Velocity is a measure of how much work a team can complete in a set period of time.  It is measured in Story Points and although it was originally created for use in Software Development scenarios, it can be used in just about every type of team scenario.

Velocity can be measured assuming you have… :

• 1 team (1 or more people – ideally no more than 7 or so) that remains the same over time
• 1 set sprint duration (whatever works best for you e.g. 1wk/2wks/1month etc…)
• Enough work to keep you busy for the duration of the sprint (!)

So the first question is - how long will your sprints be? Let’s assume you go for a two-week sprint i.e. every two weeks you commit to a new set of work that will be delivered end-to-end within the coming two-week period.

Now what?

Okay, so if the team has been working together for some time already then you could start by looking back over what your team achieved over the past two weeks. Pull these achievements together into a list – try not to be too detailed e.g. if you baked a cake then leave it at that… no need to say ‘poured in the flour’, ‘whisked the eggs’ etc. Main outputs only please.

In Software development scenarios this ‘to-do list’ will often be called a Product Backlog i.e. a full list of everything you ever hope to do (!) OR a Sprint Backlog i.e. the list of things you’re going to do in your next sprint.

The ‘to-do list’ will often be written as a series of User Stories (particularly in a software development environment), which are structured as follows… >>

As a ROLE I would like OUTPUT so that JUSTIFICATION/OBJECTIVE

e.g As a Mother I would like to Bake a Cake so that I can feed the children at my child’s 5th birthday party

The great thing about user stories is that they provide just enough information to be useful without being overwhelming.  Also, the way they’re structured means that you’re also focused on the end result without necessarily prescribing a way to get there – this drives conversation and allows the team to come up with ideas for fulfilling the objective that you may never have thought of before… (e.g. Maybe the Mother had a standard chocolate cake in mind, however by presenting the user story in this way, she may find that someone on her team has experience of making cakes in the shape of a pony etc. etc. )

In any case… I digress.

Okay, so now you’ve got a sprint duration and a backlog. The next step is to estimate the relative size of each User Story.

We’re not looking for how many days, hours, minutues it will take your team to bake that cake, buy the ingredients etc…. What we’re looking for is a rough estimate of the relative amount of effort to bake that cake vs. something else in the list e.g. Clean the house after the party.  It’s not an exact science, it’s just a hunch.

For example, if baking a cake is worth 1 story point, then cleaning the house after x30 5 year olds have  played pin-the-tail-on-the-donkey, eaten crisps and danced about for a few hours…is probably about a 5 i.e. 5x more effort (for me!).

To prevent this estimation session from getting too difficult, we restrict the numbers you can use by offering up the Fibonacci sequence as a grading system.

1,  3,  5,  8,  13,  21,  34,  55,  89

In this scenario, an 8 would be 8x more work than a 1, a 13 would be 13x more work than a 1.

Now, get all of your team together for a Planning Poker session. In Planning Poker, each member of the team is given a deck of cards with the above numbers on them. The process of estimation includes a brief introduction of the User Story followed by everyone unveiling their chosen card at the same time. If one person grades it a 3 and another grades it a 55, a discussion takes place – someone might have overlooked the complexity of doing something. The team then re-votes until they agree upon a number.

Start with the smallest valuable output of your sprint – call this a 1.  Now proceed with estimating the rest of your backlog.

Once you’ve estimated everything you did in the previous two weeks, add up the total value of the Story Points. Use this as a starting point for your velocity.

Now, look over your list of things to come. Estimate them in the same way, still using the smallest valuable output of your previous sprint (the 1) as a benchmark for estimation.

Next, collate a series of User Stories totalling your trial velocity. Ask the team if they feel they can deliver that in the coming Sprint – if not, reduce the number of Stories or add them as they see fit. Try not to deviate too far away from the Velocity you achieved over the past couple of weeks.

Now, have a go – see whether you can actually deliver all of the work or not.

If you can’t then commit to fewer Points in the following sprint. If you finish the work early, then commit to a few more in the next sprint. Most teams find their velocity within 3 sprints or so.

Have fun!

Subscribe to the Agile101 RSS to be notified when I upload new Articles, Videos, Templates and Tips.

Related articles:

• Estimating in Agile Software Development (agile-software-development.com)
• Planning Poker – Agile Estimating (agile-software-development.com)