Agile antipattern: Taking on large stories

Earlier this week I posted a blog entry “Agile antipattern: Burndown charts that hide the truth” which dealt with one way a burndown chart could hide reality.  This blog entry shows another way it is possible for a burndown chart to be misleading.  The burndown chart to the left is actually pretty common, especially for teams just starting with an agile process.  In this case it looks like no progress is made for quite a period of time, then everything suddenly gets completed.  Even though this team completed all the stories in the iteration it is still an unhealthy burndown chart.

In this particular case the team had filled their iteration with “large” stories.  Notice the stepped nature of the chart.  A very healthy agile team will usually complete stories nearly every day of the iteration which leads to a chart with a downward slope, not a stepped type of line.  When I see steps like this I worry about the size of stories.  In this case there is a second factor which almost certainly points to the stories being too large: no stories are completed during the first 4 days of the iteration.  Taken together these factors almost always point to stories that are too large.

Specifically what do I mean by stories being too large?  I usually instruct teams to take their iteration length in work days and divide by 3.  The resulting number is usually a good number of days of work to average on a per story basis.  So, for a 10 working day (2 week) iteration if stories average getting completed in 3-4 days (people days, not calendar days) then they are the right size.  Because more than one person should be working on each story (you are swarming, right???) this means stories will be completed almost every day.

As the average size of a story gets larger the ability to complete a story every day is compromised.  For example, if the average story creeps up to 6 days, even with 3 people working on each story it means the average story will take 2 calendar days to complete.  In other words we’ll be completing stories every other day, not every day.  Certainly some can be completed in a day, but others will take 3 days (so the average stays the same).  This gets worse if the number of days to complete a story creeps even higher.

Why is this such a big deal?  Because larger stories tend to get harder to complete within the iteration when they are started later in the iteration.  An image I use in my courses is one of a Tetris game.  Imagine you have built up some blocks (completed stories) and there are now holes which are certain sizes.  Do you want large complicated shapes to fall, or smaller, simpler shapes?  Of course the small, simple shapes are easier to deal with just like it will be easier to deal with smaller stories.  The more complicated the shapes later in the iteration the harder it is to make them all fit and the more likely we are to fall short of our commitment.

Teams fall into this trap quite easily.  If a team has 8 members and velocity for the team is 40 it seems like the team can complete 3 stories of size 13 and 1 story of size 1.  That adds up to 40 so it should be possible.  Unfortunately, the 3 large stories make this scenario very unlikely to be successful.  If 2 people work on each story then the size 1 story gets completed very quickly, but only 6 people can work on the 3 large stories while 2 people sit around and do nothing.  Team capacity is wasted which means the stories won’t get completed.  If we say 3 people can work on a story then we still have the problem but in a different way – now we don’t have enough people to finish the large stories which are each 1/3 of the work in the iteration (we would get 2 of them done but then just have 1/3 of the iteration to get the other done).  As you can see, big stories can cause big problems.

Now that we know we have a problem, we have to solve it.  A typical planning poker deck of cards contains some very large numbers.  For this reason teams seem to think they have to use those numbers.  DON’T!  In fact, the fix I would suggest to stay away from large stories is to burn all cards higher than a 13 (maybe even 8 and higher) and never use them during planning poker.  If a story is larger than your new largest size, split it.  Oh yeah, you don’t know how to do that part.  That’s ok, read my next blog entry which will be on splitting stories!

Until next time I’ll be Making Agile a Reality^® by burning lots of planning poker cards!  I hope you do too!