While it's true that agile teams value "responding to change over following a plan," high-performing agile teams do make plans. In fact, agile planning is built into the Scrum framework, from daily scrums to sprint planning. The reason? Because good agile plans lead to good decisions.
But what makes a decision good? Does a commitment to agile decision-making and building accurate agile plans mean making perfect guesses every time?
The answers to those questions are found in the video below. (I've included the text of the video as well so you can read instead of watch if you prefer.) Find out what makes a good decision good, and learn best practices for playing the odds.
Consider the Odds When Making Decisions
A good decision is one that we’d make again the same way, given the same information. That doesn’t necessarily mean what you think it does.
Suppose I offer you the chance to win $100 on a single roll of a normal, 6-sided die. You have 2 options: You can bet on rolling a 1 or you can bet on rolling all things other than 1. If you choose correctly, you win the $100.
| Roll | Win | |
|---|---|---|
| 1 | $100 | |
| 2, 3, 4, 5, or 6 | $100 |
Assuming a fair game, there is an equal chance of rolling any number. So there is 1-in-6 chance that you roll a 1. There is a 5-in-6 chance you roll something other than 1.
Your best option is to bet on rolling a 2, 3, 4, 5, or 6. If you do that, you have a 5-in-6 chance of success. And so that’s the decision you make.
What happens, then, when you roll the die and throw a 1 and lose the bet? Was betting on 2 through 6 the wrong decision?
To answer that, how would you bet if I gave you the chance to roll the die again?
You would again bet on rolling a 2 through 6.
Rolling a 1 is bad luck but it doesn’t mean betting on 2 through 6 was a bad decision.
Do Good Plans Ensure Good Outcomes?
Let’s put this in the context of an agile products. You follow all the best practices in agile planning and conclude that a product can be delivered in 4 to 6 months.
Before deciding to approve the project, management considered the 4-to-6 month plan and compared it to the projected benefits of the project, such as increased revenue, customer satisfaction, or cost savings.
They reasoned that the product will be a bargain if it’s finished in 4 months, a good deal if delivered in 5, and will even yield an acceptable but not exciting return even in the full 6 months. Based on these odds, management greenlights the project.
The project progresses nicely at first. Then some unanticipated bad luck strikes and the project is completed in 7 months, a bit longer than the expected 4 to 6.
Does this mean the plan led management to make a bad decision? Not necessarily.
Ask GoatBot Your Agile Planning Questions
Keep the Odds In Your Favor with Good Agile Plans
As with rolling the die, imagine you could run the project 100 times and with no learning between successive runs of the project. Would it almost always take 4 to 6 months just as the die would mostly show 2 through 6?
There might be occasional bouts of bad luck in those 100 project runs. Sometimes the project will take 7, or even more, months. And there could be occasions of good fortune in those 100 imaginary runs, with the project being completed in only 3. But these are outliers. They’re like rolling 1 on the die 4 times in a row.
Management has every right to be disappointed if they’re told 4 to 6 months and a team takes 7 to deliver. But management doesn’t have the right to be angry about it if it was just like the random bad luck of rolling a 1.
I encourage teams to communicate plans that, 90% of the time, they can meet. Theoretically that means there’s a 5% chance of finishing earlier and a 5% chance of being later. More practically, even teams that are good at estimating may provide plans that are accurate 80% of the time and that will be too low 20% of the time.
There’s a difference between being wrong and making a bad decision. If I made a bet that a die will come up with a 2 through 6 and it doesn’t, I was wrong about the outcome. But I did not make a bad decision. This is an important distinction for both teams and management to understand.
