In this article, I will discuss the dangerous dynamic that can arise when a Product Owner, Scrum Master, or the management of an organization focuses a Development Team on velocity.

What does velocity refer to?

The concept of velocity signifies:

The speed at which a Development Team converts Product Backlog Items into a Product Increment that is RELEASABLE.

Pay particular attention to the highlighted word. Feature velocity is applicable when a Development Team can deliver an Increment that is releasable at least once per Sprint. In this case, Done = DoD = releasable. Awesome!

But even in this case velocity does not show:

  • Whether the client’s problem was resolved.
  • Whether team is working on the highest priority problems.
  • Amount of value delivered.
  • Level of client satisfaction.

Velocity only shows that the team was busy with something.

But is this an accurate measure of the success of the products and services? Do the clients value products based on how busy company’s staff are?

To put it another way, Velocity reflects the volume of a Development Team’s output. Unfortunately, this is not enough for the creation of successful products and services.

The feature velocity of component teams = 0

Component teams have the most stable feature velocity. Because it always equals zero. Component teams are by definition not able to convert Product Backlog Items into value for a client. At a minimum they need integration with other component teams.

When a team has Undone work

In my opinion, the most dangerous dynamic arises in cases where a Development Team is not capable of generating a Product Increment that is releasable each Sprint. This means that Done = DoD + Undone and team optimizes just the part of the whole flow.

Let us examine a system diagram that shows the link between the strength of DoD and organizational agility.

The stronger the DoD, the smaller Undone work in the Sprint. Undone work limits the team regarding the number of potential releases, and, as a result, also regarding the amount of feedback that can be received from the market. The more feedback, the more decisions can be made by the Product Owner on the re-ordering of a Product Backlog. That could be called organizational agility — being able to quickly change the direction of a Product’s development. This may prompt a Scrum Team to undertake additional improvements to create an even stronger and more exhaustive DoD.

By strengthening the DoD, velocity decreases and becomes real

How is the strengthening of a DoD reflected in velocity? The velocity will decrease at least in the short term. But this is not a problem if the goal is flow optimization (shortest Lead Time), learning and agility. Velocity decreases and becomes more real!

But how likely is it that a Development Team would strengthen the DoD, if they know that team effectiveness is evaluated according to the velocity?

My answer is unlikely. Focus on velocity keeps the team away from strengthening their DoD. As a result, that inhibits feedback from market, learning and agility.

Focusing on velocity inhibits organizational agility.

When I was a young and an inexperienced Scrum Master many years ago, I focused my teams on velocity excessively, which reduced their agility and increased the amount of Undone work. Nowadays, my advice to Scrum Masters who are just starting out goes something like this:

Forget about velocity, if your team cannot produce an increment that is releasable at least every Sprint. Focus on strengthening your DoD first.

What should we measure then?

I recommend focusing on metrics that show the ability to deliver actual value to the market and satisfy client’s needs. For example, Scrum.org has developed framework Evidence-Based Management, and is offering a range of metrics that shows:

  • A team’s ability to create value in the long term
  • The speed at which value is generated (Time 2 Market).
  • How much actual value is delivered to the market.

In conclusion

I would like to repeat once more the fundamental idea that I want to convey with this article. The basic idea of a Scrum is to create an increment that is releasable at least every Sprint. If your team is already at that stage, then the concept of velocity is useful and genuinely demonstrates the speed at which a team converts Product Backlog Item elements into an increment. If not, please focus on strengthening Definition of Done (DoD) and flow optimization.

The Article’s Main Ideas

  • Velocity denotes the speed at which a Development Team converts Product Backlog Items into a Product Increment that is releasable.
  • Velocity does not show whether clients’ problems are being resolved, nor whether value is being delivered, as reflects volume of output.
  • Velocity only shows that a team was busy with something.
  • The feature velocity of component teams is always zero.
  • When team focuses on velocity and has Undone, it is unlikely they would strengthen the DoD.
  • Focusing on velocity inhibits organizational agility.
  • Focus on the value that is actually delivered to the market.

Scrum ON!

In this little blog I share some tips for multi-team Product Backlog refinement.

What is Product Backlog Refinement?

Product Backlog Refinement (PBR) is an activity that Scrum Teams regularly do to clarify potential upcoming Product Backlog Items (PBI). In single team Scrum, typically the Scrum Team gets together for one or more workshops during a Sprint to create and maintain a Refined Product Backlog. 

Below some example activities you can consider:

  • Understanding what is the right problem to solve: The Product Owner tells a coherent set of stories with a goal and links them back to the business objective. The team discusses “why we are doing this?”, “how do we know we are solving the right problem?”. Some teams use story-maps, impact-maps, Speedboat, Me and My Shadow, or the 5 Whys. 
  • Splitting big items for discussion and learning
  • Estimating items for learning and alignment
  • Understanding Customer needs: The team discusses “Why does the user want this?”, “Are we solving the problem right?”. Some teams use a Storyboard (before/after) and Pain Gain maps.
  • Clarify Items: Some teams use Specification By Example and create acceptance tests for the user stories; use story narratives with Gherkin specifications, flow tables and/or decisions tables.
  • Define Exploratory Test Charters: Identify risks to target; Identify which features need manual testing. Some teams use exploratory test charter for each and use exploratory testing tours to test as a team.
  • Create initial designs: Modelling at whiteboard, design sketches,…

( see our paper in Testing Experience magazine for some more examples ) 

Teams that work together on a single product can benefit from doing multi-team refinement. But how can you do refinement with multiple teams at the same time? And why should you?

Why multi-team refinement?

Multi-team PBR is when all members of all teams refine PBIs together without yet deciding which team will implement which item.

Below you can find some benefits that multi-team refinement can give you: (there are many more benefits, but that would make this blog too long)

  • Adaptability at the product level. Why? because all teams understand all PBIs on the Product Backlog, instead of each team understanding only ‘their’ PBIs ( a subset ) of the Product Backlog. If all teams understand all PBIs then the PO can put any PBIs she seems most valuable at the top without being constraint to the PBIs a particular team understands.
  • Improved self-coordination: Why? because the teams maintain a broad understanding of the whole product and the upcoming PBIs, and therefore are more likely to know of “dependencies” between PBIs.
  • Transparant measure of progress at the product level. Why? because all teams participate in estimating all PBIs and therefore there is one common velocity at the product level, instead of a distinct velocity per team that needs to be combined into a total.

How to do multi-team refinement?

The activities for single team refinement can also be used with multi-team refinement; the biggest change is in the facilitation of large groups.

I like to create new groups from the teams that participate in a refinement session instead of using the regular teams. So, let’s say that there are four teams A, B, C and D. Then at refinement, I ask the teams to form four new groups, each group consisting of a person from team A, B, C and D. Why? With groups consisting of members from each team, all PBIs are refined by at least one person of every team. This creates a shared ownership and broad understanding about the PBIs.

Multi-team refinement formats

When I work with teams, I show the teams 4 ways of doing multi-team refinement so that the teams can then choose the way they like most to continue with and improve.

I work with the following 4 formats:

0. Full Roulette

Each group picks a PBI for refinement and start refining at their station. After a timebox -I like 15 min timeboxes- all groups move to the next station and continue refining where the other group left off; this is continued until the PBIs are refined or the workshop timebox expires. The groups can use whatever technique the like for refinement. 

The full roulette results in good refinements because the groups feel pressure to leave their work clear and understandable as possible for the next group.

1. Partial Roulette

Just like Full Roulette, but instead of the whole group moving to another stations, 1 person stays at the station. This person then teaches the new group what was discussed before they continue with refinement.

I use this approach in the beginning because is that it is easy to start with. After the teams have experienced this Partial Roulette, I encourage them to try Full Roulette.

2. Diverge and merge

In this approach, the groups do a diverge-merge action after each timebox. One person stays at each station and becomes the teacher. Then all groups send a person to each of the other stations. So, let’s say you gave groups A, B, C and D. Then 1 person from group A stays at the station to teach back and 1 other person visits group B, another group C and another group D.After the teach back, the persons return to their original group and share their learnings. Any puzzles, questions are then discussed as a group.

I have worked with this technique with up-to 35 people or so.

3. Teach Back

Each group picks a PBI and refines it. After the timebox is over, each group teaches their work so far back to the other teams and have a Q&A discussion. 

This technique works not so good with a large number of teams, because the teach backs easily take too for long for big groups, and its harder to have a focused discussion with lots of people.

Role of the Product Owner and Customers

During the refinement sessions the Product Owner (PO) and customers play an important role. The Product Owner has to be prepared and understand what is needed from the business perspective. The PO will discuss overall topics at for example a Storymap and also participate in each group when requested. 

You also would like the end-customers or people closest to the end-customers like sales, helpdesk etc to participate in detailed refinement sessions.

The approach I like the most and have seen be most effective is the Full Roulette. If you decide to try any of the above approaches, I would enjoy hearing from you how it worked out.