As far as I know, we use story points to measure the complexity of a story in Scrum.

But what about Defect? Should Defect have story points? If it does, what does it mean by completing these points, given that a Defect doesn't have business value like a story? Should we have something different from story points, for example, defect points?

  • 5
    To be a massive pedant, story points aren't part of scrum. They are a method you've chosen to estimate effort. Ray is correct and the effort to fix bugs is still effort. – Nathan Cooper Nov 24 '15 at 1:12

[...] given that a Defect doesn't have business value like a story?

I disagree with this. As a user, I want my software product to work and behave as intended. A known defect goes against this. Accumulate and ignore enough defects and sooner or later your customer(s) will stop using your product and use someone else's instead.

This is something known as retained revenue1, which includes customer(s) that would leave if something the customer wants/needs is not done. This is often mentioned in terms of features, but it can also include defects. (Can you honestly claim your product has some feature X if said feature is broken? I don't think so.)

Since it is assumed that when a feature or story is accepted as "done" it works as expected, it's perfectly valid to create another story and estimate it in the same way as you normally do, especially if the defect is discovered by the customer(s) after release. If the defect is known prior to release, then perhaps the Product Owner should've rejected the "done" status for the story and moved it back to "In Progress" or a equivalent status, but not call it "done".

Should we have something different from story points, for example, defect points?

No. Just treat it like any other story in your team's backlog with a size estimate for its effort/complexity and a priority that's relative to other stories.

Since defects are an example of "Technical Debt", and bugs become more expensive to fix the more their resolution is delayed after being discovered, the team and P.O. should consider giving defects a slightly higher priority. What you use to determine this priority (e.g. visibility, customer annoyance, something else?) should be up to your team.

Just my 2 cents.

1 Agile Estimation and Planning, by M. Cohn

  • 3
    +1k for "...I want my software product to work and behave as intended." I support a buggy, third party app that causes a lot of stress and support costs. "Working properly" is a huge feature that adds a lot of value. – poke Nov 24 '15 at 4:45

I've been on a couple of scrum teams where we've debated this, but ultimately come to the conclusion that defects should be story pointed like stories. The reason is the purpose we are using story points for - by measure the amount of story points completed each sprint we can get a rough metric for the team's capacity, how much work the team can complete in a sprint.

If a defect is significant enough that it will take development resources away from other stories, then it should be pointed and figured into your team's capacity for the sprint. I've always found that once the testing effort enters into the discussion, which often include writing missed unit/integration tests, it always ends up being significant enough work to point. If the bug is so ridiculously small and no real testing effort is required then you could always give it zero story points.

  • Typically 1/2 is better than zero, could you fix an infinite amount of trivial bugs? – Nathan Cooper Nov 24 '15 at 1:13
  • 2
    No, that strategy is not meant to be scaled. If you have a large number of trivial bugs you may need to story point them as a group. You don't use 1/2 because the point of restricting the set of allowed point values is to prevent wasting time splitting hairs over something that is only supposed to be a coarse grained estimate. If it's not a 0, it's a 1. – Erik Nov 24 '15 at 1:18
  • It's all a bit arbitrary, I use 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. I'm not that bothered if you're team are happy with 0, go nuts. – Nathan Cooper Nov 24 '15 at 1:31
  • Yeah, either way could work. We virtually never give 0 story points to anything because of testing effort involved, so it doesn't much matter. – Erik Nov 24 '15 at 1:33

I'd argue that a defect represents an earlier feature that has not been adequately completed. Therefore the fixing of defects is not given story points.

If you apply story points to defects your burn-rate looks great "We completed 20 story points worth of features this sprint" - but, 10 of those points were bug-fixes so your real rate of progress is only 10 this sprint.

Now, I'm not advocating fixing every bug in the sprint immediately following discovery. Some bugs just aren't that critical. But don't "complete" a 5 point feature then the following sprint do another 5 points of bugfixes to it - it masks bad estimating, bad coding or both.

  • 3
    If the team are doing work that isn't being measured, how do you take this into account when you measure the teams velocity? – Karl Gjertsen Nov 24 '15 at 5:59
  • 1
    The team are doing work that's already been estimated. They didn't complete the story during the previous sprint(s) so the effort is being carried over in the form of bugs. If you do include bugs with story points you mask the underlying productivity of the team in terms of delivered, bug free, features which is my preferred metric. As I said above, you can go on delivering 20 story points per sprint but if half of those story points are really bug fixes, the business is not getting 20 story points worth of added value. – mcottle Nov 25 '15 at 1:14
  • 1
    @mcottle You assigned new, personal meaning to story points and velocity which is fine but it is not what these are in a traditional scrum context. They merely serve your ability to make good estimates, to improve planning. The quality of your software or the happiness of your clients have nothing to do with it. – Martin Maat May 4 '20 at 4:56
  • 1
    You'd have to show me a reporting tool that correctly sums up effort spent on bugfixes on the original story/feature that caused it. And also, sometimes you complete a feature and it works fine but breaks something else. Where do you count the bugfixing effort towards? I think it's much easier to give points to bugs and then conclude e.g. "This sprint our velocity was 25 points, of which only 8 were new features." – marstato May 4 '20 at 9:42

My team put story points on any defect identified after the sprint in which the story was completed. If the defect is found during the sprint that the story is being developed we consider those acceptance bugs and are part of the original estimate of the story.


You have to assign story points, otherwise you have no way to accurately measure the teams velocity.

If you get through 50 points in a sprint, but you are working on 10 points worth of bugs, your velocity would only be 40. How would you account for this in the next sprint planning?

  • The good point is, you don't account for this in planning. You plan 40 points of new work, and you probably will get 10 points of bugs again. – MSalters Nov 24 '15 at 13:14
  • That would only work if you are keeping 2 separate velocities, one for stories and one for bugs! – Karl Gjertsen Nov 24 '15 at 13:16
  • The point was actually not estimating bugs at all. Not points, not velocities, nothing. This assumes you fix bugs immediately and bypass planning. Unfortunately, this is a high standard - too many companies treat bug fixes as if they're new features. – MSalters Nov 24 '15 at 13:23
  • The questions specifically asks Should Defect have story points?. In my experience, the only defect you stop for is a Priority 1 (as defined by the Product Owner), all of the other defects are added to the next sprint. These defects are bugs, not new features, however you need to make sure the next sprint is achievable. If your velocity is 50, you cannot have a sprint with 50 points, with an additional 10 points of defects and expect everything to be completed. – Karl Gjertsen Nov 24 '15 at 13:28

If you are properly linking defects to your user stories (whether directly or indirectly), then you should have backward traceability. So the story points that are affected by the defect are your reference. From that, if you have already estimated each story point's complexity/size/effort that can help you estimate the defect's complexity/size/effort.

  • 1
    Saying "just by knowing which story points are affected by the defect, you can estimate the defect's complexity/size/effort", I think, incorrectly suggests that the size of a defect-fix story should be the same as that of the story being fixed. Although it could be helpful, I'd at least note that this implied correlation is not necessarily there. – code_dredd Oct 16 '15 at 19:27
  • @ray - this is true. I edited my answer to try to remove the implied correlation. – Andy Oct 16 '15 at 19:53
  • Unless its pretty obvious, its usually not worth the time to analyze defects to find the original user story that they belonged to and link it (sometimes you just cant, sometimes its inconclusive, and sometimes its confluence of multiple things). And that's not counting the time involved to take a lesson from it and then alter a habit/behavior/process to avoid it. – StingyJack May 4 '20 at 1:54

Story Points represent business value and the velocity that a team is capable of within a sprint. Yes in a sense fixing bug has a business value, but if you prove a high velocity capacity just because you put story points on defects then your team will neglect Quality Assurance.

For example, if a team has an optimal 30 story points velocity for a sprint planning and after their grooming they realize they can only commit to 20 story points due to bugs prioritized by the product owner. It then raises a flag to increase quality control/management and the goal to lower amount of defects.

The engineering department needs to react, adjust and fix any problems when a decrease in velocity is noticed.


For sprint planning purposes, I count each bug as a half of a story point (the smallest increment) instead of trying to estimate them. For sprint deliverable purposes, I also count bugs as a half a story point, but only those bugs that are not related to development work executed in the sprint (like a regression, or something a user finds in production and needs fixed asap).

  • Downvoter care to explain? – StingyJack Jun 8 '20 at 2:15

Not the answer you're looking for? Browse other questions tagged or ask your own question.