Agile with RTC: How to handle defects in RTC?
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
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. |
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.
|
