Agile Team Velocity and Forecasting

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

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 backlog

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.

 

Agile Product Backlog Refinement (Grooming)

Feature image by Photo by Crystalline Radical.

 

In my last post, Agile Product Backlog Grooming Reduces Risk, I talked about using Product Backlog Grooming sessions as a project risk mitigation tool. In this post, we’ll further explore the details of backlog grooming with some tips to increase the value of grooming. These tips are for the Product Manager, Product Owner, and Development team to help make the grooming experience valuable and easy.

Development and Product teams begin the process of collaboration before the Product Manager has pitched the new/modified product idea to the business or before anything is actually in the product backlog. At this stage, most if not all information is based on previous experiences and assumptions. However, depending on your business structure, the Product Manager will probably validate most Problem & Solution assumptions prior to presenting the project to the business. The Development person here is the product architect or designated representative of the team(s) familiar with the product.

  1. Product Manager gets an idea (from any source) on how to achieve business goals with his or her product
  2. Product Owner and Development discuss feasibility of the idea, reworking the idea until thought feasible, based on the limited knowledge at hand.
  3. Product Manager/Owner develops business rational including the risks based on limited knowledge.
  4. Product Owner and Development collaborate to create the Business Canvas. You might consider using Ash Maurya’s Lean Canvas or Roman Pichler’s Product Canvas and Vision Board.
  5. Product Owner and Development collaborate to validate the Customer Problem and Solutions with customers through interviews and user testing. (Remove any Canvas entries that failed validation. Might need to go back to step 1.)
  6. Product Owner and Development provide an initial estimate. We’re looking for the ballpark, order of magnitude type estimate here e.g., 6 weeks or 6 months?
  7. Present Business rational and Canvas to business stakeholders for approval and funding.

Establishing preliminary understanding

The Product Manager’s product feature idea is now on the product roadmap (or equivalent). Depending on your business’s average lead time for work all the following steps could occur over the course of months or in rapid succession. My own experiences had roadmap items identified up to a year before the project, not very timely for customers but there are other factors at play including priorities, competition, and ‘hunches’ from the executive team.

These few steps are for illustration purposes and may not be what your team wants or even needs so feel free to modify for your specific needs. These steps will probably be done once. However, depending on the timing, may need to be revisited if the Product Owner and Development architect determine the data gathered has gone stale.

  1. Create one epic in Jira for one idea or feature. Most people use a tool rather than a big wall these days but if you have the wall space and an enthusiastic Scrum Master, by all means use a wall to define the high level projects.
  2. Development architects do initial technical scoping and high level design or impact mapping on current architecture. Unless you’re contemplating a new product, this will be based on the product’s current technical foundations and platforms.
  3. Full development team discusses the problem and possible solutions (non-technical). This is with a larger group of people using validated feedback from customers about how they envisioned their problem being removed from the user perspective. This serves as the baseline for UX designs. The discussion stays at the ‘what’ level but the full team might have something to say about feasibility and sizing.
  4. Full team provides updated estimates for Product Owner.
  5. Create the paper or wireframe UX designs & validate with customers.
  6. Development team (developers, UXD, and testers) along with Product Owner to define or confirm their collective understanding of what a ‘sprint ready user story’ is i.e. they define the Definition of Ready.
  7. Full team provides an updated estimate for the Product Owner.

The value to the business achieved during the above steps is to develop a good high-level understanding of all the work necessary for the initial epic user story. The team does a couple of estimates so the Product Owner can determine if the feature is still economically feasible. You’ll note customer involvement, looking at display mockups. The ideal situation is the customer finds that only a portion of the proposed work is necessary. The Product Owner and Development team keep focus on satisfying the customer in order to achieve a business goal.

On-going backlog grooming

This section details the steps for mainstream backlog grooming that gets repeated until a story is actually in a sprint. Most of these steps will be familiar. The full development team is ideally one Agile Scrum team but if there are several teams working a product, the grooming session should include those teams likely to work the stories. With a large number of teams (> 3), the LeSS framework, by Craig Larman & Bas Vodde,  suggests doing the grooming sessions in stages:

  • Overall Product Backlog Refinement (shared among all teams)
  • Team-level Product Backlog Refinement
  • Multi-team Product Backlog Refinement

 

  1. Full development team, using UX and architectural designs, begins breakdown of Epics into smaller stories using the Definition of Ready (DoR) guide the team established in the previous section.
  2. Product Owner and Development team continue to prioritize stories based on customer/business value but taking into account any implementation concerns or risks.
  3. Each user story is reviewed starting with those at the top of the backlog. Every user story is accompanied by notes, acceptance criteria, and estimates using the DOR as guide. If the story can be associated with a step in the ‘customer journey’, that would be a great help for stakeholders toward understanding the work.
  4. Product Owner and Development team review & discuss each story including those that are marked ‘sprint ready’. For stories not ‘sprint ready’, discussions on how the story could be implemented, could be tested, the customer value, and discuss compromises as necessary. ‘Sprint ready’ stories are checked that nothing has change that could affect the team’s understanding of the story or its priority.
  5. Again prioritize stories based on costs and customer / business value
  6. Check that all Epics and UX designs are covered with stories and have been prioritized.
  7. Make stories sprint ready and keep anyone who’s interested informed. My experience is most managers will not be looking through tools on a daily basis to determine progress. But being transparent is critical and using a big wall in a conspicuous location will provide the necessary details to management. If you have a ‘story wall’, you can use colored stickers to indicate status of stories i.e. sprint ready.
  8. The last step of every grooming session will be to again review the estimates and priority of the stories. Always check  the most valuable work is top-most on the product backlog.

The desired outcome of these sessions is:

  1. Big stories are split
  2. Stories are estimated
  3. Stories are well understood by the team(s) likely to implement them
  4. Stories are made ‘sprint ready’ based on the team’s Definition of Ready

Summary

In my experience, the amount of time needed between roadmap item to having a couple sprints worth of ‘sprint ready user stories’ is about 4 weeks calendar time, assuming development teams are busy doing sprint work as their primary activity. This provides time for any proto-typing, UX design, additional customer/user interviews, and getting input on marketing, sales, support, or other business concerns that could affect implementation choices. This could take a few days if done by an experienced project team in a full-time workshop.