This really achieves the best of both worlds. My usual recommendation is to assign points to bug fixing the agile defects. A common approach for doing so is to plan to fix X bugs per sprint or spend Y hours on bugs per sprint. Shortly into their agile initiative, many teams (and their product owners) decide to aggressively work through the bug backlog. These are the result of an inadequate focus on continuous high quality. When migrating a product from a traditional approach to an agile one, teams commonly bring along a large database of agile defects. On the other hand, if the team does assign points to the agile defect bug-fixing effort, velocity comes to represent the team's true capacity to accomplish work. This has the advantage of making visible that the team is going more slowly through the work than it could if these legacy bugs had been fixed when originally found. If the team does not assign a story point value to this work, velocity will show the amount of "forward progress" the team is making each sprint. In these situations, a common question is whether the team should assign some number of story points to the work of fixing these legacy bugs. Sometimes teams write a user story for this activity such as: "As a user, I want at least 15 bugs fixed" or, "As a user, I want you to spend about 50 hours this sprint fixing bugs so that the application becomes gradually more high quality." Even a team that doesn't explicitly write such a user story will usually include a row on its taskboard to make the agile defects and bug fixing visible, and to track it.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |