A long while back I wrote an article about “Increasing Velocity vs. Stable Velocity“. In that I listed a catalog of improvements that once done, could help make your sprint velocity stable. Of course the full list would probably never be realized as it’s unlikely teams would do everything. The reason I created the list was to give visibility of the many things an agile team could try. For some people, the list really wouldn’t have helped. Always easy to tell people what they could do but finding reasons and value for doing it is sometimes hard.
I wish here to talk about velocity and the business. Businesses have a tough time keeping their many shareholders and/or stakeholders happy with continuous growth and prosperity. One thing that makes all these people happy, or at least stops them from lynching the execs, is for the business to predict when things will happen with some accuracy. If you’re a software product company or a digital product company, the people you count on for this are your agile teams. The Product Owner manages the business aspects of sprint work while the development team manages the customer solutions. Combined into one agile team, the product owner and development team forecast what they’ll deliver anywhere between 0 to 12 months. This forecast is based on several factors but a key component will be the team’s past track record for delivery, their velocity.
Velocity is simply the average amount of work one team can successfully complete in one sprint. For most teams, this may take a few sprints to stabilize as the team finds itself through the stages of formation.
Velocity sits at the team level and does not translate to individuals on the team. If a team of 5 has a velocity of 40, adding another person doesn’t mean their velocity goes to 48. If the team’s velocity is 40 story points per sprint and a new person is added to the team, the team’s velocity is more likely to fall in the near term rather than rise. This is due to the disruption the new person causes in the team, needing mentoring, learning how to do things the “team’s” way, and the change in group dynamics (see stages of group development). So keep it simple and use velocity for the team.
The product owner
The product owner represents both the customer and the business within the agile team. It is the product owner who’s held accountable or at least responsible for getting the most valuable product features into the hands of the agile development team at the right time. They do this to meet both delivery (business) and customer demands. It’s the agile development team’s responsibility to match their forecasts with actual deliveries, scaled appropriately from near term (sprint) to longer term (release). All this needs to happen with regularity. All this can fail if the underlying forecasts are unreliable. The agile team’s velocity is the most reliable measure used during forecasting.
The single wringable neck
It often falls upon the product owner to meet promised delivery dates. This is strange because it’s not the product owner doing the work. The product owner relies on the development team to deliver. The product owner needs to manage business expectations once an agile release is in flight. This happens regardless of the reliability of the forecasts made by the team. However, the amount of effort and stress associated with managing these expectations can be mitigated if there’s a solid foundation to base initial forecasts on. The solid foundation starts with a predictable team velocity. Once a predictable velocity exists, product owners can begin challenging the agile team to achieve degrees of accuracy in their forecasts & estimates. For example, the product owner and development team might set planning goals as:
- Get 85% or better accuracy between 0-6 weeks (sprints)
- Get 60% – 70% accuracy up to 3 months (release)
- Get 50% accuracy 3 – 6 months (release/future release)
Make success possible yet challenging
It may be the agile team has an unpredictable velocity, especially common with new teams. Asking a team to have an estimation accuracy of 90% for a two-three sprint window when the development team is barely at 35% is asking for failure. Instead if the team is at 35% accuracy, challenge them to achieve 45% within the next two sprints. But simply challenging the development team won’t be enough by itself, you’ll need to work with their Scrum Master to change the team’s current processes. This often means making backlog grooming sessions better.
The product backlog is an example of a combining longer term strategic planning with near term tactical planning in one convenient place. The product backlog epitomizes the concept of Just In Time (JIT) planning. The product owner owns the product backlog and they, along with the development team, need to continuously maintain it. The product backlog is prioritized from top to bottom. It’s very common to think of the backlog as an iceberg with 3 distinct layers. The top layer is the bit of the iceberg that is above water, is the sprint ready layer. User stories here are the most refined and best understood. The product owner desires these stories to be the most accurately estimated to make sprint commitments viable. One grooming goal therefore is to get user stories to the highest state of readiness or ‘sprint ready‘.
The middle layer is populated with stories that are in planned releases including the current release but are generally less well understood. These stories are estimated but will likely be split into stories sized to fit within the sprint time box. As stories are split and new understandings are reached, they are re-estimated. Stories from the Release layer are feed into the Sprint layer as openings appear, based on priorities. This is a continuous process. A second goal of backlog grooming is to split stories down to a size that can be completed (Done) within the sprint time box.
The bottom layer but no less important are the stories for Future Releases. These stories might represent new feature or new products. These stories are the least understood and often are more speculative in nature. For example, a Future Release story might get dropped if there’s no customer support or the business ROI is too weak. Future Release stories feed into the Release layer as openings occur. The third goal of backlog grooming is to validate the customer/business value of new features, prioritize them, and allocate to releases as space becomes available
The backlog and velocity
Let’s get back velocity and see how the product backlog and velocity are inseparable. At the Sprint layer, the amount of work, usually measured in story points, is based on team velocity. For four teams working from a single backlog and the cumulative velocity per sprint is 135 story points, the Sprint layer might have 405 story point worth of stories (3 sprints X 135). (I recognize that skill levels within teams matter and I talk about cross-skilled teams at the end but for the moment, assume the work is equally divisible by team strengths.)
For the Release layer, velocity is used to project work capacity into the near future, often 1 to 6 months or one or more releases. Below is an example of a multi-release story map from Steve Regalsky of Winnipeg Agilist. Story mapping is probably the best way to engage the development team(s) and get realistic commitments using their own velocity metric.
For future release layer, velocity plays only a small part in that you can estimate these features or new products by the number of sprints they might require to complete. This is done in portfolio planning where costing is done at a gross level. It’s a good idea to use T-Shirt sizing at this level to abstract the estimate and help prevent any premature expectations. The question development answers is how many sprints would this feature or new product take given your current velocity? A guide to T-Shirt sizing could be:
- Small (S) => 1 – 3 sprints
- Medium (M) => 4 – 8 sprints
- Large (L) => 6 – 12 sprints
- X-Large (XL) => 9 – 18 sprints
- XX-Large (XXL) => Unknown
It would not be unusual for one Future Release story to be enough work for one or more releases.
Tips for getting and using team velocity
There are several activities that can improve velocity but there are also a few things a team or business can do to help make team velocity useful.
- Keep the team intact and constant. This means no swapping people in and out of the team on a random basis.
- Co-locate the team. The team sitting together will build stronger bonds over a shorter period of time.
- Be patient and give the team time to grow. They’ll go through the stages of group development over a period of time but give them that time. Use team building exercises such as Journey Lines to help them grow closer.
- Engage the team with the business early. Get the team thinking solving business problems and customer problems is their responsibility.
- Do not use velocity as a stick. The team’s velocity is for the team to use and improve. Enable the team to improve and trust that they will improve.
- Have the team create and agree to what success looks like. The team needs a common understanding of what Done means for sprint work.
- Maintain strict adherence to how velocity is calculated. In its simplest form, velocity is a count of work completed, averaged over several sprints.
- Improve ‘T-skills’ within and across teams. The goal is to progress work, not have everyone equally skilled. Reduce reliance on specialist roles.
- Focus coaching and training activities to areas that can improve velocity. Maximize the value of agile ceremonies and interactions within the team, not just doing.
- Be honest. Only count stories that achieve a ‘Done’ status towards velocity. A story that needs 30-minutes in the next sprint to be complete counts for 0 in the current sprint.
Cross-skilled agile teams
If the agile teams are limited in their skills and unable to work any story in the backlog, this complicates things a little. Velocity can fluctuate wildly when work needs divided up based on skill. This can hurt if you have a team but no work for their particular strength. In practice this usually means stories are not worked in a priority order. For example, the backlog might have stories targeted for IOS developers and Windows developers. However, within these categories, stories would be in a priority (customer value) order.
The only realistic solution is to upskill the agile teams so a team can progress most any story in the backlog. This is achieved by building ‘T-Skills’. ‘T-Skills’ means although there’s depth in a particular discipline, the person has some capacity across several other skills. Teams can begin analysing their ‘T-Skills’ with a skills matrix.
A skills matrix can help identify areas where weaknesses exist. For example in the matrix above, we see that several skills have only one contributor. These would be prime areas to begin any cross-skill training. Having Sid pair up with Alice on occasion to build his Backend skills might be a good idea. This would make two people who can do Backend work although not with the same rapidity but does allow work to progress when the key person is unavailable.