Story Completion and Acceptance
In our last sprint retrospective we were not able to complete nearly 50% of the stories in our sprint. What was up with that? The last day before the end of the sprint, everything was still in progress (say 80%) but nothing was done. We talked about it in our retrospective. Why was this happening?
Lots of reasons:
The stories as they are broken down are typically taken on by only one person. Aside from any distractions, that person is focused on one and only one thing for that sprint – completing that story. Some people are UI focused, and generally, they get the UI stories. Other people have experience in certain components, and strangely enough, they pull those stories matching their expertise. So the specialization of individuals on the team plays an important role in how stories are completed by the team.
Furthermore, stories that are written in a way that cater to specialization further aggravate the problem. For example, stories really shouldn’t be broken down into UI, backend and DB layers. To do so is to create a story that can ONLY be accomplished by a specialist. Theoretically, our stories should require everyone’s involvement. So in essence, often times we are guilty of creating stories that can only be accomplished by a specialist. Each specialist on the team pulls a story that they have expertise in. Guess what inevitably happens? We end up with one story per team member per sprint.
Independently, each team member works as hard as they can to finish the story by the end of the sprint. As a whole, no stories are completed until the last day of the sprint.
Does this sound like what might be happening to your team? I assure you, it is not uncommon. Teams I work with do it all the time. Even the really experienced ones if they aren’t paying attention.
So how do we avoid this? Here are a few ideas:
1) Try to write stories that reflect implementation of multiple skills (vertical slices through the system). Try not to break the stories down when you are in sprint planning.
2) Agree as a team on how you are going to manage this. If your team feels that they are falling into the pattern I outline above, what are you going to do to change it? Focus on one or two stories each day? I know a team that did this very well. They would have what they called a “tactical” meeting each morning after the standup. In the tactical meeting they would work out exactly who was working on what. It forced a certain discipline on the team. Another idea is to only allow stories to be pulled by pairs of people. This will focus more resources on each story. Note, this is not pair programming – it’s working together. Another idea: If you have 8 stories only allow the team to pull two at a time, and don’t pull the next two until the first two are done.
3) Specialization is always the bogeyman in my experience. Nobody wants to volunteer to be anything other than an expert. Time pressure plays a role here too. “We don’t have time to flail about learning new things.” Give it to the experts. You are going to have to fight this. Reward people for taking on new stories that are not in their realm of expertise. Don’t give in to time pressure – you will be able to make up later the time you lose now. Slow down to go faster. It’s counter intuitive, but it works. Take much more of a “learning” mindset. This is a learning process, If we ignore these learning opportunities, we will hurt ourselves in the long run.
I’m sure there are many other good ideas you can try. That’s what we’re doing – assessing where we are at and trying something different. There is one note that I think is important to make: If you are successfully delivering 100% of your stories each sprint, then perhaps you don’t need to worry about whether you finish them one at a time or not. In that case, completing stories is probably not your biggest problem. If I had a team that successfully completed their stories every sprint, and they didn’t show any progress until the last day, I would leave it alone. That’s right. I wouldn’t worry about it. All that really matters is that we deliver high quality product every sprint. If a team can do that, I’m not going to try to micromanage how they do it. Keep in mind that it’s a balancing act, and that we are ultimately not trying to create pretty graphs, but rather to satisfy our customer’s needs.