Dec

14

Some ideas that seem perfectly sensible are really disasters waiting to happen, and agile teams are not immune. I’ve started to notice some frequent mistakes that inexperienced, and sometimes not so inexperienced, teams make when they’re trying to be agile. These things seem like perfectly good, common sense ideas, but they have undesirable consequences, and we’re going to see what those consequences are.

It’s surprising to me that making the sprint longer is such a temptation to a project, but it is. There are lots of reasons that people give for wanting longer sprints, usually it boils down to “we can’t get our work done in two weeks, but if we had three, we could get it finished.”  When questioned about why two weeks isn’t enough, testing seems to be a common sticking point. “We got all the development done, but couldn’t get it tested in time.”

There are a variety of reasons why shorter sprints are desirable.  Shorter sprints allow a team to be more agile in response to changing requirements, for one.  If our project’s requirements aren’t stable, then planning two weeks at a time mean that it’s easier for us to accommodate new requirements without disrupting a sprint.

Another good reason for short sprints is it allows us to get more data points early in a project, and for short duration projects this means we have a better idea what the velocity of a team is sooner. If your project is 3 months long, and you have four week sprints, you’re going to be roughly 33% done before you have any idea what your velocity is, and thus how much work you might be able to get done before you run out of project time.

I also think that short sprints are easier to plan.  I have a pretty good idea what I’m doing this week and next, but a pretty fuzzy idea what I’m doing next month.  Earlier this year, I watched a video from the TED conference in which Dan Gilbert talks about mistaken expectations. It’s a 20 minute or so video, and worth watching all of it, but the point that really resonated with me occurs about 19:20 into the video, when Dr. Gilbert is talking how time alters our perception of differences between values.  The gist of the message I took away was that our perception of differences is affected by how far in the future we’re comparing things: the further in the future, the more things look the same.  I think this also shows up in sprint planning: we’re pretty good at understanding how much time is available in two weeks, and how much we can get done, but less good at understanding how much work we can get done in a month.

So there are good reasons to prefer a short sprint: we’d like to have a better estimate, we’d like to get more data points for our velocity, and we’d like to be more responsive to changes in requirements without disrupting the flow of work.  Despite this, teams protest that they can’t get done with work in a short sprint. How, without making the sprint longer can we get more work done?

In order to answer the challenge, we need to understand why teams aren’t getting stories done in two weeks.  Many teams seem to bring large stories into the sprint, and then have difficulty completing it.  One approach that can be successful in this scenario is break our stories into smaller ones.  Rather than buying a single monolithic story that we expect to take two weeks, break it down into two or even three stories that will take less than the full duration of the sprint.

Another problem is when teams have stories that are small enough for the team to complete, but they decide to have various team members work on different stories in parallel.  This ends up looking similar to teams that have stories that are too big, you don’t know what kind of trouble you’re in until the end of the sprint.  In this case, I encourage teams to put as many people as make sense on the same story, and only when we’re getting in each others way start working on other stories. I tell them it’s better to have one story completely done than two mostly done.

There’s one final caution I tell teams that want to make their sprints longer, so they have a better chance of getting stories done.  Teams that make their sprints longer sometimes just increase the amount of work they try to accomplish, and this just means we have larger stories we don’t get done, instead of small ones.

This is the second post in the Temptations series. The first was Too Many Stories in the Backlog.


Comments

RSS feed | Trackback URI

2 Comments »

Comment by Manoj Vadakkan
2009-12-17 15:57:04

Keith,
Great piece of advice and nicely put “I encourage teams to put as many people as make sense on the same story, and only when we’re getting in each others way start working on other stories. I tell them it’s better to have one story completely done than two mostly done.” Thank you!

Other way around, when team members start working on independent stories the amount of collaboration goes down and eventually start looking like a mini waterfall. Think about the testing person in the team; tester will end up real busy at the end of the sprint and most of the time we will run out of time in the sprint before completing many of the stories.

Manoj

Reply to this comment
 
Comment by Santhosh Sreedharan
2009-12-24 10:16:00

Been there, tried that. I think this temptation is more from trying to comeup with a working app or prototype for the product owner, within the crunched timeline. More or less inexperience in Agile stems this temptation. Incorrectly breaking down a story adds on to this. As a caution, this temptation can be avoided even by development teams if “DONE” is clearly defined and understood by teams and accepted by the product owner. My two cents.

Reply to this comment
 
Name (required)
E-mail (required - never shown publicly)
URI
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.

Blogroll