Story Points
Don’t use hours to estimate a requirement or feature. Your estimate will be wrong, but you’ll be held to it. Instead let’s use story points. Story points are values that only have meaning within a given team. That meaning is developed, learned, and refined over time.
To understand story points, let’s look at something similar that we all understand.
Restaurants are rated on a scale of 1 to 5. That star rating conveys a lot of information. With that star rating you know the following:
- Quality of food
- Attire
- Price
- Wait time for food
- Will there be valet parking?
- Will there be a waiter or do I order at the counter?
- How customizable will the meal be?
- How knowledgeable will the staff be?
If I tell you we are going to a 5 star restaurant, I bet you could answer all of those questions with a high degree of confidence. You would not know precisely how much it will cost, but you’ll have a ballpark feel for it. If tell you we are going to a 2 star restaurant, again, I bet you have a pretty clear expectation.
If instead of the star rating, I just told you that the food was really good, would you know how to dress? If I just told you that it was very reasonably priced, would know if you were ordering at the counter or talking to a waiter. If told you that meals were $50 a plate, you might guess that it was a 4 or 5 star restaurant. But in reality it could be a 3 star tourist trap on an island that has only 1 restaurant and has to fly all of their food in from the mainland. The point being is that knowing only one dimension can sometimes you get close to the right answer, but can also be quite misleading and dangerous.
Story points allow you to embed information from lots of dimensions into the numeric value. We might embed the following dimensions into our story points:
- Coding effort
- Complexity
- Risk
- Knowledge of technology
- Quality of the domain expert
- Platform
- Usability requirements
So maybe we can setup story points like the following:
Example:
- 1 point = easy, straightforward feature
- 2 points
- 3 points = moderate, somewhat complex feature or contains some moderate risk
- 4 points
- 5 points = hard, complex feature, that may contain high risk
These are just guidelines to get started. Story points develop meaning over time. Just as with restaurants, it took experience with restaurants before you understood the rating system.
In that one number you can embed any additional information or padding that you may need. If you estimate everything in hours you will be challenged by people who don’t know better. If you assign story points to things, you can use your intuition or any other knowledge to pad your estimate without getting into a debate with those who don’t understand.
Each developer will bring a different intuition to assign story points. Some will be junior developers who spend most of their time focused on technology challenges. Others will be senior architects who are assessing risks and future complexities far outside the experience of the junior developer. Story points serve to normalize those large differences in experience and perspectives across the team.
Story points are a tool. When used incorrectly you will get bad results. Story points only work when the project is being managed in the Scrum (or similar) methodology. They work with time boxed sprints and user stories. If you are doing time boxed sprints and user stories, then you may not get the desired results.
