When estimating a project using the Planning Poker method, many developers like to use a baseline estimate for a given task. For example, many developers use CRUD, the creating, displaying, editing and deleting of a Model as their baseline estimate. Once they’ve got their baseline in mind, it makes it easier to estimate other stories that are more domain specific, or so it seems. This is a common agile estimating mistake.
Baseline estimates are broken
When you’re using a task like CRUD as a baseline for your estimations, you can easily skew the estimations of the other stories in the project. Let’s say we’re using a 3 point baseline for CRUD stories.
As a user I should be able to upload a profile photo– 2
As a user I should be able to CRUD movies I’ve seen– 3
As a user I should be able to send a private message to another user– 5
As a user I should be able to create a trivia quiz for a movie that I’ve seen– 8
In this first example, the stories are probably estimated fairly well and compared to each other, the complexity is quite relative. What happens if we add a few more easy stories or a few more difficult stories?
As a user I should be able to see a contact e-mail on the home page– 1
As a user I should be able download the menu as a PDF– 1
As a user I should be able to CRUD restaurant reviews– 3
With easier stories added, the CRUD story is definitely the most complex, but compared to the others it is significantly more complex than seeing a link on a page or viewing some text.
As a user I should be able to CRUD portfolio photos– 3
As a user I should be able to signup for a paid recurring account– 8
As a user I should be able to make connections with other users via Facebook– 13
As a user I should be able to send a rocket to the moon– SPIKE!
When the other stories become much more complex, the CRUD task is again shown to be significantly different in complexity, this time in the other direction. In this group of stories its hard to imagine that managing portfolio photos is only two orders of magnitude away from a recurring payment e-commerce system.
Relative Complexity Works
Its important to estimate a group of stories so that the complexity of each story is relative to the next. In Mike Cohn’s Agile Estimating and Planning, he describes a method of estimating stories called “Analogy”.
When estimating by analogy, the estimator compares the story being estimated with one or more other stories. If the story is twice the size, it is given an estimate twice as large.
When you apply this technique to your estimation process, you will have a more coherent set of estimates. From this you will be more likely to determine an accurate estimated velocity and you will have a better overall sense for the scope of the project.
Hurdles to Estimating by Analogy
- Estimating all of your stories one by one makes it difficult to estimate a relative complexity as you only have the previously estimated stories with which to compare your current story. A group of especially simple or complex stories could be waiting towards the end of the sessions.
- Estimators who are new to the agile estimation process might have difficultly estimating a story without a point of reference.
- Estimating with a baseline can be a difficult habit to break since it provides a convenience and familiarity to the estimator.
- Two seemingly similar projects may have a greater than expected difference in total number of story points, even though their velocities are relatively the same.