Fix your Scrum with flow!

For a while I kept struggling to find an effective strategy to help our Scrum Teams benefit from what Scrum has been designed for: short feedback-loops and collective performance to deliver the right value.

In most Scrum Teams I have worked with, I keep observing the same three patterns:

• Lack of feedback within the Sprint. Work is executed in a waterfall approach: testing happens only at the latest days of the Sprint and feedback is delayed at the Sprint Review.
• Team members tend to focus only on their individual work and make sure that everyone is individually busy. This resulted in starting most of the Sprint Backlog items in parallel.
• Release dates forecast is made difficult due to lack of regularity in delivering a potentially releasable Increment from each Sprint.

The expected benefits of Scrum to optimise predictability and to control risk are undermined.

I kept looking for a strategy to help our Scrum teams address these patterns. The end-goal (the why) is to have them:

• Shorten their feedback loop to validate assumptions and control risk,
• Focus together on small batches to achieve collective performance,
• Reach a regular and sustainable delivery pace for a higher predictability

To help reflect on this, I drew a simplified diagram of Scrum (picture below). All of what we plan for the Sprint is an assumption until we get feedback to validate that it is the right value (it is what our users really want).

Then, I have an obvious question for you: “What feedback loop length would you target in order to validate your value assumptions?”

Let’s keep this question in mind as we go throughout the article.

Shortening the feedback loop (to validate our assumptions about value) is all about having the Sprint Backlog items moving as fast as possible throughout the Sprint activities to have them validated in an integrated environment, right?

Speeding up the movement of the Sprint Backlog items is all about increasing the efficiency of your delivery process. You can think of a river as a way to transport your items to deliver them to your customer. To the extent the flow of water is fluid, the faster your customer will get their delivery.

So our focus is on optimizing the flow of value within the Sprint to have short feedback loops that validate our assumptions and ensure delivering the right value.

How do we get there?

As said earlier it’s about the movement of value through your Sprint activities or workflow. Then obviously the first step would be to have the team define and visualize their workflow.

The workflow definition should help your team move towards a collective ownership mindset. Two basic workflow rules to help your team in this mindset shift are that:

• Columns shouldn’t reflect roles in your team. Don’t create roles’ silos.
• Work items always move forward (flow). “The work shouldn’t move where I am. I should move to where the work is.”

The workflow definition also helps reflect on the lifecycle of work needed to get feedback and create value. The Definition of Done is part of the workflow definition and must, therefore, include a mechanism of feedback, even in the case where you don’t have access to your users or your Product Owner has limited availability.

The workflow definition and the visualization of the lifecycle of work (value) will help the team get a sense of flow within the Sprint.

Remember: we are looking for optimizing the flow to shorten feedback-loop and deliver value faster to our users.

How can we measure our feedback-loop length and optimize it over time?

“You can’t improve what you don’t measure.” Often attributed to Peter Drucker.

Cycle Time is a flow metric that measures the feedback loop length — or how long it takes to deliver value to our users. It’s a simple metric that requires only two data: when you start on an item and when you finish it. The metric then is “end date” — “start date” + 1.

This implies that you define when work starts (first activity) and when work is done (DoD) within the Sprint. You can simply track these data in a spreadsheet for each of your Sprint Backlog items. As it’s about the measure of how long we deliver value, then you can exclude tasks or sub-tasks and apply it only at the items that are value placeholders (User Story for example).

Cycle Time can be also displayed in a scatterplot chart:

As soon as an item is Done, you add a dot to the chart. The chart will display multiple dots (done items). Each dot has its own Cycle Time.

What would your target Cycle Time be? How can you define it?

To answer these questions we use percentiles to avoid the fallback of averages. Averages have the disadvantage of being biased by outliers. Using averages also means that you accept taking the risk of being wrong in 50% of the cases!

Calculating percentiles is really simple. For instance, the 85% percentile is about counting from the bottom of the chart and stopping at the dot closest to 85%. There you draw a line (green line on the chart above). The correspondent cycle time is called the Service Level of Expectation (SLE).

SLE is our target cycle time and contains 2 pieces of information: how long it took to finish an item in the past, and a level of probability. From the example above, our team has been able to finish an item within 16 days or less with a probability of 85%.

Now that we have been able to set a target cycle time (SLE), how are we to optimize it over time?

An effective way to do so is to apply the principle of “stop starting, start finishing”. You may have already heard about it. What’s new here then?!

Flow gives you 2 actionable flow metrics to help implement this principle and then optimize your Cycle Time.

• Work In Progress (WIP): the first part of this principal “stop starting” could be done by limiting WIP.
• Work Item Age: the second part of the principle “start finishing” could be done by preventing items from ageing.

Limiting WIP to “stop starting”

Once you have defined your workflow, now part of the visualization you also need to include how you are going to limit Work In Progress (WIP) (picture below).

WIP limits could be applied per column or cross columns. WIP limits reflect the capacity of the team and the team should honour its capacity by pulling new items when going under their WIP limits.

Limiting WIP helps create a pull system where team members pull new items only when they have capacity to do so. Team members should be pulling work from right to left.

WIP has a direct effect on the Cycle Time. It may sound counter intuitive, but on average, the more things you do, the longer it takes them to get done (Little’s law for more details on this).

Work Item Age to “start finishing”

If we look to finish items faster, then we need to monitor their age to trigger the right decision. Monitoring an items age at the Daily Scrum is a powerful technique to guide the team to the right action plan for the day. The expected result would be that the team swarm/mob/pair on the most aged items. The team will be constantly asking the question “which item is ageing too much compared to our target cycle time (SLE)?”.

Let’s recap

Flow is a strategy to help your Scrum Team shorten their feedback loop and achieve collective performance. To help you and your team in this journey, here is a recap of the suggested practices and flow metrics:

• Define and visualize your Sprint workflow to get a sense of your work lifecycle and collective ownership of value delivery,
• Assess your current Cycle Time and set a target (SLE),
• Optimize your Cycle Time to shorten the feedback-loop by:
  – Limiting WIP to work on small batches (“stop starting”)
  – Using Work Item Age to trigger collaboration and avoid your items from ageing too much (“start finishing”)
• Keep optimizing your Cycle Time to reach a stable flow for higher predictability.
• Keep improving your workflow definition (stages, pull policies, DoD…).

These practices should be applied as incremental experimentations to improve your process of value delivery. You need to continuously adjust them as you go (like an aeroplane cockpit indicator) to reach your optimized Cycle Time and stable/predictable flow.

Scrum is founded on empiricism and lean thinking. Flow helps in reducing waste (process efficiency) and inspecting and adapting small increments (small batches).

Remember the question we asked in the beginning of the article. “What feedback loop length would you target in order to validate your value assumptions?”.
Would you change your initial answer?

Keep reflecting on:

• What would be your target Cycle Time?
• How could flow bring efficiency and predictability to your process?

Credits: This article is made possible thanks to a collaboration with my colleague Scrum Master Samuel Leroy. We prepared and run together a workshop on this topic at XP Days Benelux 2022 conference.