Thursday, April 04, 2013

3 Reasons to Give Story Points to Defects

An agile manager recently asked if the teams in his department should size bugs, the same as they estimate user stories with story points.

My response was that I prefer to story point escaped bugs. Escaped defects are those not found within the sprint (because sprints should be zero-defects).

Sizing defects helps:

  1. development teams get credit for the work that they do, which often can often include fixing bugs.
  2. the Product Owner determine priority (maybe he doesn't really want to fix a defect for IE 5.5 users in Estonia if it means 40 points of work.
  3. track another view of defect trends for your product (not just defect count but also total effort/complexity/doubt, priority when combined with feature requests, real progress trend, etc).


Derek Neighbors said...

100% disagree. Considering a significant rebuttal piece. :)

Andrew Rusling said...

I believe that a teams velocity should represent the outcomes they have achieved not necessarily the work they have done*. Hence I prefer not to size defects, and for the team to reduce their predicted capacity for the sprint to get the defects resolved.

e.g. A team member could spend many many hour ineffectively delivering a feature which is not wanted. That is a poor/zero outcome for lots of effort. The teams velocity should not increase for doing 'busy' work.

Scott Dunn said...

Derek, looking forward (I think) to your response,

Andrew, great point. I do believe that teams should be business focussed, and I hope to see them mature to not needing, or even wanting, to size defects. But with new teams, I get a lot of resistance to not getting credit by management for the work that they do, there is an absence of trust and respect between the groups.

Andrew Rusling said...

Scott when there is a lack of Trust or Respect work the work done by the team, I often find that it stems from a lack of visibility around the work that the team is doing and obstacles that they need to work around in their day to day existence. When this occurs I coach the Scrum Master to make the team impediments clear to management and to make the work that they are doing highly visible by involving management as much as possible.

Once teams are used to getting credit for doing busy work, it will be a hard habit to break.

I do agree that as team mature their approach should change and hence your coaching approach should change.

Mark Levison said...

Scott - like Derek I disagree. This was work not done. When they fail to complete something in one Sprint I don't want tem feeling all warm and fuzzy about it. I I want team members to feel uncomfortable.

In addition I find it difficult to estimate defects well since in many cases I don't understand the size until I've found the problem. Once I've found the problem the fix often only requires about 10 minutes more work.

So to summarize - no, no and no :-)


Scott Dunn said...

Thanks for the comment, Mark.

I agree that they don't get credit for work not completed. I'm not referring to defects of stories worked within the sprint, but defects found by QA in production code.

Andrew, great guidance on making impediments clear to management.

As far as visibility to the work the team is doing, how do you recommend doing that for a production issue?

Andrew Rusling said...

The simplest solution that I have seen work well, was to include the list of escaped/product defects fixed during the Sprint Review.

These teams would summarize their sprint outcomes on a page in their wiki. The PO could ask questions about the defects if they were important or interesting. Otherwise they could skip over it during the review and team had a cheap record of the defects to refer to later.