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.


2 Responses to “User Stories Should Be *Estimatable*”

  1. Anonymous says:

    Actually, the “E” stands for “Estimable”. “Estimatable” is not actually a word!

    – Your friendly neighborhood pedant

  2. Kelly Waters says:

    Well I never knew that! Thanks Anonymous, I stand corrected.


Leave a Reply

What is 10 + 5 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”