Why do Scrum Fanatics Hate Time?
Time can be understood. Unless a scrumdamentalist is in the room. When they are, time is replaced with a point — but that point cannot be known. It is just relative to other points — not really a way to tell score or identify a true location.
This is a story about software development and time. Building great products is hard and developing meaningful software can be unpredictable. We know this after founding or being early employees of six software companies including Aha!
Our lives are finite and value creation is measured in time. But scrum fanatics have been able to dismiss what was once so obvious and take something that was known and make it mysterious. That was quite a brilliant sleight of hand and their marketing and PR folks must be proud. The problem is that it’s hurting the folks it was supposed to help — engineers and product managers. It reminds me of clear-cutting during the “Healthy forest” years or growing classrooms during “Leave no child behind.”
Scrum practitioners often rail against using time for estimation for a number of reasons.
However, the argument that I hear most repeated assumes that people talk about time only in absolutes — this will take 5 days and will be done on September 20. Scrumheads then set up a strawman and argue that time-based estimation is prone to failure because it’s too precise. It’s at this point that I continually see the use of points be adopted and consequently go haywire. Here’s why:
Story points force developers to ignore their experience Experienced developers have spent years developing code and astutely use pattern matching to recognize problems or stories that are similar to ones they have done before. This allows them to also draw on their experience of how long those stories actually took to complete. If a team uses an estimation metric other than time, then it is harder to use that prior experience to estimate the new task. Especially if the estimation metric has no linear relationship to time.
Velocity estimates are less accurate using points The agile gurus will tell you that points have a correlation to time that is based on the velocity of the team over a number of sprints, and that this provides a more accurate picture of how much work the team can achieve in a given time. This thinking is flawed because of the way that points are estimated for each sprint using a relative scale. If a particular sprint uses a larger or smaller story as the estimation baseline then the absolute value of a point will differ from previous sprints. Thus the velocity measured in points will also vary from sprint to sprint (even if the actual work velocity doesn’t change).
Points are opaque to the broader organization People in other groups (e.g. marketing, sales, support) need to know when something is going to happen or be completed because their work and customers depend on it. Just like product management and engineering, they need to have time to plan and do their best as well. Because there is intentionally no way to translate points into time, the organization is always flat footed and guessing.
Understanding of points differs by team Teams typically end up with different point scales that ebb and flow over time. This makes it additionally difficult to manage resources across a product portfolio or even across teams working on the same product.
I really wanted to give points a chance after seeing teams struggle to predict when they would ship product — maybe there was a better way than focusing on time. Unfortunately, using a different metric to estimate how long something will take only makes it harder to peer forward.
We use two key “estimation phases” when building software and they typically happen separately. Having two phases also provides a solid check and balance and leads to more predictable outcomes.
First, PMs and engineering leaders work together when PM is scoping a release or sprint and a collection of features. Early prioritization requires knowing whether the feature is a boulder, rock, or pebble. You can use a number of metrics here in discussions including pizza sizes, t-shirt sizes, and yes even points if you insist. Use any high level metric you want as long as there is some direct relationship between the metric and time (e.g. hour, day, week, weeks, month, months). You are simply trying to get an idea of what something will cost in terms of effort to help identify the features that will deliver the biggest value for the smallest cost.
Any “release dates” discussed at this point are really just PM “wish dates” that help focus the team on an objective until they are vetted and the targets are agreed to.
Second, the next and more detailed level of estimation comes once PM and engineering leadership generally agree on the goals and rough timing for the next major release. Engineering typically does this together to rationalize what can fit into a certain timeframe and these time-based estimates are connected with the features.
If the goal of business is to create as much value in the shortest amount of time, surely the clock matters. And just because it’s hard to estimate when complex work (like software development) will be completed, it’s no excuse to hide behind an unknowable mass disguised as something that even a pee-wee footballer understands.
If you are looking to create brilliant software roadmaps, articulate clear requirements, and build what matters — try Aha! And don’t worry, we will shortly support both time-based and point-based capacity and time management.
