Agile antipattern: Taking on large stories

sprintburndown3Earlier 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.

tetrisWhy 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!

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

  1. Large stories are also a challenge because I tend to find the estimates get less and less accurate the larger the story. I have some actual feature charts from a project posted at the bottom of the page here, and it would seem to corroborate your quest for more granular story completion rates đŸ™‚

  2. Very good point.
    I just have a different thought about the final suggestion: instead of ‘burning’ card number 13 and higher, we could ‘burn’ cards which represent an effort of more than 4 or 5 days of work.
    The reason: points vary from a team to another, so ’13’ is not necessarily high number.

    Congrats for the post đŸ™‚

    • Eric, good point and I agree on burning anything that equates to more than 4-5 days. In my experience it has been VERY rare (actually I can’t think of a single team where this has been true, but I’m assuming I just don’t remember it) for a team to have a size 13 that corresponds to 5 days or less of work. Great catch – thanks!

      – Bob –

Bob Hartman

Known as Agile Bob, brings over 30 years of experience and broad industry knowledge cultivated by serving in almost every role in the software industry including developer, tester, documentation writer, trainer, product manager, project manager, business analyst, senior software engineer, development manager and executive. Over the past 15 years Bob has grown from being an early adopter of Agile to his current status as a Certified Scrum Trainer® (CST) and Certified Enterprise Coach℠ (CEC) and an expert in training, coaching and mentoring across all areas of Agile development. Bob is a popular speaker, having spoken at numerous major conferences, seminars, workshops and user group meetings where his engaging style, holistic view of development and personal anecdotes are always well received by attendees.

Connect

bob.hartman@agileforall.com Twitter LinkedIn Subscribe to RSS Feed Blog posts by this author