Bad plans lead to many well-known problems. Teams deliver later than expected. Or the budget is blown by adding people in the hope that will help.
Sometimes a deadline is met but by dropping important features. Or the deadline is met by team members working overtime, causing burnout, frustration, and usually introducing bugs.
Inaccurate plans frustrate both team members and stakeholders.
An Overlooked Impact of Poor Planning
But one of the worst, and perhaps most overlooked, impacts of a poor project plan is that the team loses credibility with its stakeholders.
As an example of how poor planning affects credibility, I’ve got a friend whom I’ll occasionally meet for lunch. He’s always 5 to 10 minutes late. If he emails me today and suggests meeting at noon, I’m going to arrive 5 minutes late myself.
I no longer trust him to be on time. His plans just aren't reliable. And that's OK because it’s just lunch.
But the credibility gap caused by unreliable plans is much worse on projects.
Consider a team that is either consistently late or always has to drop scope to meet a deadline. The project stakeholders ask this team if they can deliver a new project in 3 months. Team members think about it and decide they can’t deliver it in 3 months, but could do it in 4 months.
When the team members tell the stakeholders they need an extra month, the stakeholders don’t believe them. Why should they? The team has been consistently wrong on all prior projects.
At this point, stakeholders may tell the team to do it in 3 months anyway. And why not?
If a team never meets its stated deadlines, stakeholders may reason that they’ll stick with the 3-month deadline to apply some pressure, which has limited effectiveness. (And like me with my friend, they might also quietly expect it to be done later, in perhaps 4 months.)
Stakeholders and Developers Should Be Equal Partners
Here's the bottom line: stakeholders will not treat a team as an equal partner if the team consistently provides bad plans and inaccurate estimates. Credibility is such an important factor that I include it as the first of four reasons agile teams estimate product backlog items in the first place!
Consider how things may have played out differently if the team instead had established a track record of providing decent plans. Note I said decent. Plans don't have to be perfect to be reliable.
When a consistently decent team tells stakeholders a project will take an extra month, stakeholders are likely to engage in a conversation about options to meet the desired, earlier deadline:
- Would it help to enlarge the team?
- Is there a feature or two that could be dropped or deferred?
- Would it help if team members were allowed to focus solely on this product instead of also supporting some old product?
When a team has a track record of presenting reasonably accurate plans, they will be treated as equal partners by the rest of the organization.
Padding Doesn’t Help
Many teams try to solve the problem of inaccurate plans by padding their next plans. This usually makes things worse as the team now has two things to estimate:
- The plan, and
- How much to pad the plan
When stakeholders call the team on padding the plan, the padding is often removed unless team members can present solid logic and evidence for the size of the padding.
Instead, Understand Why Plans Have Been Wrong
A better solution would be for team members to assess why their plans have consistently been wrong.
Sometimes the problem is due to poor agile estimation. If that’s the case, there are many things team members can do to improve estimates of story size.
I’ll share just one technique now that's especially helpful for teams who chronically underestimate the amount of work involved in a particular product backlog item. It’s called unpacking.
Unpacking involves identifying all the subparts of some work to be done. I need to do my laundry today. I can unpack doing my laundry to be wash, dry, and put away the clothes. If needed, I can unpack putting my laundry away into folding some items and hanging some others.
Agile teams can unpack large product backlog items into smaller product backlog items, and they can unpack small product backlog items into the tasks they’ll perform to complete an item.
Having split work into smaller pieces, most teams will next estimate those smaller pieces. However, research by Magne Jorgensen has shown that estimating small things and then summing those estimates can lead to worse estimates.
So instead of estimating the smaller pieces, unpacking involves identifying the components of the work but then estimating the original, larger item. Research by Kruger and Evans has shown that unpacking items this way will lead to larger estimates. For teams who chronically underestimate, this is a valuable and easy way to get better estimates.
Being Late Even When Estimating Well
Unpacking is one of many ways a team can improve its estimates. But some teams actually estimate most items fairly well but still deliver late.
How can this be? The backlog is bigger than teams think. In The #1 Reason Even Agile Projects Are Late, I discuss the four reasons products grow beyond initial estimates, including something I call the unknown backlog. The unknown backlog contains all the work that a team will need to do but that hasn’t been identified yet.
This includes things the team hasn’t thought about yet and also includes emergent requirements. Emergent requirements are needs that emerge through the process of building the product. Stakeholders are shown a preliminary version and that gives them new ideas. In many cases, those new ideas become must-have features.
It would be impossible for a team to make a list of everything they’ve overlooked or that will emerge–these items are, by definition, unknown. However, there are techniques a team can use to roughly estimate the size of the unknown backlog, including calculating a project buffer size.
As explained in #1 Reason Even Agile Projects Are Late, a project buffer is based on the idea that team members see about 80% of the ultimate solution when estimating the initial product backlog. The unknown backlog adds 20% to that calculation.
Team members won’t know what will be on the unknown backlog, but they can estimate an approximate size for it. And they can use this to better scope the full size of the project.
By including an adjustment for the unknown backlog, a team can greatly improve the accuracy of its plan, even if the adjustment is a very rough approximation.
Accurate Agile Planning
Not all teams need to create estimates and long-term plans. Some teams are simply instructed to deliver new capabilities to achieve outcomes as quickly as possible.
In the majority of organizations, however, some degree of agile planning and predictability is important. This may be to enable coordination with partners, to train users, to coordinate marketing efforts, or more.
In a private company, plans feature prominently in the company’s ability to acquire funding. And in a public company, plans influence guidance given to shareholders and investors.
And for physical products, plans influence manufacturing and shipping commitments.
If creating reliable plans stakeholders can trust is important to you, consider participating in one of our Accurate Agile Planning courses. This course is designed to help teams produce accurate estimates and plans including on fixed-date and fixed-scope projects.
I teach these online publicly a few times a year and we teach a private course for your organization.
