Why I choose points over time for estimation in Agile development
A PO’s point of view why time measurement is pointless
When establishing Agile and Scrum in a company, there is usually the question on how to create projections, progress and efficiency. Effectiveness is, though it should be, unfortunately rarely in the immediate focus. Estimations in „people days“ is usually a measure people think they understand, but Agile development presents other points of view and options for that matter. Having tried time and story points, Scrum and Kanban for several years, I want to give my two cents on this topic.
Why to estimate at all?
If you search for “No estimates Agile“, you will find various articles promoting this or reducing time spent on it. I personally see several benefits when working with estimations.
On sprint level, estimates
- help driving a ROI discussion: a story can be over-engineered on both technical and scope level
- Drive splitting up stories
- encourage to keep story efforts in the boundaries of the estimate
- accommodate holidays, vacations, … during planing
- Identify improvement areas during retros
Long-term, estimates
- help prioritization, judging risks, …
- give an indication on when a specific epic or feature can be expected
- help getting to something like a roadmap
Estimations can also have negative consequences:
- Tracking team performance with all its negative motivational and protective consequences
- Over-engineer estimations: discussing an hour on whether it‘s the higher or lower number
- False sense of accuracy: software development is a creative activity and as such is not completely predictable
These should always be taken into account when working with estimates.
The unit conflict
Let’s look at velocity. This is measured in distance per time unit, e,g. meters per second.
Mapping that to Agile, what should the unit be? Frankly, seconds per seconds doesn’t make sense too much as they both have the same unit. Any other unit that you can map to a time (period) would fit much better to that analogy.
Time estimations have two other issues: communication and projection. It is difficult to explain that you only work 30 hours in a 40 hours week or why another person in your team doesn’t add the same hours. If you as Scrum team have to report to any other person, these communications are never beneficial. Also, reflecting team growth or shrinkage, team maturity, distractions or vacations is difficult. Some of these may vary on a daily basis and are hard to project.
Presumed accuracy: the false friend
You can track and measure time, perfect for measuring how long a task took to complete. But that‘s not what the estimation is about.
When using time, you give the assumption that you can exactly measure how long it would take and how many hours are left in a sprint. You may try to fill every hour to get the most out of it. Even worse, during estimation you might run into discussions, on whether a story is 8 hours or 10.
You might start the sprint completely filled and reality kicks in. The given estimates will rarely be met. What does this mean to your sprint or burnout?
Burning down time
A burn-down chart is one way to inspect the progress towards the sprint goal. When using story points, you get a quick overview on story closure. The burndown is only updated when customer value is created. The remaining points clearly visualize progress. Alternatively, burning down tasks give you a similar insights while there might be some ups and downs on the chart.
But with tracking time, it’s different. You burn down the work hours but that doesn’t necessarily give you an indication on how a sprint progresses. So you might reach zero without closing a single story.
Burning hours is not what you target for in Agile development. It’s creating customer value — and story points can be one measure for it.
The problem with time velocity
Velocity indicates for a team what can be done within a sprint. When measuring time, the result of a measure would be: “How many hours of work are done within a sprint?” . This can be useful to identify work of for book keeping purposes, e.g. when you have to bill your hours. But when you are developing a product, billable hours are not of interest: customer value is.
The customer value per sprint can vary drastically, depending on the complexity of the features, the developer’s or team’s maturity, noise during the sprint , … . When having a measure with a high variation, it hardly can be used for anything.
In Scrum, the velocity can be used by the team to judge what they can achieve, how many stories they pull into a sprint. For this, a somewhat stable measurement is necessary. Otherwise, the team cannot really commit to anything nor is there any stability in the plan.
With story points, you can get to a stable measure within 2–3 sprints which helps the team to get to a continuous and predicable feature output.
Making story points understandable
Outside of a software organisations, it is hard to understand what story points are and why “people days” is not a good way to measure effort. Explaining the background and arguing it might not really lead to a result. Instead, I suggest to focus on the actual problem: having some predictability in the plan and the roadmap.
Outside of software development, the interesting parts are:
- when a certain feature will be available — and what needs to be done to make it happen faster :-)
- any schedule changes and no surprises (don’t appear on the release date to state that it takes another four weeks)
- whether something else can be done first and what the impact is
My recommendation is not to use story points in any argument with any stakeholder — instead talk about the features and their availability. Talk about acceptance criteria and discuss them. In the end, reliability in the team’s assessment counts for itself and all requests for measuring “people days” is gone.
