During my training with other Product Owners, the most difficult discussion we had was to do with Story Points. Why do we need them? Why not use ideal days? Do they even work?
What is a Story Point?
A story point is a unit of estimated effort needed to complete an item. The higher the effort, the higher the points.
Mike Cohn gave a great early example of Story Points. Using an analogy of traveling will explain it’s complexity. Imagine you have to travel between two points. The distance is 100 meters. You ask your team to give estimations using story points. You will get different results due to different factors.
- Historical experience — One of your team members has traveled 100 meters a lot of times and can do it easily. The other team members are new so may over or underestimate.
- Technique — One team member estimated it as if he would walk it. The other team member has a bike so it will be easier and faster.
- Risk — One team member sees it is straightforward. The other sees that there are many busy junctions to cross adding more effort to their estimate.
- Complexity — Both team members realized that the destination is 100 meters in the sky with no way to get there. The complexity of the task is much higher.
What is a Story Point for?
I believe it is a benefit of both the Product Owner (PO)and Team. The most important benefits in priority order are:
- Create conversations about History, Technique, Risk, and Complexity.
- Negotiation within the team (including PO). Negotiations can result in trade-offs, reprioritization because of Return on Investment or the scope of the story.
- Create predictability for the product backlog items. I use data to determine the predictability of the story by looking at the correlation of story points and the cycle time (start work to closed).
No more Estimations!
I am being controversial here. I do not want to get rid of Story Points or any burn-down or velocity charts. I want to never ask teams to provide estimates that I would use against them.
Let me share two examples where estimates go wrong.
- When I was a developer. I was asked to estimate how long a feature would take. To be honest, unless I built that exact feature before I can estimate pretty well. However, 98% of the time, I guess it. We call them guesstimates internally. We have disappointed Product Managers time and time again.
- I did a long refinement session to determine if we were able to release a feature within the timeframe. After adding story points to all the items with a predicable team we would not release on time. A second refinement session was called the following day when other management heard the results. With negotiations of UX and features, the new story point estimations fit. However, the product team was unaware development felt pressure to make them fit. We failed to meet the deadline.
In both situations, the team had felt pressure to estimate and make it fit. Because of bad estimations, it created more pressure on the team and the PO to deliver on time.
As a PO I rather focus on conversations, negotiations, and increasing predictability by learning, and story points are a useful tool to ensure success.
Estimations for Stakeholders
We will never get away from deadlines because of our stakeholders. Various techniques I saw or done in the past are:
- Understand the cone of uncertainty and don’t make promises if you are uncertain.
- Use data or examples to support your statements. Theory alone does not convince stakeholders. Use practical examples you used. Burn-down Charts, or statistics helps.
- Support the team. Keep the goals and scope small and clear to increase predictability. Making it easier for the scrum team will yield greater results for everyone.
