User Story Estimations

Should we estimate complexity (what if something is complex but doesn’t take too much time)

Should we estimate effort (what if something is straightforward and easy but takes a lot of time)

Going back to basics on estimations (seminal work by Mike Cohn), here are some points on how to estimate better. I have quoted Mike Cohn at some places(italicised) so that I don’t stuff it up:

1. What to Estimate

The number of story points associated with a story represents the overall size of the story. There is no set formula for defining the size of a story. Rather, a story point estimate is an amalgamation of the amount of effort involved in developing the feature, the complexity of developing it, the risk inherent in it, and so on. No matter how much effort you put into an estimate, an estimate is still an estimate. No amount of additional effort will make an estimate perfect.
The story is looked as a whole and not piecemeal (iOS, PHP, QA, etc.). When we say “developing”, we are referring to end-to-end development (QA included) and delivering it to the PO / client.

2. Effort-Accuracy Curve

Till an extent, the estimate continues to improve as you put more effort in trying to be accurate. After sometime, the “law of diminishing returns” kicks in which means that the improvement in accuracy is less as compared to the amount of effort being put in. One should stop before this point is reached.

3. Estimates are Shared

Estimates are derived collaboratively by the team, not by a single person. Even though one might be tempted to go with the estimate of who would do the job, the team’s estimate is preferred. The people most competent in solving the task should estimate it.

4. Buckets of Water and Sand

Rather than thinking of work as water being poured into the buckets, think of the work as sand. If you are estimating using 1, 2, 3, 5, and 8 and have a story that you think is just the slightest bit bigger than the other five-point stories you’ve estimated, it would be OK to put it into the five-point bucket. A story you think is a 7, however, clearly would not fit in the five-point bucket.

5. The Right Amount of Discussion

Some amount of preliminary design discussion is necessary and appropriate when estimating. However, spending too much time on design discussions sends a team too far up the accuracy/effort curve of the graph. The question is this – would that extra discussion change the estimate a lot? Can we skip that and check the finer details with the PO during the Sprint?

We can start time-boxing our discussion. We start a timer (for say 2 minutes) and discuss. At the end of the time, we draw cards. If there is a lot of variation, we again start the timer to sort out the variation and then draw again. By this time, the estimates need to start converging or the outliers can consider compromising for team’s sake unless they have a strong point for not doing so.