User Story Estimation
Agile approaches prefer to use a simple estimation technique called Relative Estimation.
Consider this stack of books:
If you estimated the number of pages in each book, you would have some very precise numbers. You would also most likely be quite incorrect!
What if you took one book – for example the one on the bottom – and said it had a size value of 1. Then, you estimated the size of the rest of the books relative to that first one – for example, the book second from the bottom would be 2 or 3 times the size of the bottom one. The next book up, the thickest, would be about 5 times the size. While these estimates aren’t very precise, they are probably much more accurate than attempting to estimate the number of pages, and you can perform the estimation very quickly
We can apply this same approach to estimating Stories. We take a single Story and use it as the baseline – often one that isn’t the smallest but isn’t the largest either – and give it an arbitrary value of 2. We then take each Story that needs to be estimated and compare it against the baseline in terms of the total amount of effort required by the whole team to complete that Story to satisfy the team’s Definition of Done.
If the Story being estimated is considered to require more effort to complete than the baseline Story, give it a value of 3. If the effort is less, then give it a value of 1. If the effort is considerably larger and the team isn’t comfortable with a value of 3, you should look at ways to split the Story further until the smaller Stories can have values of 1, 2 or 3.
Note that the team members estimate the effort involved to implement the User Stories. This is an important point, because traditionally the team has had estimates imposed on them, or the estimation has been performed by a small group of experts. By ‘owning’ the estimates, the team members not only have a vested interest in meeting those estimates, but they also tend to make much more realistic estimates in the first place.
If the team doesn’t feel comfortable providing an estimate to a Story, it’s likely because they don’t know enough about it. In that case, they ask the Product Owner for more information. This can result in the developers having enough detail to provide the estimate, or that the Story may need to be split into multiple stories.
Estimation Example
This is a sample user story for defining a Customer Discount Rate:
The problem with this Story is that it’s too large. There are a couple of concepts here that need to be split out into separate stories:
This provides just enough detail for everyone involved (Product Owner, Developers) to agree on the importance of the story, and for the Developers to create a reasonable estimate of the time required to implement it. It doesn’t delve into any specific details about how the system performs the action, any validations required, etc. These are left until the Developers are creating the programming tasks, and consult the Product Owner for more details.
Having said that, there still isn’t quite enough detail in the Preferred Customer story. During the Release Planning meeting, the Developers would likely ask the Product Owner, “When do you start counting the $50,000?”
With the answer in hand, the Story is updated by the Product Owner, and the Developers provide their estimate:
These posts may also be interesting...
Smaller User Stories?We are the Borg
Every little thing
What problem are you trying to solve?
There’s a new look around here
Product Management
comments powered by Disqus