Get certified - Transform your world of work today


Should Defects Be Considered User Stories?

10 May 2013

Prashant Pund
AgileSoft Methodologies

User stories and story points

A user story is a description of functionality at the lowest level of granularity that can be independently developed and demonstrated to generate feedback. Since, in Scrum, we focus on developing the smallest incremental functionality of the product, we use the user story as a unit of development. We also need to assess the size of the software being developed per sprint. The size of the user story in terms of story points is decided mainly by:

  • Complexity (related to development)
  • Doubt (clarity on what is really needed)
  • Effort (work needing to be done)

This approach is logical and similar to one taken for use case points or function points. (The only difference is that while use case or function points are "counted" as an absolute measure, the story points are "estimated" as a relative measure.)

Hence it's a good idea to assign story points to these stories and to track the velocity of the team by means of these points. Keeping the velocity at a sustainable constant value is the responsibility of the team.

User stories and business value

Every user story, when developed, must add to the business value as endorsed by the product owner. One user story may add much more business value than another. The business value of the user story decides its place in the prioritized product backlog.

Assessing the business value of the story, prioritizing the story accordingly, and passing on this understanding of value to the team is the responsibility of the product owner.

Do the story points indicate business value?

The answer is no. As stated earlier, story points constitute a sizing technique to indicate how big a story is. A bigger user story may have less business value than a smaller one, and vice versa. Well, then, if we measure velocity, does it indicate the business value delivery of the team? Again, no.

In short, velocity and story points developed can indicate only the pace and productivity of the team.

A team with constant velocity may give varying business value to the product owner. The only way of ensuring incremental business value along with the productivity is to prioritize the stories effectively and give the best possible understanding of this story prioritization to the team. That's why product backlog grooming helps to add business value.


A defect is an understanding of deviation from the expectation. The severity and effect of a defect will vary from "ignorable" to "show-stopper." During the sprint, there can be defects of varying severities, and the team must make decisions to "fix in this sprint" or "push to the product backlog." This is typically decided based on whether the developed user story still delivers the business value. If a defect prohibiting the execution of functionality, thereby rendering zero business value, is not fixed by the team by the end of sprint, the product owner would not want to consider the story points as "delivered." The story would not be "done." This is quite fair. However . . .

Defects and story points

Many a times, even when the story is functional, the defects are considered "sins committed by the developers," and the product owner doesn't count the fixes or work-arounds as "work done." By not counting this as work, we are not accepting the truth that it eats up the sprint work time, and the actual feature development will be affected. You may not consider it "business value work," but you need to count it for an accurate measure of velocity. If the work to be done by the team also includes defect fixes, we need to size that, and the convenient way to do so is to assign story points to that work. So you can assign story points to the defects and add them to the "feature development" story points. This gives a clear idea of the team's productivity.

Keeping the track of the defect story points separately can help you find out in a quantitative manner how much more feature development the team could achieve in the absence of those defects. This motivates the team, PO, and management to think about defect prevention measures.

Other work items that can be assigned story points

When you have component teams (such as a UI development team or a framework component development team), they don't produce any business value as is provided by "feature teams." In such cases, it's useful to have the components under development at par with user stories and size them using story points. Further, such a work item as "architectural refinement" may be taken up even by the feature teams, and it needs to be counted in size although its completion may not demonstrate business value.


  1. Accept that defects are "backlog" items. Effort will have to be added for dealing with them in the sprint.
  2. To understand the velocity, size the defects using story points.
  3. Separate "delivery of business value" from "velocity of the team." While the former is driven by the PO, the latter is driven by the team.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 2.3 (4 ratings)


Vijay Kumar, CSM, 5/16/2013 5:59:44 AM
This is good reading, we have implemented the same approach of considering the bugs as a userstory when we had spent 10% of time fixing the bugs in a Sprint which we have not accounted for, as a result our velocity was effected.
Gurpreet Singh, CSP,CSM, 5/16/2013 6:27:21 AM
Hola! very nice thought put-up. great amigo.
Sandeep Bramhe, CSM, 5/17/2013 9:53:48 AM
Nice! We story point our defects too.
Now, How do you estimated story points for an training or other category item which does not necessarily add direct value to the release?
Prashant Pund, CSM, 5/23/2013 2:58:45 AM
We find the available time for each sprint by adding the available time for each team member. The time not (to be) used for the "Sprint work" is not to be considered as "available".
Hence, this work which is "Process Work" than "Product Work" should not to be counted while deciding Velocity. This way, velocity will always represent the team productivity to produce value.
Sivaraam Duraisamy, CSM, 5/23/2013 11:42:46 PM
Thanks Prasanth for the good article. Good thought. In software the defect fixing consumes a considerable time. So it is necessary to measure it, may be in story points. But when it comes to productivity, if the number of defects are more and the time consumed in defects are more, the productivity will not have a relationship with the value delivered.
Zoran Vujkov, CSP,CSM,CSPO, 5/30/2013 4:14:22 AM
I don't think is necessary to add user story for defects and do SP estimation. It works equally well if you allocate some % of time (buffer) in sprint for defects. As you fix more defects in sprint velocity will be smaller because you will finish less user stories, if you fix less defects situation is opposite. Estimating effort in SP for defect fixing is waste and it is difficult to compare effort necessary to do user story and effort to do defects
Maryann Snider, CSM,CSPO, 6/8/2013 3:35:33 PM
@Zoran, I agree defects are waste, should be reduced, and using SP skews user story point value. We have a warranty period, so all defects are fixed before the period ends, and any defects outside of that period go to the help desk, and production support team at a fixed cost.

My business owners require us to deliver quality software on time, not deliver defect ridden software on time. I understand some defects are unavoidable; however, value decisions are made daily by the PO with team input. If a defect canΓÇÖt be fixed in the sprint it was created, a deeper problem is brewing. We inspect right away.
Is business/PO PUSHING stories on the team rather than the team PULLING user stories? Did the team pull incomplete stories, large stories, or was a dependency not removed beforehand? Is one developer working on multiple user stories? Is there a junior developer who needs mentoring? What is inefficient in the teamΓÇÖs value work stream?

Defects represent borrowed time, debt, waste, and costs with no business value. However, value can be derived if the team can learn from their defects. This is where retrospectives come in. Ask questions until the root cause for a defect is identified, and understood, so the team can do better next time. Unless they get better, they could view defects as the status quo and equally as important as user stories, which they are not. We want value add user stories done.

Reduced velocity means an opportunity to learn, and a need to slow down a bit. Decreased velocity is the consequence for going too fast, taking in too much, or poor planning. Our developers need a rough duration estimate to fix, so the PO can weigh the cost/benefit, and for QA to test to get to done. Believe me, my POΓÇÖs feel the teamΓÇÖs reduced capacity to work on new stories, and they think through what he/she can do next time to improve throughput. If a backlog of defects festers, the team can decide how to allocate capacity to fix them, and then track actual effort in time, rather than relative story points. That way, our user story points are not devalued by defects and future user story points with potential value to our business customers are represented for the next release planning session.
Bob Lieberman, CSP,CSM, 7/5/2016 3:42:57 PM
Prashant, this all sounds good in principle. But I have found it makes the job of forecasting nearly impossible. The team has a product backlog it is supposed to work down. If the team's velocity includes points from work that never appeared on the product backlog, or appeared on it only at the last minute, then the velocity can't be directly applied to the product backlog to derive a forecast.

How have you addressed this problem?
Derek Lau, CSM, 11/8/2016 6:20:28 PM
We're wrestling with this issue, and I think it comes down to using SPs to measure velocity (team productivity) or business value delivered.

If we give points to stories and escaped defects (not bugs found in unreleased code within the Sprint- majority of these should be fixed in the Sprint they were found) then we've got a way to measure and predict the amount of work a team can get done in a Sprint.

If you want to know how much value to the business is being delivered, then just add up the points for the delivered stories, and not the escaped defects.

It may be that in a given Sprint, a team is spending a high percentage fixing escaped defects. If points are given only to stories, then you'd see a decrease in velocity.

If points are given to both, you'd still see a decrease in stories delivered, but you'd also be able to see how much effort is going into fixing bugs, and can then do further inspection on why.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up