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 met by team members working overtime, causing burnout, frustration, and usually introducing bugs.
Inaccurate plans frustrate both team members and stakeholders, but one of the worst impacts is the team loses credibility with its stakeholders.
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 five minutes late myself.
I no longer trust him to be on time.
It's just lunch, so who cares?
But the problem is much worse on projects.
Consider a team that is either consistently late or always has to drop scope to meet a deadline.
The team is now asked if they can deliver a new project in three months.
Team members think about it and decide they cannot deliver it in 3 months, but could in 4 months!
When they tell stakeholders they need an extra month, the stakeholders don't believe them.
And 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 three months anyway.
Why not?
the Team never meets its deadlines.
So, Stakeholders may reason that they'll stick with the three-month deadline, but quietly expect it, in perhaps four months.
What's critical here is that stakeholders will not treat the team as an equal partner.
Consider how things might have played out differently if the teams had established a track record of providing decent plans.
Not perfect, just decent.
When that team tells stakeholders a project will take an extra month, stakeholders are likely to engage in a conversation about options.
Stakeholders and the team would discuss ways to meet the desired earlier deadline.
For example, would it help to enlarge the theme?
Is there a feature or two that could be dropped or deferred?
Would it helped 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.
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 a plan, the padding is often removed unless team members can present solid logic and evidence for the size of
the patting.
A better solution would be for team member to assess why their plans have consistently been wrong.
Sometimes the problem is with the estimates themselves.
If that's the case, there are many things team members can do.
I'll share just one technique right now.
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 washing to wash, dry, and put away the clothes.
if needed, I could unpack put-away into fold some items and hang some others.
Agile teams can unpack large product backlog items into smaller product-backlog items, and they can pack small product backlogs into the tasks they'll
perform to complete that item.
Having split work into small pieces, most teams will next estimate those smaller pieces.
However, research by Magda Jorgensen has shown that estimating small things and then summing those estimates can lead to worse estimates.
So instead of estiming 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 I've added references to these two important papers in
the description.
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?
One reason is when a team fails to account for what 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.
Part of the unknown backlog is just things the Team hasn' t thought about yet, every Team overlooks something.
Beyond things a Teams overlook, there are also emergent requirements.
These 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 idea 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.
A simple approach is to ask Team members to estimate how much they think they currently know about the product they'll ultimately deliver.
Suppose a team has a set of really good detailed discussions with stakeholders.
It's clear that stakeholders hold a crisp vision of what they want, and stakeholders have answers for most of the team's questions.
Following these discussions, team members feel they have a good understanding of But team members also know there will be some misunderstandings and that
stakeholders will inevitably come up with new ideas that they'll insist be included.
Team members in this situation may reason that see about 80% of the ultimate solution.
That means the product backlog is 80 percent of full size of backlog.
The unknown backlog the other 20 percent.
Team members don't know what will be on the unknown backlog, but they can estimate an approximate size for it.
And they could 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 plans, even if the adjustment is a very rough approximation.
Not all teams need to plan.
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 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.
For physical products, plan 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 courses online publicly a few times a year and can also teach a private course for your organization.I've put links in the description.
Thank you for watching and I'll see you next time.