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?
[...] 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
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.
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.
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?
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.
Commented
Nov 24, 2015 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.
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).
