by Bill Rinko-Gay
Now that your stories are chosen and the iteration has been kicked off, is there any reason not to have developers simply start in as quickly as they can on writing the code for the stories? I believe there are 3 reasons to set up a plan for delivering groups of stories to test. First, functional grouping allows for higher quality code delivered faster. Second, functional grouping makes the testing job far easier. Third, functional grouping allows the team to re-plan an incomplete iteration. Let’s look at each of these claims in detail.
Quality: An iteration will always have stories that impact different functional areas. If you functionally group your stories you can consider the potential impacts one may have on another. Planning the development with these impacts in mind is likely to get the development done more quickly. Since the development will be more coherent from the start, it is likely to be of higher quality. Of course, you can achieve that same level of quality when taking the stories piecemeal by re-designing and re-factoring to account for the interactions. This is what you have to do when the stories fall in different iterations. Re-designing and re-factoring takes time, so it benefits the team to avoid it whenever possible.
Testing: Functional Grouping aids the testers because they can focus their efforts on a single functional area at a time. When that area is complete its manual testing will not have to be revisited, reducing test thrash. Completing a functional group and then turning it over to testing means that functionality can be finished when testing is completed. The software moves forward without the delays caused by going two steps forward and one step back.
Re-planning: Reasonably stable release candidates are made ready for test at the completion of each functional group. The team may have some other partially completed stories in the build, but the completed functionality can be the basis for a release if the team runs behind in finishing the iteration. If there have been no stable builds prepared for test and you decide to cut back on the stories in the iteration, you risk destabilizing the code. If you have one of these test builds to fall back on, you will have an easier time limiting the release to the smaller group of stories.
The functional groups should be worked on in priority order. In some cases the priority may be set by technical risk. Otherwise they are set by the business. The planning should be based on the question, if the iteration could only deliver on a subset of the stories planned, which is the most important subset.