User Stories Should Be *Estimatable*

Agile User Stories should be EstimatableUser Stories should be possible to Estimate.

If you follow the other aspects of the ‘Invest’ acronym, chances are they will be. The *E* in ‘Invest’ stands for Estimatable; another useful way to measure whether a User Story is good or not.

So what are the potential barriers to a User Story being Estimatable?

Too big?

Maybe the story is too big? In this case, simply break it down into multiple User Stories, until it is more reasonable to estimate.

Not enough information, or requires domain knowledge

Maybe there is not enough information, the story is too vague, or requires domain knowledge to properly understand what is meant? In this case, there are 2 aspects of the Scrum agile development method that help with this issue…

Firstly in the Sprint Planning Workshop (Part 1), discuss the requirement as a team with the Product Owner and/or user representative. Do not attempt to estimate it until you feel you have clarified it enough to really understand the requirement. Capture some further information or notes on the User Story Card.

Secondly, in the Sprint Planning Workshop (Part 2), break the requirement down into tasks; ideally tasks of less than one day. Do this as a team. Breaking the requirement down will obviously help to estimate it. Breaking the requirement down into tasks of less than one day will make each task more predictable and the estimate is likely to be more accurate as a result.

Doing both parts of Sprint Planning just in time, just before a Sprint, and involving the whole team, will help to ensure that everyone on the team understands the requirements. And, importantly, the information will still be fresh when the feature is being developed and tested.

New technology or not enough knowledge in the team

Another potential barrier is that the product or specific User Story may involve new technologies that the team has not worked with before. First this means the team will be less productive and may not be able to rely on their past experiences. Second it means the team simply may not know how to implement it.

In this case, someone in the team needs to be able to complete a brief research task before the User Story is estimated. This research needs to be time-boxed and they need to do only enough research and/or prototyping to estimate the work more reliably. This should ideally be done during the Sprint Planning cycle if at all possible, or if it’s going to take longer should be done early in the Sprint before the story is committed in the Sprint Backlog. It’s worth having a few User Stories in reserve, either as stretch tasks or in case the research determines the story cannot be accommodated in the current Sprint. In Extreme Programming, this research task is called a ‘spike’.

So, now let’s look at my recent Example of a User Story and see whether or not it feels like it’s Estimatable?

It’s certainly not too big. It’s very familiar and doesn’t require any domain knowledge. We all know how to log in to systems and know what to expect. I don’t think it’s vague. In fact, I think it contains quite a lot of information for such a small card. Technically it’s straightforward. And in our case it was being developed in familiar technology. So I’d say this example is dead easy to estimate, so the story – at least in this respect – is good.


Share on facebook
Share on twitter
Share on linkedin

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Posts

Six Actionable Nuggets of Advice for Becoming a First-time Technology NED

If the pandemic has taught companies anything it’s that tech is not something that you put off and think about ‘later’. The last year has seen organisations go through huge digital transformations, whether planned or otherwise. And for those that aren’t technology-based companies, getting the right board-level advice can not only be hard to find, but the difference between success

Read More »

Culture, Skills, and Capabilities // How to become a more data-driven organisation

In our whitepaper “How to become a more data-driven organisation”, we wrote about the five steps that an organisation would need to take, which are: Outcomes: Defining goals and metrics to ensure clear and measurable outcomes Analytics: Implementing and sharing the analytics to improve data-driven decision making Innovation: Testing assumptions through hypothesis testing and learning Data Platform: Gaining new insights

Read More »

Data Platform // How to become a more data-driven organisation

This is the fourth article in our series on “How to become a more data-driven organisation”, and we are going to be focusing on Data Platforms. It is at this point that most people start to dive deep into the technical aspects of Data Lakes vs Data Warehouses, but we want to bring us back up a level and ask

Read More »

Search the Blog

Agile Management Made Easy!

All About Agile

By Kelly Waters

“’Agile’ is one of the biggest buzzwords of the last decade. Agile methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. is one of the most popular blogs about agile on the web. ”

Kelly Waters

Agile 101 is available to purchase. GAME ON!

Agile 101

Emma Hopkinson-Spark

“Whilst there are lots of ways you can vary the game depending on the teams you have and the learning outcomes you want, the basic flow of the game play is common to all.”
Emma Hopkinson-Spark

Why did we make the game?

How to play the game?


101 Ways Limited
145 City Rd
United Kingdom


101 Ways BV
Weesperstraat 61-105
1018 VN Amsterdam

Contact Us

If you would like to get in touch with one of the team at 101 Ways, then please fill out the form below or email us at