The challenge with estimating agile project starts with the unit selected to quantify it.
Story Points are a standard answer to a question about measuring Agile Project. But even if Story Points are well embedded in your organization, measuring by it becomes a major headache very quickly. Teams use it to estimate complexity, managers translate it to hours. The Story Point itself is sensitive to a team assigning it, it does not reflect the circumstances around a sprint and it can be a victim of inflation.
But what’s the point?
The primary reason to measure a project is to be able to forecast. What we need to know is the chance to deliver a specific functionality (expressed in story points) within M sprints given the historical data. On top of it, we expect it to give us an insight into the quality of the agile process itself.
The standard way is to look at an average of points delivered, compare it to the backlog and apply it to the future sprints. A more advanced way would be to combine it with a confidence level.
But is all comes short, because Story Point itself is a moving target.
We don’t know what we don’t know
The standard way of quantifying a sprint in story points misses a few very important factors:
- Work which is done without points, not on a sprint or both.
- Capacity variations between sprints (people on vacation, unusual sprints during holiday season)
- Differences in estimation between teams and between sprints (team maturity, points inflation etc.)
All of this can be (in theory) solved by a proper agile process, but how can you bring your process to a higher level if you do not measure it?
The Geigr Index is a percentage, where 100% means that all your work is done with points and within a sprint, and the team delivers exactly according to the plan.
The idea behind Geigr Index is to introduce a statistic, which reflects the quality of your estimations and the agile process itself.
If the index is 100%, you can blindly take what the team commits to in the planing session and use it to estimate the future.
The index has a number of advantages in comparison to the standard measurement of velocity per sprint:
- It reflects the way team manages its backlog, so it can be used to monitor the process
- It is not sensitive to sprint velocity differences, because as long as a team anticipates its limitations during the planning session (*) and then delivers as planned (**) it is still a predictable sprint, which you can use it to plan forecast the future
- If teams use different Story Points for the same complexity, it is still possible to compare them, since it is not a number of points which counts, but the ability to deliver as planned.
(*) limitations like holiday season, important release requiring supporting other teams or other time consuming actions, which are not expressed in story points
(**) without changing a backlog ad-hoc during a sprint)