Macro & Micro Estimating
I have been enjoying an interesting chat with Philip Ledgerwood about estimating. He advocates for Kanban, and I was advocating for sprints, but the discussion centered around the benefits and limitations of each for estimating output.
As an Agile practitioner, I long for an organization that never asks for an estimate and just trusts that the team will deliver value as fast as possible. This is impossible for many reasons beyond a lack of trust (an issue in many organizations). Others within and/or outside the organization often need to coordinate the launch of new customer value. They need estimates for their own planning purposes. Leadership making high-level plans to execute organizational priorities needs to have a sense of the capacity of delivery potential.
Suffice it to say, there are lots of reasons why it is impractical to avoid estimating. Given this, teams need to learn to be good at it. In my conversation with Philip, it became clear to me that different tools and methods work better for long versus short-term estimating. When asked how long it might take to deliver an entire new subsystem, the approach will be very different than estimating value delivery over the next one or two weeks.
Philip points out that the flow metrics available in a Kanban practice are highly accurate at predicting the average output of a team. For project-level estimates, these tools and the data collection processes are excellent. Unless the team has had a recent breakthrough that catapulted their productivity, moving average type estimates work as well as anything.
However, for short periods of time, like the typical one or two-week sprint cycle, these tools are too blunt an instrument. Product development work is dynamic. We are often working on new things that we’ve never done before. There may be similarities to prior work, but unknown unknowns often lurk in the darkness.
Unlike Kanban, sprints give us an object to evaluate. When we fail to deliver the expected value during a sprint, the retrospective often centers on understanding what we didn’t know and whether it was knowable when we started. Learning is great, but it won’t help us before it happens. So, we either identify missed opportunities to estimate better or learn something new about our work that may apply to future estimating. In either case, the knowledge is valuable.
While there’s no reason why you couldn’t make these types of examinations while utilizing a Kanban approach, I would contend that they are not intrinsic to the approach like they are with sprints. Refining your team’s ability to estimate accurately is a worthwhile endeavor (as stated above). Stakeholders appreciate it, and the team is likely to feel a sense of mastery when their accuracy is reliable.
As a side note, this is why I tend to advocate for Kanban with teams that are tasked with “keeping the lights on.” This work is often unpredictable, and priorities can shift dramatically and without warning. For teams that are tasked with regularly delivering customer value, sprints are a way to put an iteration stake in the ground. As long as people aren’t being punitive about missed estimates and using it only as a learning opportunity to improve, it’s a powerful approach that embodies what it means to be Agile.