Velocity converts to time, not story points

Suppose for a moment that you have a collection of features you want to build into a product. 

You sit down with your team, brainstorm some user stories and then score them.  When you are done you total up the story points and there are 100 story points.

Suppose then that I tell you this project is scheduled to be delivered in 3 months.   Hmm, that's interesting.

Now suppose that you are also consulting on another project.  You have a collection of features you want to add to this other product.  This project has an entirely different team.  Like the first team these folks have been working together for a while and many of the team members go back to version 1.0 when the product was launched.

You sit down with this team, brainstorm some user stories and score them.  When you are done you total up the story points and there are 100 story points.

You look at the project plan and see that the project is scheduled to be delivered in 9 months.

Both are 100 points but one is a 3 month forecast and the other a 9 month forecast.  Is one team's assessment of the user stories right and the other wrong?

It's likely that both are correct.



Each team scored their stories with their understanding of the complexity of the work involved for their project.   They used the experience of their team and the technologies involved in their project.  It's likely that both teams have done a proper assessment.   Remember that story points rank the complexity of one task to another in a relative fashion.

Perhaps one project involves a relatively light mix of backend services and the other includes a CMS, a search engine, a complex asset management system, and high performance data storage.  It's no wonder that one team's notion of complexity would be different than the other.

So, what are we to say of story points and the schedule?  Is there a conversion between points and days - as so many people long for?  No.

Velocity maps to time.  Points do not.  Points are unitless but velocity has units: points/sprint.  A sprint is a unit of time, so a velocity is exactly what people are looking for.

If you need to know the time in advance of the work, perhaps for an estimate or bid, and don't have a velocity then you can spend some time doing a task breakdown of each user story.  That is a lot of work.  Many of those tasks will be obsolete or out of date by the time you get to them.  This kind of wastes will eat away at the project and slow your velocity but it may be the only way to get an advanced assessment of the work involved.   If you don't have an established velocity, this may be your best bet.   On a big project this could take weeks, so it doesn't come for free.

If you have previous experience working together and have an established velocity, then estimating the schedule for new work is simple.  If you don't have an established velocity, you may be able to guess your team's velocity and avoid the extra work of creating a "work breakdown."   This is risky, but if there are a lot of unknowns and a detailed analysis is as likely to be as accurate as a solid guess, then why not?

Whether you have an established velocity, made one up, or did a work breakdown, you can still get an assessment of your performance very quickly.   Perform a sprint or two and see how fast each of the teams is "earning story points" and then use that "velocity" to forecast when the work will be done and to track progress along the way.

It's important that you are realistic and view the earned velocity as more important than your original estimate.  Failure to communicate differences between the two are generally catastrophic.

I hope this story illustrates why expecting points to map to time is not a valid exercise.  Velocity maps to time, not points.  Attempting to map points to time is not only futile, it's actually nonsensical.  If your project plan is nonsense then don't expect your team members to follow or respect the plan.