Burning Forward

On letting go and using just what we know now in our Agile planning and estimation cadence

Plans are nothing, planning is everything.
— Dwight Eisenhower

Seasoned business managers worldwide succumb to the sunk cost fallacy each time they use non-recoverable costs incurred as reason for ongoing investment in projects or products. In a similar vein, experienced development teams mistakenly onboard irrelevant information when they include already-expended effort in forecasts for future periods. Plans and projections — to say nothing of blood, sweat, tears, and money — can be hard to let go of. But if we’re the Agile practitioners we say we are, we should be letting go often. And we should be regularly revisiting our estimates and burns in doing so.

Uncertainty and agility

On a number of occasions in the 1950s Eisenhower, in both letters and speeches, deployed his observation on worthless plans but valuable planning as he reflected on an armed forces career and a World War that had culminated with his command of all Allied forces in Europe. Eighty years earlier, and similarly from a military vantage, Prussian Field Marshal Helmuth von Moltke the Elder had posited, “No plan of operations extends with any certainty beyond the first encounter with the main enemy forces.” Then, of course, is this gem from beside a 1997 boxing ring, Mike Tyson’s iteration: “Everyone has a plan until they get punched in the mouth.”

Predicting the future is a fool’s errand. Planning for it, however, is not… as long as the resulting outputs and indicators aren’t taken for promises, certainties, or contracts. The reason for this is that the act of planning in and of itself makes us engage with options and contingencies as we try to get from where we are to where we want to be. In Agile contexts, we repeat this act frequently to allow for the onboarding of new information and related adjustments. Herein then lies a question. What value is there in continuing to abide by yesterday’s projections when today’s are the surer set?

There is none.

Neither field commander nor gap-toothed pugilist insists on using outdated information in the face of new developments. We — in our relatively peaceful project endeavors — should likewise refrain. And if we believe this, we should be bringing a critical eye to artifacts or practices that do get weighed down by the past.

Revisiting estimates and burns

One place we can find ourselves burdened by yesterday is with project Burnup charts informed by planning sessions that don’t allow for work re-estimation. Teams commonly forecast completion of work over a period based on the effort they think the work will take (often as story points), and their past history of delivery (as velocity). Teams also sometimes miss those forecasts, necessitating work items to be brought forward (rolled over) into the next period. This is the moment it’s important to ask, “Do we care how big we thought this thing was, or only how big it is to us now?”

We should care only how big it is now because that is what we need to consider in forecasting the work we think we can complete in our next period. In keeping with the 2017 Scrum Guide’s prescription for a canceled sprint’s incomplete work, what this means in practice is that when we show up to plan this period, we revisit any partially-worked items and assign them new estimates that reflect only the remaining work to do. An eight may morph into a one because the thing that prevented it crossing the line in the previous period is a last test case to be run; a five may become a two because while initial development has been completed, pull requests and a quality review remain.

And crucially, because our repeated ability to finish is what we want to be measuring, the seven and the three that represent the differences between original and new estimates in the examples above simply vanish. They are sunk. We can count our effort expended in any number of ways (calendar days, hours, Mountain Dews). But if we are focused on completing increments, we should not find value in going down the rabbit hole of retroactively splitting or redistributing points to represent effort expended on incompletion.

Reason and implication

One of the holiest and most elusive of the Agile principles is that the practices we adopt should promote “sustainable” development. The degree to which we can rely on information from previous cycles to plan future ones is the degree to which we aid ourselves in establishing predictable rhythms and associated expectations. If, in the example above, old estimates are kept on the items in question; the entirety of that scope is erroneously reported as completed in-period when they close. In trying to use that indicator of past performance to plan future, we will overcommit. A resulting “bull-whip” of velocities across periods ends up telling the story of predictability at large.

Instead, by constantly re-examining the work we see having to do now, we keep our estimates relevant-to-period while encouraging a finishing mindset. The implication of this on a cross-period Burnup representation is a scope line that adjusts as needed at the beginning of each period to reflect latest information on effort-to-completion. If teams work under contracts that focus on promises of points-to-be-delivered; this can be a problem (because of the fore-noted vanishing characteristic). If they are otherwise allowed to focus on outcomes to be achieved and to be agile in the achievement, then this view simply acknowledges that punches in the mouth can happen, and provides the truest picture of Now to use in planning forward from the moment.

“But wait…”

This is a disconcerting approach for teams used to rolling stories between periods and justifying that norm with talk of averages and a nebulous “long run.” Below are answers to some common questions.

• Won’t the team’s morale be affected when it only gets partial credit for some stories?
  Not if leaders focus their teams on the right things. Story points exist for planning purposes only. So rather than being in the business of delivering points or other estimates, let’s be in the business of delivering value. A team’s morale is far better served by its own repeated delivery of valuable product increments than it is by reporting on a related abstraction. (And note that the frequency of the very scenario that leads to re-estimation will decrease when the focus is right.)
• How does a team plan its sprints with this approach?
  Like it always has. But with a renewed emphasis on what it believes it can execute on and complete in the sprint.
• How does the reporting work when sometimes points vanish?
  Any discarding of points is reflected by the scope line in your project’s Burnup chart. This chart, in effect, recalibrates as needed with each planning session so that it presents the most up-to-date picture of remaining-scope-to-completion.
• Why doesn’t it work to simply carry items forward with their original estimates, then average these across periods?
  What gets lost in allowing for “rollovers” and averages in the manner described here is the focus that we should be bringing to Done increments, and the behaviors that ladder to these (like making smaller stories and swarming to finish in-flight items before starting new ones). We want a picture of how much work our team can get done, demonstrate, and ideally deploy in a single sprint. The logical extreme of letting unfinished items be averaged out across periods is for a team to work on a single item of size x that only completes after multiple n periods, then to translate that to a team velocity of x/n. The thesis of this article is that that is an anti-pattern.
• So you’re telling me we only care about what we can pick up and finish in the current period?
  Yes. This is what your velocity should be describing.
• Where is this being practiced?
  The approach described in this article leverages prescriptions found in the 2017 Scrum Guide and is consistent with Taichi Ohno’s emphasis on the importance of reducing inventories (in this case, as Work in Progress). It sits behind a number of successes we’ve had at Slalom with clients who have witnessed improved predictably from their teams after adoption.
• Does this change estimation approaches?
  No. Though it will to lead to smaller-sized work items over time, which in turn will help lower the standard deviation of velocities across periods (because of the increased frequency of delivered increments).

Divorcing ourselves from the worry that we somehow lose credit for effort expended when we re-estimate partially-completed work, instead thinking constantly of our estimates in terms of what it takes to Finish the items at hand; these moves make good things happen. Velocities become true reflections of the periods to which they’re associated. Deviations between periods smooth. Most importantly, mindsets and behaviors change. Teams accustomed to smudging period boundaries and existing in a suspended state of incompleteness start delivering Done increments of work more frequently. Because the emphasis shifts from rolling averages to current period. And because, despite owing to fallacy, it’s innately and psychologically challenging to re-estimate a big thing as small and the easiest way not to is to start with a small thing in the first place.

It’s ok to let go. The line still climbs when we do, but its forward advance is what we newly stress as we repeatedly embrace planning — using today’s information — as the everything.