Right-sizing iterations

Have you ever kicked yourself when a release doesn’t have as much in it as it could because some stories were undersized, took longer than expected and stole the time available? To avoid this, I’ve started continually re-sizing stories and right-sizing my iterations so I can deliver what’s important.

Introduction
On a number of Agile projects I’ve noticed that some stories explode and take much more time than planned, forcing important features to be dropped, architecture to be compromised or delivery dates moved back.

On recent projects I’ve taken a much more proactive hand in ensuring that the business sponsors get what they want. Rather than waiting for the project to slip into lateness, my teams have started to keep track of the state of each story – catching the risky ones before or as they bloat and consume more time than they should.

A little background
On many Agile projects, stories add up to iterations and iterations add up to the functionality needed for a release. If you want an on-time, on-budget release each iteration needs to complete all planned stories.
If you are regularly releasing into production every iteration, stories that run longer than estimated can significantly impact the features you can deliver in time.

Why do I care? Re-planning is Agile right?
Absolutely, a plan is just a idea of what might happen, not a commitment, and release a plan is a prediction of what can be delivered within a budget or by a release date. However the business function is often more concerned with delivering the major chunks over having everything that could potentially be in every story.
If the team does not actively constrain the time a story takes, odds are that the team will never deliver to expectation.

Continual resizing
What I’ve been doing recently is actively ensuring that the stories in each iteration fit into that iteration.
Some variation in the time it takes to deliver a story is expected and I expect that usually it will simply average out. However if we have a few stories that are likely to overrun, or any story that’s looking to explode then its time to do something.

How does the team spot the overrunning stories?

• When starting a story the pair take a quick look and decide how long they think it’s likely to take.
• The team tracks the time spent on each story on the story card, so we don’t forget.
• As the story is coded we take checkpoints on how the development is preceding and the expected time left. We often do this in the daily stand up.

For the stories in the current iteration, we compare their expected sizing with the duration of the iteration. If the iteration is looking over committed, we try to ‘right size’ it.

So I’ve spotted some overrunning stories - what could I do?
I look at what is causing the explosion and find what can reasonably be compromised.

• Can we do the same some way simpler?
• If we share the problem, can the team solve it?
• Are we working in the wrong way? Can we be smarter at solving our problems
• Are all the requirements for the story really needed?
• Are all the requirements for the story equal in priority? Can we split requirements out into new stories to be played later?

Dropping functionality from a story shouldn’t be done lightly; it should be an option only after the team has considered what they can do to get the story done.

Stories are a conversation – remember to negotiate.
What’s important is the negotiation. We have a time or a budget for the delivery – that’s usually more important than any specific requirement on any story.