I was skimming through Agile Estimating and Planning by Mike Cohn. I’ve used his idea of story points in the past versus using ideal days to estimate product backlog items.
Story points are just relative measures of the effort involved in estimating a user story. We write up use cases and not user stories, but the idea is generally the same since we’re often estimating the ‘happy path’ of a use case or one of the major alternative paths on our product backlog.
Ideal days are assuming you had uninterrupted time to work on a task and you had everything you needed at your fingertips how long would it take. It’s a little more concrete then story points, but the lingering issue is that ideal days assume a duration.
Mike uses an analogy about ordering at a new restaurant. Generally you don’t know any of the exact sizes of items. You can:
- Order a small, regular, or super size drink.
- Order cup or a bowl of soup.
- Order the lunch version of the pasta or the regular entree.
None of these items gives you any exact measure of the size or even how many ounces are in the drink or how much larger or smaller the lunch version is. Still you can very easily order the right amount of food without knowing anything but relative sizes.
At the end of the day though I prefer the story points approach. Story points are a pure measure of effort.
Ideal days bring with them the baggage of time durations. Since things are measured in days there is always the temptation to think about them as durations and forget about the fact that they are supposed to be ideal days and not actual days. Observers to a project may find this to be the most troubling as they can easily get the mistaken idea that the team is underperforming given the number of days the project should get done in.
The other big downside of ideal days is that it potentially reinforces troubles developers have estimating already. Many developers are tilted towards optimistic estimates. My rule of thumb when a developer gives me an estimate is to simply double it, because they are thinking in their own semi-ideal days. After I know a developer better I tend to adjust, partially because there are a few other developers who estimate very pessimistically so that they aren’t ever in danger of missing a deadline. Anyway, keeping them thinking about days instead of ‘Adding an Approval Workflow’ is about twice or three times more work than ‘Maintaining Employees’ breaks the connection to time estimating.
By default right now we’re using ideal days to measure product backlog items. I’ve used story points on at least two past unofficial Scrum projects, and I’m going to experiment with it again on the second sprint for our intranet portal.