One thing Scrumism teams get used to when I’m working with them is “current course and speed.”  I especially take care to explain this concept if I’m working with management, or those who aren’t very familiar with things like backlogs and velocity.

When presenting a roadmap, you basically lay out what features are to be delivered at what time.  The thing with a product backlog is that things can change – like new features being added, or moving features to a different place in the backlog, or deleting features, whatever.  So a prediction of when features will be delivered is based on the backlog as it stands right now, and using the average velocity that we are seeing right now.  That is, given our current course (arrangement and estimated effort of the product backlog) and speed (velocity), we can predict a range of features that can be delivered.  I say “range” because we try to factor for uncertainty and risk as well.

So if we have a predicted rate of delivery – velocity, and we are given a specific time we want to predict against, we can estimate a range of Value (features from the backlog) that can be delivered.  That looks something like this:

We can do the related estimation of a range of time given a set of features – same sort of idea.  If we are presenting a roadmap of what can be delivered when, we need to be sure the audience understands that agile expects that things will change and will adapt accordingly.  Still, if our backlog is ordered by value (and it should be!) and has riskier things near the top (so we can fail quickly if we can’t pull them off), our estimates should be pretty good.  Given current course and speed.