Responsible engineers do not shy away from making estimates. As software teams improve their ability to estimate story by story, stakeholders are often more interested in the bigger picture. How many weeks until feature X goes live? Is major initiative Y going to production in Q2? Q3? When answers to such questions seem like guesses or suggest dates far into the future, stakeholders get frustrated. Questions like: Why is it going to take so long to build X? - it seems so simple!, or: What’s preventing us from starting work on Y sooner? start to get lobbed at the team.
Let’s take a look at how to communicate the team’s future development plans to stakeholders.
Why it’s Important to Share as Much Information as We Can
Let’s consider why we even need to give information about the future direction of development. Why can’t we just tell stakeholders to work with the features that are already live, and tell them that they’ll gain access to new features as they become available, regardless of when that may be?
To answer this, we need to empathize with project stakeholders. Let’s consider three:
Marketers are trying to drive new customers to the product. If they are confident of the future release date of an upcoming feature, they may find it useful to talk about the feature with prospective customers. To maximize new lead conversion upon feature release, they may wish to plan a marketing campaign around the launch. Such planning would doubtless take time and they’ll want to work this task into their own planning. Knowing about forthcoming product changes will help them here.
Customer Support are constantly helping customers overcome issues they are having with the product. In some cases, a customer might be experiencing a minor issue that will be fixed by an upcoming product change (be it a bug fix or a new feature). If the change is imminent, customer support may choose to tell the customer to wait until the change goes live. If the release of a major new feature is coming up, customer support will want to prepare for any changes in customer queries that may reach them.
Business and Finance are doing big-picture, organization-wide strategic planning. Projected revenue from the release of a major initiative may need to be taken into consideration. If the company is pre-profit or desires growth at a rate higher than current profit can support, projected revenue will affect pitches for funding. The information may help the company plan staffing - how many extra people do we need to bring in, and into what positions? Upcoming product changes (especially major ones) help in such planning.
It’s clear that the sharing of such information will help many people in many areas of the organization. It is worth doing and doing well.
The Future is Uncertain
The classic reason for reluctance from development teams to estimate their work is that the future is uncertain. Everyone’s been burned by a rough, off-the-cuff speculation about when something might get done being taken as a promise, then being reminded of that “promise” again and again as a feature’s release date slips. We need to break through this trap using a few principles and techniques.
The first thing to do is to embrace the uncertainty. Use the famous quote widely attributed to Dwight D. Eisenhower:
Plans are useless, but planning is indispensable.
You’ll usually find that if you make a plan to do something, as you actually do the thing the work won’t go exactly as you planned. This implies that the plan was useless. That’s okay! The act of planning prepared you for the work, which is why the planning was indispensable. In fact, your original plan was probably closer to capturing what was actually needed than it seemed. As the actual work unfolded, you probably found yourself tweaking your plan rather than abandoning it.
You need to embrace this philosophy when communicating information to stakeholders. A good way to explain this is by saying:
We put considerable effort into planning the future direction of development. This helps us ensure that we complete our work and get features to customers. However, it is rare that any specific plan gets carried out exactly as we envisioned at the outset. Continually changing circumstances cause this to be. So please always consider the information we give as our most optimistic view of how the future will unfold, and that it is subject to continual change as new circumstances come to bear.
And with that, let’s take a look at some approaches.
Roadmaps and Timelines
In Agile software development, the tool of choice for communicating future plans is the Product Roadmap. Roadmunk calls a product roadmap a visual communication tool that aligns a company around a high-level product strategy.
As you can see from the diagram, a roadmap shows high-level information about what might get implemented over time.
Such a roadmap is a great way to communicate this information. But there are some pitfalls.
First, a roadmap should be described as a statement of intent. It is not set in stone, nor does it promise what will happen in the future (and by when). Keep Eisenhower close to your heart at all times.
Second, a roadmap doesn’t have to include dates. The truest form of a roadmap is one that shows milestones along a journey. This journey isn’t pegged to a calendar - it is just a number of steps to be taken until an objective is reached.
Once dates are introduced, the roadmap starts to become a timeline. Timelines are good because they help stakeholders plan how their own work will weave into product changes. But they can be dangerous too. The minute dates enter the picture stakeholders start hearing promises. This happens even when Eisenhower is brought in.
The way to deal with this is to only share timeline information when you are very sure that it is accurate and to be constantly aware of the human tendency to hear estimations including dates as promises.
Start by using fine granularity only in the short term. I recommend placing calendar days on your timeline only up to one month into the future. For the one-to-three month outlook, refer to dates as months (e.g. ”today is March 15th and we estimate this will be completed in May”). Further into the future than that, either use quarters (“today is March 15th and we estimate this will be completed in Q3”) or avoid any kind of date association at all.
In The Clean Coder, Uncle Bob says:
An estimate is a guess. No commitment is implied. No promise is made. Missing an estimate is not in any way dishonorable. The reason we make estimates is because we don’t know how long something will take. … An estimate is not a number. An estimate is a distribution.
He goes on to say that you should always express an estimate with a probably distribution, at least a best-case, typical-case, worst-case. That way, you are (at the very least) highlighting to the receiver that this is indeed an estimate, not a promise.
Consider the difference in these two dialogues:
Stakeholder: when will feature X go live? Development Team: next Friday.
Stakeholder: when will feature X go live? Development Team: There’s a small chance (10%) it will be live by next Wednesday. More likely (60%) it will be next Friday. However, Y might push it so we’re thinking that there’s some chance (30%) that it will be live some time in the week after.
Use this way to communicate estimates as much as you can.
Deadlines
Sometimes, especially in more toxic environments, management attempts to turn estimates from the development team into deadlines. What’s this about?
It’s important to understand what a deadline is (and what it is not):
A deadline is a date on which something will happen that you have no control over.
Examples include a third-party ending support for an API your product uses, the first day of a new team member joining your team, a political election, and major sporting event, and Black Friday.
Deadlines are by definition not self-imposed. When someone tries to impose a deadline artificially, it is not a deadline. It is a goal.
Deadlines are therefore input factors into planning. Their existence impacts the product roadmap and timeline. They don’t emerge from the roadmap, the roadmap emerges from them (when they exist).
Push back when you see “deadlines” being imposed artificially and recognize them as warning signs of toxic behavior. When actual deadlines emerge, be sure they are given the priority they need the next time the product roadmap is refined.
—
Armed with this information, I hope that your communication with stakeholders interested in your team’s output will become clearer and that your organization as a whole will become more effective as a result.
