6

The product owner wants to keep track on how much points are spent on bugs during a sprint. This can raise some issues, such as:

  • Scoring a task that is already done. Surprisingly even with it done, there are sometimes discussion and divergences.

  • Scoring many small tasks with 0 points that at the end actually sum up to something meaningful (a bunch of fast fixes).

  • Counting points spent on bugs as available points for new features in the next sprint, alongside with new bugs that eventually will show up.

I agree with him that it is important to track the time spent on it, but points doesn't seems to play really well in this case. So what are the best approaches and practices in this case? Count the hours spent on each one?

Improve this question
2
  • Are you (or is he) defining "bug" as "known issues we know we have to fix, or customers report to us" or "bugs we generate ourselves as we work on features within the sprint"?
    – jcmeloni
    Mar 30, 2012 at 21:13
  • Mainly from customer report that needs a fast fix. We develop an in house framework to test firmwares. So, sometimes when something change in the firmware specs, we need to patch the framework to test it correctly.
    – eMgz
    Mar 30, 2012 at 21:34

3 Answers 3

Reset to default
6

The first thing to remember is that points != time; points are a relative estimation of complexity. While you could get a sense of hours-spent-per-point using the length of the sprint and velocity, that's not the purpose.

Tthe way I typically handle sprint planning for an environment in which customers will inevitably be reporting bugs against software in production is to assume n number of points per sprint will be spent on bugs. This goes along with Mike Cohn's example in which one might write a story like "As a user, I want at least 15 bugs fixed".

The best situation is when the reported bug doesn't warrant an immediate fix, and your sprints are short, so that the "bug" can actually just be counted as a story for the next sprint. But "best" and "common" are not the same...

I'd really try to get at the heart of what the product owner is after -- is it a need to see that bugs are getting fixed? A need to see if more effort is spent on bugs than features? -- and plan accordingly from that, rather than try to find what could be a wholly artificial answer to "how many points are spent on bugs".

Improve this answer
1
  • 1
    Treat bugs fixes as a user story seems good for me. The main problem, as you said, is that I need them fixed asap, so I think that it all boils down to the question of what we want to measure, forward progress or true capacity to accomplish work, and as Mike Cohn suggests, we can get the best of both worlds assigning points to bugs and tracking the user stories used to group and solve them.
    – eMgz
    Apr 3, 2012 at 18:07
1

Most Teams do not give any points for resolving technical debt. Thing is, if you attach points for resolving bugs in code which had already been estimated with story points, you are assigning story points for "doing work" and not for "achieving results" which can be a subtle but important difference.

Velocity and Story points are a way to measure how fast a team can create new working features in releaseable working increments.

In a project this might lead to a team who'se velocity will get lower and lower over time, because all time is spent on resolving technical debt. This is good in some weird way, because it shows that the current code base is not able to deliver new business value in form of new features in the near future. This will lead to a rewrite, and the lessons learned will lead to a more scalable architecture.

Not every kind of pain is bad.

Improve this answer
3
  • 3
    Do you have any data to back up the "most teams" comment? While some teams use points as a way to "measure how fast [they] can create new working features", other teams use points as a way to measure how much work is done during a sprint, whether it's towards new features or support or anything else.
    – Bryan Oakley
    Mar 31, 2012 at 16:10
  • Agreed, it would be great if you could attach a link or reference backing up your answer.
    – jmort253
    Apr 1, 2012 at 3:25
  • We had a few discussions in our team, about tracking tasks or progress. I think what I've read is in books, or I know of other teams who'se scrum masters I know personally. But I will go out and hunt for some links soon, and edit my post.
    – Huibert Gill
    Apr 1, 2012 at 14:44
1

Looks like your team plays two roles:

  1. scrum team which goal is to deliver US
  2. support team - do "fast fix"

Estimation technique could be used for both, scrum team estimates before iteration, in support you've got 1 day iteration instead of 2 weeks.

It's hard to estimate support tasks compare to usual US, they are much more smaller. You don't compare US against support task, so why you are trying to do that in opposite direction ?

Try to estimate support tasks against support tasks.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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