“It is important to communicate to stakeholders that early calculations using velocity will be particularly suspect. For example, after a team has established some historical, data, it will be useful to say things like, “This team has an average velocity of 20, with a likely range of 15 to 25.” These numbers can then be compared to a total estimate of project size to arrive at a likely duration range for a project. A project comprising a total of 150 story points, for example, may be thought of as taking from 6 to 10 sprints if velocity historically rangers from 15 to 25.”

— Mike Cohn, Succeeding with Agile 2010.

This requires that you have the project’s scope and cost in story points clear at that point, which you won’t have. Story point estimation takes time to achieve any useful consistency, and especially to do the kind of learning (“last time we took something like this on, it was an 8, not a 3”) that gets you to numbers you might want to rely on.

It depends on scope being set — and how often is that true, particularly on agile projects where you’re able to show users the product at the end of each sprint and make adjustments?

More importantly, say these teams are relying on the release date of a project:

• customer support, which needs to update all the help documentation and set up training with the people who pay you money
• marketing, which needs to create materials based on final screenshots and capabilities
• other teams, which will use the delivered work to create new projects

Where if you deliver early, that’s great, they have more time to rehearse, edit, and control over whether they want to release early.

If you’re late, they need to know as soon as possible if they need to start cutting schedule or scope, or spend more to keep those constant and meet a new deadline.

Then take Cohn’s example. If my company is lining everything up behind a date, and my status email is

“We have 150 story points remaining, and the team’s current velocity is 20 per two-week sprint, with a range of 15-25, so we should deliver between 20 weeks from now and 12 weeks, and probably around 16 weeks, which is on time.”

People would rightly stand up from their desks and hurl the nearest team-building trophy at me.

At the same time, putting more information about the probabilities and how you calculated them isn’t going to help. You can’t talk about the power law or the Hurst Exponent here. The question people want answered is: do I need to take action?

You’re going to end up reconciling this to some organizational standard, like:

• Green: On target
• Yellow: Risks but on target
• Red: Will miss date unless changes are made

Which actually means for PMs:

• Green: I’m not paying attention
• Yellow: I’m on top of things
• Red: Please have your VP come by my desk immediately and yell at me

And for your customers, eventually means:

• Green: the PM isn’t paying attention so I won’t either
• Yellow: something meh whatever
• Red: aieeeeeeeeeeee

Then what do you say in your one-sentence “summary” at the top of your status report, the one thing people will read if they open it at all?

My best results came from straight team votes at the end of the sprint: ask “Do you feel confident we’ll hit our date?”

80% or more thumbs up? Green.

50%? Yellow.

Under 50%? Red.

This requires the team trusts they can give their honest opinion and not be pressured. If that’s not the case, do the rest of the PM world a favor and leave our ranks.

Ask, get the number, and nod. Don’t argue, don’t cheer, just nod, and use that. Then in your status report, you write

“We’re green.” If you want, offer “(87% of team members believe we will meet our target date)”

Now, you do want to express the uncertainty, but in a way that people can use. Think of yourself as a weather forecaster. Do you tell people to bring umbrellas? Put on sunscreen?

Hurricane forecasting has a useful graphic for this:

Where on the calendar does your project land, and with what certainty? Assume that you ship every week on Friday. Why not

Distance from the calendar is how far out you are, and the shading indicates likeliness. Mark the release deadline with red (or a target, or…).

Daniel Worthington offered this:

Which is even better.

So two questions for you — 1) How do you effectively measure uncertainty on a project’s delivery date? 2) How do you convey that so it’s simple and easy to act on?