Wednesday, February 8, 2012

Scrum quality – Teams not delivering high quality stories; testing not complete during sprints


You had a sprint demo and it failed miserably. A lot of stories were not fully tested. QA team is complaining that they don’t have any work during the first part of the sprint and they are overloaded during the last few days of the sprint. This looks very familiar.

For months we will work casually and during the last two months of the release there will be lots of last minute changes and bug fixes. It will be a virtual hell with late night hours. People will be coming early and going late (Many don’t even go home, they stay at office). Now this looks familiar. We have seen this in many projects. Scrum promised that such thing won’t happen again but still we can see such mini waterfall in our sprints. If you are seeing such issues, you should have a retrospective immediately.

A scrum team should be cross-functional. I will start with the following questions

• Why can’t the developer’s cross verify each other’s work?

• If testing is the bottleneck why can’t everyone help by testing few stories?

• Why does the QA team have to wait till the last week for testing?

• What is preventing the team from generating the build early?

• Why is the number of bugs increasing - are the unit test cases weak, are the acceptance criteria for the story weak?

• Is this a skill problem? Does the team require technical training?



Based on the answers you will get a nice perspective of the problem.

There are some suggestions also from my side to prevent this

• Implement XP practices like pair-programming, TDD etc. this will improve the quality (less number of bugs).

• No hands-off between dev. & QA (in fact there shouldn’t be such division itself).

• Make testers (dev. or QA) test the code in dev. machine itself before the build is generated. I have done this successful in my team. The feedback cycle was very small. No more time wasted in creating a bug in bug tracking system, assigning it, explaining it, providing the test data etc.

• Slice down the story to lesser size so that it can be managed & finished early.

• Create a continuous integration/nightly build. If build goes out every night then sure nobody can complain that there isn’t any task for testing.

• Team should swarm over the highest priority story first and only after its completion they should move to the second story.

• There is no dev task & QA task. Everyone should do whatever it takes to accomplish the sprint goals. Developers should test. QA should help dev. create code (they can create test data, set up the environment, automate the test case etc.)

Post a Comment