It's all about the answers!

Ask a question

Agile with RTC: How to handle defects in RTC?

Cherifa Mansoura (13389) | asked Oct 16 '12, 2:18 p.m.
Some  prefer to  keep both defects and stories in one "master" backlog.Others like the idea of having to manage two different backlogs. The latter is preferred when a tech lead is part of the team and work closely with a PO to prioritize both backlogs when it comes to scope the iterations and when the managers want to know separately the cost of defects vs new features. 
How can you manage two different backlogs in RTC? Using different views?
Once the iteration is scoped and both defects + stories are selected (from one or the  two product backlogs) for such an iteration,what metrics do you use to measure the progress during the iteration? ? The challenge in RTC is that defects are estimated in hours whereas stories are estimated in terms of story points. Do you create a story for the defects and estimate it in terms of story points? Do you see different  types of defects? How do you treat them ?

3 answers

permanent link
Richard Knaster (23817) | answered Oct 18 '12, 2:39 p.m.
edited Oct 18 '12, 3:39 p.m.

One Product backlog

Defects and Stories should be in the same Product Backlog.  Users rarely care whether something is called a New Feature or a Bug. They just want the system to work a certain way. Maintaining two separate backlogs is not an ideal situation and requires the product owner and team to maintain two separate set of books for prioritization.  Teams should avoid doing this unless keeping one backlog would necessitate significant changes in how the organization works or if it's outside the team's control or influence to maintain one backlog.  During Sprint planning, unless one backlog is used, the Product Owner and Team will need to remember to take Stories from Product backlog A and bugs from Product Backlog B.  Product Owners tend to ignore bugs and focus on new features and this will result in a build up of technical debt and lower quality.

If one product backlog is maintained, you can use a filter in the RTC plan view to view just defects, or just stories and/or epics.

During Sprint planning, I recommend that the team create a Defect Story (Fix Defects) and then puts the defects to be fixed as children of that Story.  The Story size will depend upon how many defects the team on average needs to address.

So let's say the team can do approximately 20 Story points per Sprint and on average can fix approximately 5 small defects escaped from prior sprints.  In reality, their real velocity is 25 Story Points.  In this example, the team would allocate 20 Story points for new features and 5 Story points for defects.  If there is a medium or large defect, I recommend creating a separate Story for that defect, estimate the story points and then putting the defect as a child of that Story.  Anything beyond a small defect probably requires additional conversation with the users and a Story is better suited to that.
Two Product Backlogs
If two backlogs have to be maintained, you can still use the same approach as the last paragraph, but you should supplement your metrics to ensure that high severity defects are being addressed each and every sprint (e.g. count of defects fixed per Sprint, or create a custom report to burndown the backlog using a count of defects, rather than Story points).

You may also want a Technical Team lead to serve as the product owner for the defect backlog.  This person is closer to the work and will be in a better position to prioritize the product backlog and ensure that the defects are not being ignored during the sprint planning meeting.  

permanent link
David Olsen (5237) | answered Oct 16 '12, 4:21 p.m.
One approach for keeping defects and stories separate is to use two different team areas.  One team area would own all the defects and the other would own all the stories.  The two team areas would use the same timeline so they would have the same iterations.  The teams might even have the same members.  To keep the organization clear, the two team areas could be children of the same parent team area.

This approach has a number of drawbacks.  You need different "Filed Against" categories, because that is part of what controls the team area that owns the work item.  There is the overhead of maintaining the separate team areas.  So I don't claim that this is the right approach for you.  But it might be worth considering.

Cherifa Mansoura commented Oct 18 '12, 12:51 p.m.

may be worth trying.

permanent link
Marie Drahorad (1) | answered Aug 30 '13, 8:40 p.m.
edited Aug 30 '13, 8:44 p.m.
I am in a situation where the teams/resources are setup such that the same resources are working on user stories and defects during a sprint and I believe we need to take into account the defects we are working on during a sprint to calculate team velocity.

It would be nice to know which defects affect which story.  We are using storypoints on the defect and then assigning child work items with hour estimates to the defect.

If we link the defect to the user story as a child, we can then see how many defects occurred on a user story when we are using the taskboard.

Since we are providing a story point estimates on both the defect and also the user story, I am assuming the team velocity would include both the story points from the user story as well as the story points from the child defect.

Can someone confirm this?

Also the load and progress would calculate on both the work item task cards that have hour estimates attached to the user story as well as the user story's child defect.

Can someone confirm this?

Robert Myers commented Jan 10 '14, 5:35 a.m.

I want to see Defects associated with Requirements which were not Implemented correctly.
This way when I need to Test the new Release with those Defect Fixes, I can execute just the Test Cases that Validated those Requirements in the last Release in addition to the new Test Cases that Validate the Fixed Defect in the new Release.  Taking this approach gives me a Validation that is adequate. I may not have time or resources for running the whole test suite.  This is particularly true when doing modular development where the defect and the fix are largely circumscribed.

Your answer

Register or to post your answer.