How To Complete Stories Without Leaving Bugs Behind
"Brian" on the Scrum Development mailing list has a quality problem:
Our Dev Team is having trouble completing Stories with low bug counts at the end of our Iteration. An Executive suggested, even if we fix the problem, creating a Story - QA Score.
Jorge Rowies offers a couple of alternatives to creating a new quality metric:
Are the QA people in the same team as the developers? If not, that would be a good starting point on how to reduce the ammount of defects.
Each of the stories have acceptance tests? If so, who writes those tests?, are they clear and achievable in one iteration?
Malcolm Anderson recommends blocking new development in favor of perfecting existing stories:
Wouldn't it just be easier to have a QA person approve a story before a developer can move on to work on the next story.
That should drop your bug count to near zero.
Developers tend to want to work on "the new stuff" and developers who can code poorly but quickly tend to get to work on the most "new stuff." This approach stops rewarding developers for producing bad code quickly.
Jack Milunsky advocates focussing on the definition of done:
Your team needs to setup your "Done" criteria for each story. This includes acceptance tests and quality criteria. If you still have bugs remaining for a story at the end of the sprint then the story is not done. You have to complete the development and test and fix cycle all within the same sprint. This will put you in good shape quality wise.
Peter Skeide has several concrete suggestions to resolve these quality problems:
- Improve how retrospectives are done so they can effectively detect and address these kinds of quality problems.
- If there are quality differences in the code written by different team members, have the better programmers find ways to raise the quality of code written by others.
- Focus on defect prevention, not just detection. Tools that can help are:
- code inspections
- Use pair-programming to improve knowledge sharing within the team.
- Begin regular use of static or dynamic code analysis tools.
José González D'Amico
Definition of done?
It might partly be a question of team structure and roles, too. I notice one quote in the article mentions "a QA person." That suggests silos within the team, as opposed to the generalizing specialist concept. If that's the reality in your situation, then there will be cases when the work moves "backward" (or at least, when it feels that way). It's just a natural consequence of the team structure and roles.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015