Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

If you're using scrum you should know that there is a clear difference between tasks and stories. A story is something that is valuable to user. A task is a step to produce that value to user.

So how to define a bug? Is it something you should to fix? Or is it something that will put more value to user?

share|improve this question
3  
A great, classical question that every Agile methodology does not really address. –  ashes999 Mar 3 '11 at 18:33
    
This is very much great and hope fully nice blog. Every body can easily found her need able information. I am visit first time but I fond many use full article. I will back again when get time. –  user7635 Dec 18 '13 at 7:13

11 Answers 11

up vote 16 down vote accepted

I use a modified version of Scrum with my teams in week long sprints. The product backlog is ordered from top to bottom in order of importance. The development team takes items off the top of the stack and works on them.

If the feature isn't done at the end of the week, we talk about what will be done at the end of the next sprint, and work continues on the incomplete items.

In Managing Bugs in Scrum, the author, Mark Summer, suggests treating bugs as the same as a partially implemented feature. If you really think about it, that's exactly what a bug is. It's a specific part of a feature that is not completely implemented.

I currently have a bug list and a feature list. I am considering merging them and treating the bugs as incomplete features, as suggested by the blog author. This will greatly simplify the challenges I face in prioritizing tasks, and it will make it easier for developers to pull tasks off the product backlog stack.

share|improve this answer
2  
+1 for the link –  Vanuan Mar 2 '11 at 22:11

My recommendation to teams I'm coaching is to separate bugs to two kinds:

  • The bugs/defects that are due to a failure in CURRENT work (e.g. story from current sprint) - for those I recommend tracking them as tasks on that story, and as blockers to that story being DONE/Accepted.

  • Bugs/Defects that are detected but are understood to have been there for some time now, maybe even already there in production - for those, treat them as backlog items that you need to prioritize. Thats usually a Product Management/Ownership decision/policy. The end result CAN be that you will fix them right now, but it depends on the priority.

share|improve this answer
    
Some authors say you should treat all the bugs with the top priority as they block currently or previously introduced features. –  Bartosz Rakowski May 17 '11 at 20:32

The wonderful thing about agile is that we retired concepts such as the requirements baseline so for an agile team the difference between a bug and a story is not an argument worth having. Both represent "stuff" you need to.

If the bug is part of the work being done in an iteration/sprint and we want to fix it in that sprint/iteration then treat it like a task. Otherwise put it on the product backlog.

If the bug is on the product backlog then there is value in fixing it otherwise it should not be on the backlog. The bug should also be estimated otherwise you will have difficulties planning work and measuring.

There is one special case where new development exposes a latent bug so severe that it impacts the whole iteration and I don't think there is an easy answer to this one.

share|improve this answer

A bug is bug per se and should be treated as a task. I see no difference, you can have a sprint with tasks of bug fixing.

share|improve this answer
    
But shouldn't bugs appear in a backlog? Tasks and impediments should not. –  Vanuan Feb 25 '11 at 22:59

For me it depends on the size, severity and when it is found.

If it's found during testing of a planned feature, it goes back into development to be re-worked on, and discussed in the scrum.

If it's major, red alert, red-flag stuff then it probably needs it's own task to be inserted into the next sprint.

If during general testing a heap of smaller, ordinary priority bugs are found, I tend to make up cards that say "fix 5 outstanding bugs" (or whatever suitable number), assign it a small value and but it in the backlog with all the other tasks.

Don't get hung up on the terminology - just make sure they can be tracked, repaired and accounted for.

share|improve this answer

What's the difference between a story and a task? Or a story and an epic? Or, a bug and a story?

In my opinion, it's all work.

If a bug is found in a story we're working on in the current sprint, the story is moved back to the sprint ready queue and flows back through the process.

If it's something unrelated to the current sprint and gets prioritised by the PO, whether it's a bug with previously delivered work or something new, it's moved to the sprint ready queue and flows back through the process.

share|improve this answer

For me the bug in implementation is usually a task.

As for bugs in design/architecture these are usually not so easily fixed and tend to end as a story.

share|improve this answer

Something that puts more value is a feature or a story. A bug is something wrong in a feature/story that has been completed.

share|improve this answer
    
So, is it a task? Or incomplete functionality? –  Vanuan Feb 25 '11 at 23:13
    
Please be more specific "A bug is something wrong" yes we know, but Vanuan asked how to treat a bug in scrum. –  Arturo Caballero Feb 26 '11 at 21:20

I agree with: - if part of work on current feature, treat it as part of the sprint and not a separate defect - if outside of the sprint (e.g. from production issue) then create a Bug item on the backlog.

Should you give them Story points:

  • Yes: means they are treated just like stories and help with the accuracy of your planning process. However, it also implies that they add business value and form part of your team velocity measure which they shouldn't

  • No: means that they are not treated as adding business value and punishes the velocity if you have a quality issue that needs addressing and falling velocity would be an indicator. It also means that you may find it hard to plan your releases against the rest of your backlog.

share|improve this answer

A bug is an output of "Verification" and an input to "Project Planning" and "Requirements Development" (according to CMMI). Thus, in order to keep a transparent traceability between artifacts you should refer to your bugs when making changes to "stories" and planning new "tasks".

share|improve this answer
    
I'm not sure if I understand why reference to CMMI is apropos here. CMMI is one of the heavyweight approaches that inspired the Agile Manifesto. –  Ken Clyne May 18 '11 at 2:34

A practice I've heard of is grouping a number of related bugs into a single product backlog item. This makes sense to me as there might be hundreds of bugs in a large system, and keeping track of all of them as separate product backlog items would incur a considerable amount of backlog grooming waste.

It is also easier to attribute end user value this way, and we also avoid estimations in fractions of a story point that otherwise would be inevitable for trivial bugs.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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