User Stories Should Be *Estimatable*
by Kelly Waters
User 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.
Kelly.
17 September 2008 18:51
Actually, the "E" stands for "Estimable". "Estimatable" is not actually a word!
-- Your friendly neighborhood pedant
17 September 2008 19:57
Well I never knew that! Thanks Anonymous, I stand corrected.
Kelly.