The Path to No Estimates

Estimating is part of (almost) every project. It takes a lot of effort and more often than not is not accurate, predictable or flexible.

I remember filling in Gantt charts and entering dependencies between tasks, trying to guess the length of the unknown and using magical breakdowns to justify decisions. The result? Disappointment and an increase in stress.

What lies between “It will take as long as it takes” and “Create task breakdowns for everything”?

Can we be more predictable? I do think so, but it requires learning, discipline and a profound desire to improve things.

Becoming repeatable

Software is not repeatable. Requirements are not fixed or static; they are like an untamed beast that changes shape, color and size every time a feedback cycle is complete—sometimes even sooner.

Features will change no matter what and we must learn to accept and embrace that reality.

We could keep trying (and failing) to do task breakdowns and tackle the unknown with the empty promise of “Don’t worry, nobody will make you accountable for this!” as comfort.

Experience is the name everyone gives to their mistakes. —Oscar Wilde

Instead of focusing on forcing reality to become what we need, let’s put the focus on capturing requirements in a way that can help us find our capacity (i.e., how many requirements we can work on at the same time) and consumption rate (i.e., how many requirements per week/month/etc. can be completed).

The requirement unit

Choosing how to capture requirements wisely is very important. I prefer to use user stories to capture functionality because user stories are short and concise, and finding all the details gets deferred until it is time to implement the story. Another important aspect is that each user story must provide value to the user.

Combined with a Story Map and a Kanban board user stories help me to manage releases with accuracy and keep the projects on time and budget. But this is a story for another post…

Once we get really good at writing user stories (so that they’re not too specific or not too vague), we need to figure out how to tell when a story is too big and needs to be split into more stories.

Deconstructing story size

If we manage to write stories that are around the same length then estimating each story is not as important anymore.

However, complexity is very hard to identify sometimes. We can discuss a story for hours and still the complexity of it may stay hidden until implementation later on.

Flushing out functionality means that we need to define what we expect the story to do. In other words we have to write the acceptance criteria.

The acceptance criteria are the steps that are going to be used to ensure the story is what the user wants. This sequence of steps is often called the scenario.

A single story can have multiple scenarios that represent possible execution paths of valid acceptance criteria.

For example, here is a user story to sign in to Amazon.com:

As a User I want to sign in to Amazon So I can look at my order history

For this story I can think of a few possible scenarios:

Given I am a registered user When I sign in Then I see my order history

But also:

Given I am not a registered user When I sign in Then I see an error message

And maybe:

Given I do not remember my password When I sign in Then I should see an option to reset my password

Even further:

Given I asked to reset my password When I confirm the reset instructions Then I can sign in with the new password

You can probably think of even more scenarios. Now the question is, are all these scenarios part of the user story?

My personal recipe (which you can use or create your own) is:

• More than two scenarios means the story is too big, so the story should be split.
• If a scenario provides value on its own it can be split.
• Stories should be completed every day or so. If, after a day, there’s no assurance that it will happen then the user story should be split.

I think the first two user stories about signing in can go together—they are part of verifying the user’s credentials. For the other two scenarios about resetting the password I would create two more stories.

The hidden complexity

We started with one story and now we have two more. And that is only while doing Analysis. During implementation it could be that we find the story to be more daunting than expected. Using the same recipe, after half a day or so the developers should have an inkling of how close they are to finishing.

Nope, they have no clue, you say? Well, that is a clear symptom that the story is not as simple or straightforward as we first assumed.

What should we do? Choose a simple scenario in order to finish the story, and then discuss what the other missing scenarios are and create further stories from them?

Furthermore, even after implementation, during QA, it could be that whoever does the review finds scenarios that were not considered the first time around, which is natural. Discuss them and create more stories from them.

The never-ending user story

Finding new stories can happen at any time during the software construction life cycle. That is the nature of the beast.

So how much further along are we on the path to no estimates?

Following the scenarios technique we can replace estimation meetings of unknown functionality with writing scenarios before building a story (meetings are optional).

Estimation is based on our speed and capacity. Planning should ensure that the most valuable stories are done first.

When more stories appear a decision has to be made: Do we need them in the current release or not? The answer to that question will impact the current release timeline or a future release timeline.

Fluff, fluffy & fluffery (Where is my Gantt chart?)

It is quite common to start a project with a period of analysis to find requirements in order to provide an initial estimation.

Instead we could use the same amount of time to start delivering value by implementing the first set of stories. That way we can flesh out a preliminary architecture and discover how fast we can go with the current team, environment, etc.

Though it is true that not all requirements will be captured (that would happen anyway), your team will be much more confident in providing a range of timelines (if you have to) and making that range smaller and smaller every month.

The big gain is not about having a magic formula to provide an estimate after reading two pages of features, but to become repeatable so you can focus on the only factor that can be stretched or shortened: scope.

High Anxiety

Feeling confident about finding scenarios and discovering complexity is a learning process that takes time.

As a team you will need to work together to discover the best way to introduce these new concepts.

Using both techniques for a period of time may help you to reduce the stress of “no estimation” and make the correlation between scenarios and complexity clear and intuitive.