This week I thought I'd re-post an article that appeared earlier on DeveloperWorks.
___________________
Early on, when I first started coaching teams on their transition to Agile, it was quite common for teams to come to me and tell me that they hadn't completed any User Stories by the end of an iteration. Initially, teams wanted to use this as a reason to increase the length of their iterations (I recommend two-week iterations – and teams always seem to want longer iterations). What they were failing to realize is that there were fundamental reasons why they weren't completing stories, and iteration length by and large had nothing to do with it. Let me explain....
One of the first questions I'd ask a team in this situation was if they were assigning User Stories to team members with the idea that each member was responsible for completing his or her User Story independently of others on the team. Almost invariably, the answer was “Yes, but how did you know that...?” What was happening in these situations was that each member of the team would work on his own User Story and, at the end of an iteration, the team would have six, or seven, or eight partially-completed User Stories. In this case, nothing was completely “Done!” by the end of the iteration – just a bunch of partially-completed stories. Since each team member was focused on completing his own story, there was no “incentive” for someone to jump in and help another team member get a story done because everyone was focused on completing his own story.
In this situation, we would remind the team about the importance of the Agile practice of “whole teams.” Part of this practice recommends that a team should try to work together on one User Story at time, complete it, and then as a team move on to the next story on the backlog. This way, the team is constantly completing User Stories and will have, at most, one unfinished User Story at the end of an iteration.
In order to pull this off, there's another practice that we recommend teams adopt – and that is the creation of small implementation tasks for each User Story. At the beginning of an iteration, the whole team goes through the process of creating the various tasks needed to complete a story (development tasks, test tasks, user documentation tasks, automation tasks, code review tasks, etc.). These task sizes should be small in size (on the order of 4 hours, 8 hours, to no more than 16 hours), which then allows for a lot of “parallelization” of the work. The concept is, for example, instead of having one developer work on a coding task for five days, you could put five developers working in parallel on five one-day development tasks and, at the end of a single day, have all the coding completed that otherwise wouldn't have been complete until the end of five days. Additionally, there should be corresponding documentation, test, automation, and code review tasks for each of the development tasks. This way, a team achieves a very tight integration between dev, doc, and QA throughout each User Story (not to mention each iteration), and the team also always has working code as the team completes one User Story before moving on to the next. By the way, this approach is not something that comes naturally to a team (especially if they're just beginning the transition to Agile), but give the team time and encouragement to try it out – the effort is worth it.
A few closing comments: obviously, piling everyone on a scrum team onto one story won't always work, especially with very small User Stories. The goal – even with a very small User Story – should be to put two or three engineers on that story while the rest of the team works on an additional story. Keep the number of stories being worked on at the same time by the team to the smallest number possible. This should go a long way to helping you consistently finish User Stories at the end of every iteration.
We welcome any comments and suggestions you may have -- thanks!