5

We recently began working on Scrum with one of our products. Prior to that we worked with a Waterfall methodology.

We have created stories for the new feature and also included the bugs for the next release and we are estimating stories in story points. We are not sure how to deal with bugs. Do we need to estimate in story points or number of days for bugs?

The team finds that, for some of the bugs, most of the effort is taken up by analysis since the bug requires debugging and trouble shooting efforts rather than actual code implementation.

How do we estimate these specific cases, where the bulk of the effort is spent on analysis and some of that analysis may take days to weeks to complete.

Please help

Improve this question
2

3 Answers 3

Reset to default
2

Choose a consistent estimation approach that uses story points (don't rely on hours).

You have options:

Option 1:

Don't ever estimate the size of the defect in story points. Reasoning, a defect arises when a previous acceptance criteria from an existing (already estimated) story was not met. Estimating the defect in a way then double counts the part of the work required to deliver the story.

Outcome, iterations with many defects show a lower velocity. The team is forced to discuss why their velocity has dropped and why so many defects are occurring. Con...its harder for the team to commit to completing everything in the iteration if they haven't sized it formally.

Option 2:

Always story-point estimate the size of the defect. Reasoning, in an iteration we want to align the story/defect workload with what the team has capacity to complete.

Outcome, the team maintains a consistent velocity and can accurately commit to work within an iteration. Con...it isn't as obvious empirically that value added work is dropping as defect load increases.

Hour estimation and tasking are at your discretion in Scrum. Personally I advise against formally tracking tasks or hours in your scrum software as it creates additional overhead and can give an undesirable micro-management feel to some teams.

Improve this answer
2
  • "Con...its harder for the team to commit to completing everything in the iteration if they haven't sized it formally." not really, since this is done during sprint planning - you use your capacity in hours to allocate time for those bugs, doing this formal sizing right then.
    – Alex Leonov
    Dec 3, 2014 at 21:27
  • Hour estimation during sprint planning is not a requirement of scrum. By formal estimation I mean a story point estimate. It is possible to back calculate capacity based on historical story pointing practices, but again you only know you have X total capacity, of which Y stories + Z defects should sum up to X. If you dont point estimate defects however you are doing Y + Z may or may not equal X.
    – WBW
    Dec 3, 2014 at 21:53
2

If you are doing Scrum make it as a policy that you are going to talk about the progress of bugs during the daily standup meeting. When you know what the root cause is you can start to handle the bug as a user story: you can give size or estimates because you know what you are dealing with.

If you hear no progress - let's say in 2 or 3 days - about the issue you should do something about it because a serious bug can risk your project. You can either suggest to have more people on the problem, you can cancel the sprint (discuss this possibility with your PO), or you can escalate the situation and ask for suggestions from the PO or other teams.

Improve this answer
1

First things first

If the bug fix takes days or even weeks, this is a clear sign of poor code design. This means your project code is hard to test, which should be much more of your concern than bugs estimation.

Estimation

As you start with Scrum and are used to days/hours estimates, I suggest you handle four types of issues:

  1. User Story. Adds up the user facing product functionality. Example: "As a user I want to log in via Facebook". Estimate User Stories in Story Points.
  2. Subtask. Child of a User Story. Reflects what should be done in order to complete the Story. Each Story should have at least one Subtask. Example: "Implement Login view". Estimate Subtasks in hours.
  3. Bug. The mismatch of how the system expected to work vs actual behaviour. Example: "Placing an order redirects a user to 404 page". Estimate Bugs in hours.
  4. Task. Anything, which has nothing to do with user experience and does not belong to any User Story. Example: "Set up and configure Jenkins". Estimate Tasks in hours.

Here is how do you benefit from such approach:

  • You can measure how your Product evolves. Just use Sprint velocity based on Story Points. Which clearly shows that if your Sprint is filled by tasks and bugs your Product does not evolve.
  • You can trace your Sprint Burndown. Everything you do in the Sprint is either Subtask of a Story, a Bug or a Task. You estimate them in hours and can track the performance within the Sprint.

But pay attention to the first paragraph please. Bug fixes should never take days or weeks.

Improve this answer
2
  • Thanks for the answer. The reason for it taking longer time is the product code was not originally written by the team. The team got the code due to vendor management by the client. Initially it was worked by different company and now we are responsible for working on it. Yes, we had initial knowledge transition, but you can expect the gap in understanding the functionality and code implementation. So, this is causing us delay in fixing bugs
    – ramu
    Dec 4, 2014 at 13:38
  • @ramu: If unfamiliarity with (sections of) the code is an issue, then you should factor that into your estimations.
    – Bart van Ingen Schenau
    Dec 12, 2014 at 18:23

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.