Tasks of a development team often get delayed, proving larger, more complex than estimated. We frequently hear “yeah, it’s almost done, but… (use a valid reason here)”. Stories thought to be a few hours’ work, turn out to be monsters dragging their tail for months. So, how can we avoid this? Sándor Hibsch shares his best practices. Follow along!

In a good team we don’t quite like when this happens. Blaming the outside world, or relaxing our rules (“we’ll carry on in the next sprint”) are certainly options here, but we don’t want to lose control, because then we would:

• limit our future options – by working on such items instead of more valuable ones
• increase risk – by running into a similar scenario a few days before an important deadline
• decrease predictability – not being able to work in a sustainable pace, indefinitely.

MAPPING THE PROBLEM

When we recently managed to close a story after three sprints (original estimate: a few hours), we wanted to understand what happened. When we plotted the timeline, we noticed something strange: we always thought we were almost done, so we kept on working:

SUNKEN COST FALLACY – “we have put so much effort in – the remaining effort must be small”

Then we plotted all the branches and dead-ends on the timeline to observe how complexity kept increasing:

INCREASING COMPLEXITY TRAP – branches and dead ends during implementation

HEURISTICS TO THE RESCUE

Complex problems don’t give in easily. “Every case is different,” we say. And while that’s true, this is precisely where heuristics come into play to help guide us. We started looking for questions emerging from our past experience, promising to help manage risk and keep us in control by asking them repeatedly. Here is what we came up with:

BEFORE (PLANNING)

• How knowledgeable are we in the specific technology? Is there unknown technology involved in the implementation?
• Are there dependencies? Do we need help from another team? Are we dependent on an external system?
• What is our gut feeling? Seriously. Is the story suspicious? Have we encountered a similar situation where the story looked small and grew to be way too big?

If you get several uncertain or negative answers to these questions, it’s worth stopping and replanning.

DURING (IMPLEMENTATION AND TESTING)

• How many times did the scope increase? The third time we stop the story and do a spike – i.e. research and learn about the problem. The third time we stop the story and do a spike – i.e. research and learn about the problem.
• How many times did we say “I’ll finish today”? The third time we stop. Spike.
• How critical is the delivery? It sounds contraintuitive, but if it’s very critical, you need to slow down. So we stop and do a spike.
• Has someone said “it won’t happen anymore”? Stop, do a spike, do knowledge sharing. Because it will. Stop, do a spike, do knowledge sharing. Because it will.

AFTER (POST-MORTEM)

• Retrospective – look back on the story, reflect and learn, then decide what to do differently next time.
• Case study – document what happened, to ourselves, maybe for others too. What decisions did we make? What difficulties did we encounter? What was the solution?

Heuristics are not magic bullets, but they help us become aware of the dangers of procrastination before it’s too late. The above has helped us make the team more predictable, reduce team member frustration, and keep options open.

How would you expand the list?

*A heuristic is a way of thinking that helps you solve problems quickly and efficiently, but it doesn’t always guarantee the best or optimal solution. It doesn’t rely on strict logical conclusions, but on experience and trial and error. Think of it as a shortcut that leads to an acceptable result, but not necessarily the shortest or best path.