Velocity. By far the single most important word to any Agile team. Whether you are currently practicing Agile, looking to adopt within your organization or trying to achieve your Agile Nirvana, understanding Velocity is fundamental to achieving success with Agile. Beyond a basic understanding, it’s important that you learn how to measure, influence and improve upon it. Velocity is a point-in-time metric (unit), used to accurately measure the value that your product development teams are delivering to your business.
Calculating your Agile teams Velocity is quite simple. Just sum the total estimates (story points, days, ideal days or hours) of user stories, requirements or backlog items that were delivered and accepted within a prior Sprint (iteration). If this is your team’s first iteration you can still plan your initial Velocity. A good rule of thumb when using time-based estimates (e.g., days, ideal days, etc) is to plan initial Velocity at one-half your team’s total available time. When doing so, keep in mind that you need to account for overhead (e.g., meetings, email communication, documentation, etc.).
For example, let’s say that you are using an iteration length of two weeks and that you are working with a team of four developers. Using this example, you would be working with a total of 40-days (4 developers X 10 working days). Applying the rule of thumb above, your team would ideally plan the iteration with 20 days of work. Using story points as your estimate? I’ve found that using roughly one-third of total story points planned is a great place to begin for most teams.
Using Velocity Charts
Like burndown charts, velocity charts are invaluable as they provide insight into how a team is progressing with their current and any previous iterations.
For each iteration, a typical velocity chart will show the sum of estimates committed against the sum of estimates delivered and accepted. Velocity charts can help your teams plan more accurately. They are easy to produce, so whether you are using a tool with this feature built in or not, you should take time to produce one for each iteration. The image above is a velocity chart taken from a project being tracked within Atlassian JIRA.
Using Velocity as a Guideline
It can take several iterations for before your teams velocity stabilizes, but from the very first iteration onward, your teams should be using the velocity of your prior iteration(s) as a guideline to help steer planning sessions and influence team commitments. When first adopting Agile, it can be difficult to contain the teams desire to overestimate their velocity. This is natural and actually something rooted deeply in human behavior. The best way to prevent it from occurring is to temper your commitments by using the teams own historical velocity as a guideline. It’s certainly okay to stretch and grow the teams velocity if you are consistently achieving and/or exceeding your commitments as long as it is supported by your historical velocity.
Keep Velocity Simple
Velocity is a fairly simple concept. It is easy to measure and track a teams velocity over time. This is actually intentional and much of the value comes from the fact that velocity is straight forward and easily understood.
Some teams we’ve worked with get this wrong – they overcomplicate their velocity measurement. One way to keep the understanding of this Agile metric pure and simple, is to write down the meaning and have it physically present above locations where a team’s velocity is out on display.
Stable Velocity leads to Predictability
When an Agile team achieves a consistent velocity over time, their velocity becomes “stable” and in turn the team becomes predictable. Teams that are predictable make it easy for a Product Owner (PO) or set of stakeholders to assess the delivery date for a fixed scope product backlog, or even a portion of the backlog such as an Epic or series of Epics.
When working towards a fixed date product release predictable teams have the confidence to make commitments to customers. They also have the ability to have a discussion about features vs time trade-offs as they have a greater understanding of their cadence and capabilities.
- have a consistent rhythm and cadence that others don’t,
- help to motivate other parts of the organization,
- collaborate more effectively amongst themselves and with other parts of the organization,
- ship product!
So, what’s holding you back from measuring your teams velocity? If you don’t measure it you can’t improve it ((William Edwards Demming)).