There is a long running debate regarding the use of story points vs. ideal days for estimating backlog items, both positions supported by many good arguments. In my practice, I actually use both. Here’s how.
First of all, no matter what units you end up using, the purpose of estimations is to provide some understanding of the project’s schedule and cost based on its scope and available resources.
The best thing about story points is that they are absolutely disconnected from real time. You can say that your team will complete 10, 50, or 100 points in the sprint, and nobody can ever blame you for coming up with wrong estimates, since a point doesn’t mean anything. What points reflect in reality are relative sizes of stories and the volume of stories the team completes per sprint.
However, every time we put together a new team, I have a hard time explaining what the heck a story point actually is. In my experience, it is very difficult for people, regardless of whether they have come across the concept of a story point in the past, to start estimating a new product backlog by picking the smallest story and comparing it to others. I have noticed several general cases that make it hard or impractical to use points:
When confronted with these kinds of cases, teams often feel that a points-driven approach is inadequate. I have found it useful to introduce the concept of absolute ideal days in order to enforce structure estimation practices. This is how I use it: at the release planning phase, when we are required by the customer to provide a high-level estimate for the entire backlog, I ask team to assume that one story point is one ideal day. This means that a story estimated at 1 point can be done (designed, developed and tested) in one day, assuming no distractions or breaks. This helps me build some measurement scale for the team. I use additional techniques like Fibonacci rows to avoid micro-estimating (trying to breakdown stories to tasks to estimate them) and planning poker to level out different team members’ knowledge and skills. Ultimately, with complete estimates of the backlog in hand, I can add up the ideal days to assess the schedule and cost. Even without knowing the team’s past performance we can usually come up with some kind of load factor for the team (to borrow a term from extreme programming) using risk and contingency considerations.
However, we don’t use ideal days for the entire life of the project. Once the project is committed, I simply don’t need the tie to real time anymore. After work gets underway, the only two things under our control are team velocity and scope. To track velocity, we can easily use the number of points the team completes per sprint. Scope can change significantly over the course of the project, affecting schedule and cost. If the initial project commitment was 100 story points, then adding, say, 30 more points’ worth of work will likely have a costly impact. If both the schedule and the costs are kept to their original levels, I will need to replace a bunch of original stories of the same size. Alternatively, if the customer is flexible about budget and timeline, we can add the appropriate number of iterations to implement the new stories, and that can also be done with points, with no need to revert to ideal days. The team will get into it once they get going, usually after 3 to 5 sprints, as they learn how to compare stories with each other, identify the smallest reference stories and break up bigger ones before estimating them.
So to sum up, I do believe that story points work; I just don’t believe they work equally well for all team and situations. Sometimes you need to come up with a ‘hack’ to kick off the estimation process.
What hacks do you use to estimate projects and get them done in real life?