Story Completion and Acceptance

June 5, 2008

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.

A few experiments in Agile

June 3, 2008

Here are a few ideas for things we could try out to improve our teams:

  1. Work on only one story at a time
  2. Minimize square footage of the team area
  3. Daily Design Review
  4. Change the way you do retrospectives (a coffee chat rather than an inquisition?)
  5. Bring one new idea to every stand-up meeting
  6. Daily interaction with other teams (ping pong tournament, sports book, whatever)
  7. Utilize ambassador pattern between teams
  8. Get to know I new thing about a team mate each day
  9. Focus on a single practice in each review until the practice is mastered
  10. Swap roles every sprint

Like anything else, they probably would be best supported by some acceptance test of some sort. It would be some what of envisioning what the success of a given experiment would look like. There is no point to trying something out if you have no idea what the benefit will be…

Just a thought,

Diversity & Teams

June 2, 2008

I’ve been reading “The Wisdom of Crowds” by James Surowiecki lately and he makes a compelling case for composing teams of people from a wide variety of backgrounds and skill sets. He claims that teams that are composed only of “experts” do not do as well as teams that are composed of a mix of experts, novices, and average players too. Apparently, the range of perspectives for problem solving is broader for more heterogeneous teams. Teams that are too homogeneous, even if they are experts, tend to limit their solutions to their own known problem space. They don’t look outside the box.

So Surowiecki recommends that it might not be the best strategy to hire “The best and the brightest”, but rather we should be looking for people who are smart, but are very different from ourselves. Perhaps we are not looked for the most talented. Instead we should seek unskilled people who are new to the business, Average folks who come from different domains, people who see things differently.

This confirms an intuition of my own: teams composed of average talents consistently outperform teams composed of superstars. For a while, I thought it was just me. In my own experience, I’ve never been all that successful when I’ve worked with the “best and the brightest” for a team. In fact, it’s usually a recipe for disaster. On the other hand, when I have worked with a team of people who were competent,  but not especially remarkable, we’ve achieved some pretty remarkable things. Hmmm…This Surowiecki guy might just be on to something there.