In your first few sprints there will not be many defects in your story backlog. Therefore, those sprints will almost exclusively contain new development stories. However, you will reach a point where defects begin to accumulate. As any good scrum master would do, you will turn these defects into new stories and have the product owner (or business sponsor) prioritize them with the remaining stories in the backlog.
For product owners and managers that are new to Scrum it is difficult to envision how defects will be managed. Its difficult because they expect that each sprint is going to be 100% focused on delivering new stories. This perception can be especially dangerous when the manager and/or product owner are trying to set expectations with upper management on project milestones.
You, as the Scrum Master, need to help the manager and product owner anticipate defects. We know that the software is going to take as long as it takes to build. Managers and Product Owners just can't live with a statement like that. Rather than fight this fact you need to find a way to lead in the face of it. You need to inject yourself into the milestone planning process and guide this planning in a way that anticipates defects by planning defect stories for the later sprints in the project. The following chart depicts a hypothetical reduction in new story velocity over time.
2 comments:
Thanks for the post, I'm researching how to incorporate defect management into scrum and this helped.
This is a good and impressive way and i have seen it working because majorly scrum meeting help us with improving in a lot of different aspects which is proven quite sensible.
Post a Comment