I like Scrum. As a framework it supports ‘the doers’, which in my opinion, leads to better products. But I still come up against the same questions from clients, questions such as, “when will it be ready?” – which is of course valid. Scrum’s answer to this is velocity, which in its simplest form is the average throughput across multiple Sprints.
This is where I start wanting a bit more out of Scrum to help with those situations. I had been reading about various hybrids such as Scrumban, which smooshes together parts of Scrum and Kanban. But for me this feels like a case of ‘Scrum but’ – the age-old practice of not committing to a framework because it doesn’t suit you, therefore distilling the benefits of the framework.
So I was interested to get a spot on one of Scrum.org’s courses, Scrum with Kanban. There’s a lot of importance placed upon the ‘with’ here. Unlike a hybrid framework, Scrum with Kanban uses Scrum as the framework, so all the Events, Artefacts and Roles are adhered to. The Kanban elements introduced are complementary to that, rather than picking and choosing from both.
As someone whose role it is to introduce new ways of working, I feel that adding complementary practices to a framework a team is already using is more effective and less disruptive.
On another Scrum course, the trainer told me a story about a stakeholder asking when a piece of work would be done by. His answer was to tell the stakeholder, “I’ll tell you next Sprint”. His justification for this being that Scrum isn’t about precise planning. The Project Manager in me felt that this wasn’t a good enough answer and I know a client would not be happy if I deflected their question in such a way.
And this is where the metrics introduced in Scrum with Kanban really piqued my interest.
You’ve got to know the flow to go with the flow
Kanban is centred around the notion of moving value through a system. This is called Flow. Scrum’s pillars are transparency, inspection and adaption – essentially a feedback loop in which information and improvements are identified, translated and actioned. When Kanban metrics are applied to this feedback loop it means focus is given to improving the Scrum pillars.
Flow is is tracked using four basic metrics:
-
Work in Progress (WiP)
-
Cycle Time
-
Work Age Item
-
Throughput
Work in Progress (WiP)
Work in Progress (WiP) is pieces of work that have been started but not yet finished. Kanban actively works on the premise that the team limits how much work can be active at any one point, which is achieved by placing WiP limits on the stages of your workflow.
Work can only be pulled into the next step when the WiP limit allows. This makes the team work collectively to enable the work to move through the system and not overload any one stage.
This in turn helps identify bottlenecks which the team can address.
Cycle Time
The point an item enters the workflow, to the point it leaves it, is known as the Cycle Time. In Kanban we track how long this cycle takes for each item.
Because software development is a complex process, we cannot give certainties. But what cycle time does enable us to do is build a picture of all the historical items we have delivered and use this to manage expectations.
Work Age Item
When an item has been started, we track it. Work Age Item is simply how long an item has been in the workflow. Therefore this only applies to items that haven’t been finished.
It gives a current picture that we can use to help manage the work in flight. Combined with Cycle Time, we can start to question why something isn’t moving through as quickly as our data tells us it can.
Throughput
Cycle Time and Work Age Item look at individual items, whereas WiP and Throughput look at our items collectively.
Throughput is how many items we complete in a given period of time. It’s pretty similar to Velocity in that respect. So this is easily applied in a Scrum scenario as our unit of time could be our Sprint.
Kanban Practices: the secret sauce
The secret sauce is combining these four metrics to actively manage the work in progress and manage stakeholder expectations. To be able to do this, you need to define and visualise your workflow. This is a practice already employed by Scrum teams, so not a new concept.
Once you can see the work, you can manage it.
As set out, Kanban expects the team to set WiP limits on each step of the workflow which creates the pull system. Active management places emphasis on the team to collectively move items through the workflow. Therefore if a WiP limit is reached on one (or many) of the steps then the team tries to find ways to move the items. For example, that could be helping test items rather than starting development of new ones.
Constantly reaching WiP limits also alludes to an imbalance in the number of items being started versus the number you’re able to finish. Here, the team should look at their WiP limits and workflow and make adjustments so that the bottlenecks are reduced and work coming in matches work going out.
The age of items in flight is also an indicator for the team to act on something. Items should not be left to age unnecessarily, and the team should monitor this on a daily basis.
How long will it take?
The last element I want to share is the Service Level Expectation (SLE). This is the use of cycle time to establish a forecast for how long something will take. It’s made up of two parts: a number of elapsed days and a probability linked to that time. For example, 85% of the time an item should be finished in eight days or less.
So now that question of “how long will it take?” has a standard answer I can use, albeit with a carefully placed “... should”.
Previously from Chris:
Stripped down but still Scrum – updates to The Scrum Guide
How the Scrum values are helping us deliver products throughout lockdown
VIDEO: Talking Design Sprints and Scrum (with Kyan CEO, Laurent Maguire)
We are Kyan, a technology agency powered by people.
