Uncertainty is good for you

May 22, 2019 by Georg Schild

#agile

Estimations

When working with Scrum, we make estimates on a regular basis. This could be in separate appointments, combined with a refinement, or with the entire team in the Sprint Planning. There’s nothing inherently good or bad about these options – the team decides what suits them best.

In our case, however, it all boils down to Planning Poker and Story Points. Sizing of the estimates is, of course, heavily team dependent. Nevertheless, most teams would say that an estimate of 20 or even 40 points is quite large, assuming it should be finished in one sprint.

This post will try to show why a certain degree of accepted uncertainty is good for agile teams.

How do we estimate?

In order to understand Story Points and the way we use them, we have to talk about the estimation process. An estimate considers complexity, uncertainty and, to a certain degree, also the amount of work – but not plain effort. Effort per se is generally harder to estimate for a group of people than uncertainty and complexity. This is just due to people having different paces – you can’t argue these differences away. Complexity, on the other hand, just like uncertainty, is the same for everyone – after talking about it with the team.

Complexity

Complexity affects different parts of the product and the process.

How many layers of the software are affected by the change?
Are any new and unknown libraries needed?
Does the change affect third party systems?
etc.

After the initial gut feeling decisions when starting a new project, complexity estimations become pretty stable. This is due to the ability of the team to compare new requirements to ones that are already Done. This is also where the estimation of the amount of work kicks in – by comparison with prior work.

Uncertainty

Uncertainty, on the other hand, is a whole new story. When estimating uncertainty, you are talking about things you simply don’t know, or don’t know yet. If what you’re thinking right now is “That ain’t gonna work”, you might want to consider taking a step back and rethink your estimates – uncertainty is an inevitable part of the job.

In the following chapter, let’s talk more about uncertainty and how the level of detail is a valuable tool to handle it.

Uncertainty and the level of detail

Agile requirements are often directly connected to user stories. Yet, most teams will need significantly more than a single sentence to specify their user stories.

There will be acceptance criteria, which are good and make the requirement transparent. However, there might also be a bunch of other pieces of information.

Technical details
Background information
Annotations
Things-to-come(-maybe)
etc.

While the intent of this additional information is to reduce uncertainty, what it actually does is

Reduce the agile requirement of communication
Reduce the degrees of freedom
Add confusion
Create waste (see muda)

From an agile perspective, I am definitely a fan of requirements that fit on a single card. But I also know that this doesn’t necessarily work for each and every situation.

Nevertheless, the point that I want to drive home here is that the level of detail can influence teams in their decision to cap the size of stories within a sprint.

Consider a story, estimated to be 20 SP and described in high detail. Compare this story to one that consists of the same user story and only some acceptance criteria. That one might also get 20SP, but the contract is much smaller. That smaller contract enables the story to fit into a sprint while the minutely specified story might not have.

Why? Because the loose definition enables the team to make implementation decisions at the point in time where the most information is available to them. Based on the time left in the sprint and the hard requirements defined in the user story, they can decide how to get the story across the finish line without having to plan an entire sprint ahead. Since this also involves a lot of direct PO communication, the result will most likely be the best fit.

The greatest thing about this is that reducing the contract might even get you something for free that you didn’t expect: Bigger stories are more likely to be done by more team members in parallel – which is very agile (see 1, 2, 3).