What is Velocity?

It definitely does not mean percentage complete over time or number of hours completed on a task or number of story points or any other such unit. What it essentially means is how fast, how quick can you go? It means speed of doing any action or motion over time.

Velocity = Quickness of motion : Speed

Or Rate of occurrence or action : Rapidity

Or Rate of turnover


In case of software development team, it means how fast can you deliver from first sprint to next sprint? Can you go faster every sprint? Faster than before, faster than ever however, in the direction that business wants. That is, can you deliver the most important business functionality in fastest possible time.

What does it mean for an organisation?

A simple example could be two companies trying to get same kind of cars in the market. Same kind, may be same engine size, same efficiency, same length. However, whoever can launch the product first, Velocitywith required quality will win more customers, will win more orders than one who launches say after 3 months.

It is all the more critical in today’s market place, where product life cycle has reduced significantly and speed of innovation has increased tremendously. Simply speaking, organisations which are not continuously innovating or evolving or reinventing their core strengths will not survive the market dynamics.

Again, if I go back to Formula 1 Car team example, your Formula 1 team should be focused on how fast the car can go, lap after lap. Not only it should start fast – 0 to 100 in 6 sec, it should continue to accelerate with every iteration and it should do so without causing any vibrations or damage to the engine, or to the frame or importantly to the driver.

In Formula 1, is it possible for one person from the car team to achieve this? or for one engineer to achieve this? Or for driver to claim all the credit? Absolutely NO. It is the whole team that works together to achieve one result.

In the discussion in my previous post with the program managers, what was the problem they were trying to address?

Problem was they could not predict release date to the business. What is the root cause of this problem? Estimation? Business asking for release? Or waterfall practices?

Well, my view all three are problems.

Problem 1 : Estimates and release dates

You need to ask what benefit estimates gives you? If you are a business person and your development manager, project manager, development team tells you, that they can deliver everything after ten sprints of three weeks each. That means they will deliver your software sometime in the future which is ten months from now. How does that information help you?

From experience when your team says ten sprints, it will be more likely that they will finish essential Estimated Releasefunctionality in fifteen sprint. Cosmetic changes, documentation etc. will take another 4-5 sprints. So, what is the benefit of asking today, that when will they deliver? Or asking them to predict the future?

Most common answer given by the business is : release plan or time to market. That is based on this information, we need to plan when to release our product or service to the market.

So I ask again, if your development team gives you an estimate that ten sprints from now they will be ready with delivery, will you announce a date to the market? Most probably you will add a buffer at least 25% before you announce date. And if you announce the date as promised by your team would you be happy changing it if your team doesn’t deliver? Or if you will not change the date, then would you be happy taking partially completed product to the market?

Most of the times, answer is NO. We cannot change the date. We cannot take partial product to market.

So I again ask, then is it not better rather than asking for estimate, you ask your team to complete it AS FAST AS POSSIBLE and review the completed product every 2-3 weeks? Then as you get closer to completing the product, based on your own reviews of the product, you can probably announce release date one month in advance? Is that not what you want?

Big answer is YES.

Problem 2: Business asking for release dates

This is a big legacy of waterfall, as well as management by objectives. Traditionally business treats itself separate then delivery or engineering. It thinks that there job is to throw over the project to the Release Planengineering and ask them to come back only after it’s complete. However, such a thinking has got many projects and organisations in trouble.

In today’s rapidly evolving business, business has to talk to the development or engineering every day. Business should be able to drive the project rather than just being mute spectator.

Problem 3: Waterfall practices

Asking for delivery commitment from teams even before they understand requirements. Asking teams to deliver on those commitments, and declaring bonus or punishments based on adherence to those Waterfallplans. All this is just symptoms of old waterfall thinking.

In real world dates have little value if you can’t release on that date or if you have defects in your product and still you are releasing. What makes sense, is to focus on delivering small chunks of quality functionality every two-three weeks and then releasing product once enough functionality has been completed.

Business should work with the team directly

So instead of business asking for release date, it  should be working with the team to declare when functionality would be complete and when the product can be released. It should be directly working with the development team on the top most priority business requirement. So, if they point their team to one most priority requirement broken down to finish in 2-3 weeks. Ask entire team to work only on that and nothing else. One requirement, one team. And focus on removing anything that comes in the way of completing that requirement in fastest possible time. What would be the possible outcome for the business?

For example, if requirement X is divided into ten sub requirements (not time estimated), each to be taken one at a time. What will happen if team starts with first (x1), completes it in say 3 weeks. However, team and business both work together to realise that if we improve, fix few things we can do it in 2 weeks. Next requirement x2, with new improvements will be done in less than 3 weeks. So on and so forth.

This is called velocity. Based on this ever increasing speed of delivery, business would say once all ten sub requirements are complete we can deliver. It could take ten weeks or ten sprints, however, quality product with zero defects would be delivered to the customer.

Focus should be on ever increasing speed of delivery that is Velocity


Leave a Reply