Story Point Estimation in the Real World

When the initial team of developers at Ring Seven was asked how they want to report progress I heard all sorts of passionate push-back.  I heard things like software is impossible to measure, I don’t want to be micromanaged, hours are too cumbersome to report. I agreed with several of the problems with hours and decided to look for another alternative.

I pitched the idea of story points. A story point is assigning a level of complexity to a user story. A user story is a high-level explanation of the desired functionality that a user wants from the system. For example a user story would be like “As a User I want to login so that I can see my pets information”.

After the user story was written we would then think of all of the tasks that were associated with it like (1) set up the database, (2) write tests, (3) email verification for new accounts, (4) hash and salt passwords, and (5) Implement the UI. Then we would give the user story a point rating as either (1, 2, 3, 5, 8)

After explaining to developers the point system it seemed like something that they could get on board with. In the end story points are really just one level of abstraction above an hour-based estimate, but it allowed the developers to feel like they were not being monitored and in the end it just adds another variable to the total cost of a project calculation.

After several months of using the point system we have learned the following lessons:

• Don’t give points to bugs or chores. While bugs and chores are essential to a business they should be seen as maintenance and costs of poor planning not improvements to the system. This helps focus engineering efforts and eliminates over-engineering.
• Many of the engineers that pushed back very strongly against micromanaging are now asking for more granular reporting and for the ability to add sub-tasks to user stories. They now want what they hated, more micromanagement. 🙂
• User stories need to be estimated by a team. This provides a level of consistency between a team and helps the individual realize the level of their contribution and the overall completion of the project.
• A development task is not completed until it is in the clients hands. If a client can’t interact with his/her product over the web or on their smartphone, it is not finished. This has helped our team understand the need to be constantly merging and deploying.
• No work is finished until it is reviewed and approved by the client. Frequent check-ins and sign-off are important to prevent scope creep and regression. Sign-offs gives you a point to of reference to return to with client and can act like a checkpoint to regroup.
• If you have an 8 point story you need to break it down. Several of our stories that started out as 8’s ended up taking an entire weeks. If the project is small stories like this can really mess up the schedule and budget.

In the end, points and hours are really pretty synonymous but they allow developers to provide higher level estimation without getting to involved with all of the technicality. It also gives a simple weighting toward the more difficult tasks and helps business leaders understand how hard certain tasks are.