“Don’t forget to leave a buffer for maintenance!” was what me, my superiors and colleagues always reminded one another when we were about to plan a Sprint. “How much of a buffer?” was always the followup question.
The answers range from “I don’t know, figure it out”, to “a rule of thumb says X%”. For some reason, no matter which X we choose, we ended up being wrong. By the end of this Planning series, we’d know why. Hopefully we’d also know how to do it right. In order to get there, first we need to decompose everything we know about buffers and expectations.
The main problem with a buffer is that no matter its length, it would never 100% perfectly fit the reality of execution. Buffers only set our expectations to be:
At the end of the Sprint there could be two outcomes. One where we take too big of a buffer and another when we take too small of a buffer.
When we take too big of a buffer, the result would be a lost potential to move the business forward. For example, let’s say the Sprint length is 10 days and we left a buffer of 4 days for maintenance. That has left us to commit only to Tasks of 6 days.
At the end of the Sprint, it turned out that we had only 2 days of maintenance instead of 4. Meaning that in hindsight, we could have committed to Tasks of 8 days instead of 6 days.
That is under-commitment, setting the expectations lower than feasible. We won’t be getting the job done If we continuously under-commit. The job we could have done, but didn’t because of an incorrect buffer.
A lost potential managed correctly is actually not a thing, because there is always more work to get done. We’d end up working on a Task no one expected us to work on. It’s only the expectations that we can manage.
On the contrary, when we take too small of a buffer the result would be a spillover.
We ended up with more maintenance than anyone could have even foreseen. It has spilled over the buffer line, causing the committed Task to spill over the Sprint’s end.
For example, a 10 day Sprint with a buffer of 4 days. While executing the Sprint, maintenance took 6 days instead of 4. The committed Tasks are still estimated at 6 days, which puts it at 2 days after the Sprint’s end.
2 days worth of Tasks could be dropped, or spilled over to the next Sprint. Both cases are under-execution, and expectations not met.
Another way to overcome spillover is to do 6 days of Tasks in 4 days. If they are already minimized or unchangeable, that would lead to stress.
People would have to put in more hours and code into late hours. Coding after concentration was exhausted would increase the odds of introducing bugs and Instabilities. That is a non-beneficial outcome.
Our binary thinking minds would come up with a quick solution. If no matter what we do we can not properly set a 100% accurate buffer – let’s just don’t set buffers.
Removal of a buffer may prevent the lost potential (which is not a thing), but it would not prevent spillovers. It would not prevent under-executions nor stress. On the contrary, it creates the potential for an ever bigger spillover because you allow yourself to over-commit, set the expectations higher than feasible. The result would be even more expectations not met.
“Life is what happens to you when you are busy making other plans”. There is some truth to this famous quote by John Lennon. We can plan all we like, but execution and reality would always differ from the plan. That is true for planning with a buffer, without a buffer and also true for a no-plan. So, what should we expect from the Plan?
Plans always set expectation, but not only from engineering. They set expectation of customers, who are agnostic to the Plan’s details. They do not care about maintenance and buffers. They do not care how long it takes or when we start to work on a Task.
However, they do care when we finish it because they need it done. When we set a date for a customer’s need to be satisfied, we set their expectations. We create a Deadline.
That would be setting customer’s expectation to “Us the company expects your need to be resolved by MM/DD/YY”. And that would be us expecting engineering to “resolve this customer’s need by X”. And because we Plan, X equals the Sprint’s end date. It’s a three-way contract.
Following up on John Lennon, Plans do not change the reality of execution. Deadlines do, and affect the execution of a Task through pressure, during execution itself in real time. Pressure is not stress, and a relationship exists between Pressure, Stress and Performance. It is called The Yerkes-Dodson law.
Let’s say our engineer estimated a Task at 5 days of effort. If we set the Deadline to “you have two days to do it” he’ll probably unconsciously say to himself “this is an unrealistic deadline. There is no way I’m going to meet the it. I’m not even going to really give it a shot but I’ll play along”.
Not because engineers are lazy, we as people are just wired so. The result would be under-performance and a Deadline not met. And it would be the Deadline’s fault and not the engineer’s.
Unfortunately, in some companies that would lead to blame as that is what mis-expectations of people do.
Instead, it is better to use Deadlines as a constraint for the solution. Deadlines can affect the solution. “We have a deadline in X days. What do you think we should do?”. Different solutions would be put on the table whether the deadline is within 3 days, 5 days or 3 weeks. Deadlines can be a guidance to a more beneficial solution.
On the contrary, we can set a 10 day Deadline for a 5 day Task. Our engineer would unconsciously take it too easy and would just take his time in doing so. It may actually lead him to do some non-beneficial work.
Deadlines and Plans are two swords, each with a double-edge. They have the potential of setting the expectations too high or too low and they have the potential to change the length of the execution itself.
Now that we better know their effects,, in this series we will learn how to do them better. By minimizing the uncertainties and variance in our expectations. But first, we need to continue to set our expectations by predicting, which is what the next chapter is about.