E is for Estimation.

There is no subject more contentious in technology development than estimation. Over my career, some of the biggest disagreements have been about estimates. I even witnessed a shouting match that almost came to blows. When we write user stories, they should be clear enough to estimate. When we do this, it should foster helpful conversations rather than conflict. Like it or not, estimations are necessary for project success.

Why Business Demands the Clock

I have experience with every type of estimation, from using story points to no estimates at all. I have witnessed executives demand estimates in hours and then seen them treated as quotations for work. Sometimes, deadlines are set by people funding the project with no input from the people doing the work. Each of these approaches has its pros and cons, but the most important question we ask in business is when work will be completed.  Time and money are limited resources in business, so the people paying the bills must know how to invest them wisely.

Once I understood the importance of providing honest, accurate estimates, I was able to have frank conversations with leaders about how long it would take to complete a task. These conversations were never easy, but they helped clarify expectations and, over the long run, prevented misunderstandings.

Demystifying the Estimable Story

So, when we say that a story is estimable, what does that mean? As a Scrum Master, I find that a story is estimable if our development team can provide an educated guess about how long it will take to complete the work. It does not have to be accurate to the hour, but we should know if it can be completed in a sprint. This is why I use story points: they give us the best means to calculate complexity, risk, uncertainty, and effort (CRUE), for which I use the 1980s glam metal band Motley Crue as a helpful mnemonic device.

Dissecting an Estimable Story

The following is an example of a user story that can be estimated.

As a supervisor, I want to see a data grid of my direct reports' TPS survey so I can review the work and audit progress.

01
Given I am a supervisor
And I am authenticated in the system
When I pull up the survey grid
Then I see the TPS survey in descending numerical order
And it is grouped alphabetically by my direct reports' last names.

02
Given I am a supervisor
And I am authenticated in the system
When I pull up the survey grid
Then I see the TPS survey in descending numerical order
And paginated in increments of 20, 50, 100, or 500 records.

03
Given I am a supervisor
And I am authenticated in the system
And I have zero direct reports
When I pull up the survey grid
Then I see an empty grid with no data
And a modal message box saying I have no data.

The story is straightforward and contains a negative case and two pieces of functionality.

The developer reviews the story and explains that they might need a database diagram to locate the information in the system. The product owner or business analyst might say this is not necessary because the system uses RESTful APIs to retrieve information from that database. The developer then asks that the API documentation be included in the story, along with all major methods for retrieving data. Once that information is included, the developer confers with their peers. After some discussion, they say the story is worth 5 points based on complexity, risk, uncertainty, and effort. The story also requires QA review, so they take that into account. The story is ready to be worked on in the iteration because it is estimated. If it is not planned for a sprint, any developer with time on their hands can pluck it from the backlog and work on it when they have slack time.

Remember, estimation does not have to be perfect; it must be an educated guess.

Completing the INVEST Model

So far, we have seen how stories need to be independent, negotiable, valuable, and now estimable.  The 'E' in the INVEST model makes it easier to determine how long a project will take and provides others with visibility into how the team is doing. Clear estimates protect the team from unrealistic pressure and keep delivery predictable from sprint to sprint.

Until next time.