Quality in the scrum process

Ever wonder why your last sprint tanked? Was it because of changing requirements, undiscovered work that was found during the sprint, or perhaps because your team finished on time but the quality was too poor to release. Let's hope that the retrospective brings these issues to light and your team has the courage to make positive changes.

On the last note, of poor quality, this happens to teams more often that I'd like to think. Since software development at some level is a serial process you can find that we put our test and quality assurance team members in a tough spot... Hurry up and test the product now that we're done coding.

Has this ever happened to your team? During sprint planning your team picks the right stories, they diligently task them out and the team gets started. Of course being the excellent QA engineers they are, they do all the test case creation and automation they can before they see the features coded for the first time. Giving QA a code drop before it's final helps them finish their test cases and gets them started on setting up automation runs but it eventually comes down to having the first finished build they can test the features with.

The software developers do the coding and unit testing before handing it off to QA. Now here's the rub. Often the developers end up using nearly all of the available time in the sprint to finish their features, leaving precious little time for testing. I'd like to say that my teams have never run into this but that's not true. Even after talking about it at retrospectives this is an area where we continued to be challenged. Eventually we did something non-scrumy, we created a deadline for features to be finished by so that the team could complete all of the required testing. While the agile purists out there are surely grimacing this worked great. It allowed the developers to have a firm deadline for hand offs to QA and allowed QA enough time to finish all of the functional testing, regression testing, performance testing and final pass system testing. Now some might say that the developers should have done the testing too which we did but do you really want the person who wrote the code to do the testing too? I don't think so. We had developers test other developers code and over time we were able to reduce the amount of time it took to test everything. In the end we were successful but it required some different thinking.

How do bugs fit into Scrum

Zero bugs; it's the nirvana we all strive for as software professionals, it's also unfortunately a myth. The only way to write code without bugs is to not write code. All software has bugs, it's simply of matter of how hard you look to find them. You'd like to think that the top companies somehow have come up with a way to create bug free software. After working at two of the biggest, Intel and Microsoft I can tell you they haven't figured out how to ship bug free code either.

Scrum isn't a magic process that doesn't have to deal with finding and fixing bugs. Like waterfall it focuses on the delivery of the product and with the product comes bugs. If you're using scrum how do you account for fixing the bugs that exist in your legacy product or dealing with the new ones you're creating as you write code this sprint.

Most of us should be familiar with bug triage and assigning severity and priority to bugs. All well and good but that doesn't get the bugs fixed and regression tested. I recommend an approach to assist with first managing the current load of existing bugs and to deal with any new bugs found.

1. If you aren't holding a weekly bug triage do this now. I've been on teams that didn't emphasize triage of bugs. It came back to bite them. As a scrum master on these teams my job is to facilitate and schedule these weekly triage meetings which is the first thing I did when encountering this issue. Second, make sure that you show up prepared with a query that can identify open high priority bugs, bugs awaiting triage bugs fixed but not verified, and all bugs that fail regression. This should give a quick look at the overall health of your product wrt bugs.
2. Now that you've got a regularly occurring bug triage meeting let's account for the time it takes to fix legacy bugs. On my past teams we've taken on the highest priority bugs during the sprint planning meeting by having a story for fixing the 'X' highest priority bugs. Note: this is an estimate, you will not be able to fix all of the bugs in the bug database. This bug "bucket" allows the team to carve out enough time for the highest priority bugs while still leaving time for the team to focus on features.
3. Developers are writing code during the current sprint, bugs are being created too. Your development team shouldn't be using the entire sprint to develop code, there has to be time to do testing and find/fix bug loop. If the team doesn't leave time to do this you will either ship low quality code and/or push technical debt into a future sprint. Which isn't good because the Product Owner is expecting the team to be ready to start the next set of features in the next sprint, not fix the left over issues from the last sprint.

Your mileage may vary but I've been relatively successful in keeping technical debt low, shipping high quality features, and meeting the needs of my team and customers using this technique.