Presentation Tips for Software Development Managers
By Daniel Harper · Career & Business
How should a software development manager present a delivery date? As a range with a stated confidence, built from what the team has actually delivered before rather than from the plan. Say what would move the date and when you will know more, then update the range as work lands. Honest numeric uncertainty costs little trust; vague wording and missed promises cost far more.
Software development managers present in sprint reviews, release planning, roadmap meetings and steering committees. Whatever the meeting, one question comes up more than any other: when will it be done? Most of the trust a development manager has with the rest of the company is won or lost on how that question is answered.
Why the first date is usually too early
People are reliably optimistic about how long their own work will take. Roger Buehler, Dale Griffin and Michael Ross called it the planning fallacy. In their studies, people's predictions of when they would finish tasks were too optimistic, and when asked to think aloud, they focused on how the work would go rather than on how similar work had gone before.1 Two findings from the same paper are directly useful. When people were asked to connect their prediction to relevant past experience, the optimistic bias disappeared. And observers predicting someone else's completion time erred in the other direction.
For a software team, that means two things. Build the date from what the team has actually delivered in past sprints, not from the plan for this one. And ask someone outside the team to sanity-check it, because they are not attached to the plan.
Present a range, and say how sure you are
A single date is a promise. A range is a forecast. Most development managers give a single date because they worry a range will sound weak.
The research suggests the worry is mostly unfounded. Anne Marthe van der Bles and colleagues ran five experiments with nearly 5,800 people, including a field experiment on the BBC News website, and found that communicating uncertainty about facts and numbers lowered trust only a little, and mainly when the uncertainty was put into words rather than numbers.2
So the weak version is not the range; it is the vague wording.
Weak: "We're aiming for around the end of March, hopefully." Strong: "Between 14 and 28 March, most likely the 21st."
Say what would move it
A forecast is only useful if people know what it depends on. Name the two or three things most likely to move the date and when you will know more about each:
"The main risk is the payments provider's sandbox. If it's ready by the 3rd, the range holds. We'll know by Friday."
When someone insists on a single date
Some stakeholders will push back on a range: "I need one date for the board." Give them the date you would bet on, with its condition attached, and put both in writing: "Plan on the 28th. If the provider's sandbox slips past the 3rd, that moves, and I'll tell you on the 4th." That gives them their single date without turning your forecast into a promise you never made.
Show progress as a burn-up, not a velocity number
Velocity is a planning tool for the team, and it means little outside it. A sprint velocity of 34 tells a stakeholder nothing, and comparing it between teams invites exactly the wrong conversation. A burn-up chart shows what they actually care about: total scope, work completed, and the trend towards the line where the two meet. It also makes scope growth visible, which is often the real reason a date moved.
Narrow the range as you go
Present the forecast in the same format every time, so people can watch it narrow. A range that tightens from "March or April" to "14 to 28 March" to "21 March" builds more confidence than a fixed date that is quietly moved twice.
When the date does move, say so at the next opportunity, not at the last one. Presentation tips for project managers covers how to deliver that kind of news.
Sprint reviews: show working software
A sprint review is the one meeting where you can show instead of tell, so show. Demo working software, from the user's point of view, following one real task from start to finish. Rehearse the demo once, run it on a stable environment, and have a recording ready in case the live version fails.
Skip the list of tickets closed. Nobody outside the team can tell whether 42 tickets is good, and it invites the wrong question. "Here's what a customer can do today that they couldn't do two weeks ago" invites the right one.
References
- Buehler, R., Griffin, D., & Ross, M. (1994). Exploring the "planning fallacy": why people underestimate their task completion times. Journal of Personality and Social Psychology, 67(3), 366–381. https://doi.org/10.1037/0022-3514.67.3.366
- van der Bles, A. M., van der Linden, S., Freeman, A. L. J., & Spiegelhalter, D. J. (2020). The effects of communicating uncertainty on public trust in facts and numbers. Proceedings of the National Academy of Sciences, 117(14), 7672–7683. https://doi.org/10.1073/pnas.1913678117