It's Always About Value The Scrum Guide 2020

There is a thing about agile that is often forgotten, especially among people who are new to the concept: It has always been about creating value. The very agility, that is: the ability to change one's mind and plans about things, is only important as it helps us to improve our ability to create value.

The newly, as of this writing, released Scrum Guide 2020 reminds us about this. The latest version incorporates some classical agile pracices into the very framework, to help us maintain our value focus.

The Agile Manifesto

The agile manifesto was written late in the history of agile. The people gathered in an American ski resort to write it, in February 2001, were agile practitioners since long time back.

But they didn't have a name for what they did. When asked, they just called it "the new way", or "the lean way" of building software.

Many of them were inspired by japanese companies, Toyota in particular, and their methods of developing both products and their ways of working.

Not because the early agilists wanted to be better at building cars. But one of the key elements in lean and the Toyota production system is the relentless focus on creating value. "Value" defined as "meeting customer needs". Avoiding wasteful behaviors that doesn't contribute to value.

They understood that agility, the ability to change, is a key element in development. It is written all over the Agile Manifesto:

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
• We have come to value ... responding to change over following a plan.

But even more often, and earlier in the manifesto, there is this focus on value through meeting people's needs:

• We are uncovering better ways of developing software ...
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Working software is the primary measure of progress.

In their case, it was all about software. In our case, twenty years later, it is about valuable services as a whole. Software is integrated in every service these days, and not something particular. If you are a service developer, you are a software developer. And the other way around.

Scrum

Scrum, the collaboration framework, was first presented five and a half year before the Agile Manifesto was written. And had been in development for almost four years before that.

Scrum was also all about value creation. Jeff Sutherland, its first author, was heavily influenced by lean thinking. One of the problems he wanted to solve was how to help the organization focus on the most valuable things.

Almost all of the Scrum practices revolve around this.

The Product Backlog

One of the earliest features of Scrum was the backlog: a single, ordered, list of things to do. Instead of having a bunch of wish-lists, one from each stakeholder, the organization should be able to condense all the requirements into one comprehensive list.

Early Scrum texts talk explicitely about a lot of things that goes into the backlog: requirements, tasks, investigations, features and so on. The backlog items used to be were very IT-centric back then, since Scrum in these days was all about developing software.

In the last versions of the Scrum Guide, the backlog is just described as emergent, ordered list of what is needed to improve the product. Without mentioning any IT specific terminology. But note that the practice of using a backlog still assumes that you have a clear idea of what improvement means.

That you have a clear idea of what a good product is.

Expressing Value in the Backlog

Since Scrum is silent about the exact contents of a product backlog, others have tried to specify what that could mean.

One of the more popular practices is to divide the backlog into three sections:

1. At the top is the list of small slices: things that a small team of developers can turn into something releaseable in just a couple of weeks.
2. In the middle are the changes that a user actually would consider valuable, no matter how many teams were involved in its development or if it will take months to accomplish.
3. In the bottom are the larger groupings of changes, initiatives that you invest in, in order to achieve effects and reach objectives.

This is the approach taken by Dean Leffingwell in his book "Agile Software Requirements" from 2007, and was used by him when he developed the thoughts therein and created the framework SAFe.

While it is a strength that Scrum doesn't want to specify any particular layout of the product backlog, it has been a weakness that without an explicit notion of value in the backlog (in terms of effects and objectives), the value is easily forgotten.

The question of value is drowned in the pool of things to do. We lose our focus on the impact we want to make.

The Product Goal

To help people keep their focus on the value they are there to create, the Scrum Guide 2020 has introduced the Product Goal as a core practice of the framework.

A product goal describes a future state of the product, and is the reason you do all the changes that you do right now. Every little item in the backlog points to the goal. This is in my experience enormously helpful for improving value focus and reducing the time it takes to deliver something valuable.

If you use the backlog approach explained above, where every change is connected to an initiative with its own effects and objectives, you have the concept of Product Goal already.

The initiative, or Business Epic, is our product goal, if it provides us with a directional statement that points us to a desired future state of the product.

And just like an initiative or Business Epic, a product goal doesn't have a fixed scope of deliverables or changes connected to it. At any time, the backlog is just a hypothesis: these changes might bring us closer to the goal. But we don't know. So lets find out. And come up with even better ideas along the way.

Keep the product goal in the backlog. For example in the format as an initiative or Business Epic. And only prioritize those changes you see are connected to the goal.

The Scrum Guide suggests that you should focus on only one product goal or initiative at a time. That is a really neat productivity trick borrowed from lean: reduce the number of things you work on, so that each thing can be done quicker.

Focus is the key to success here.

The Sprint Goal

Another core practice that helps us maintain our focus on value is the Sprint Goal.

The sprint goal has been around in Scrum since at least the 2010 version of the Scrum Guide, and is described as the reason why we are doing this sprint.

The sprint goal could be just a sentence starting with "After this sprint, we will be able to ...". Or more elaborate by continuing with "We do this by ..." and "We will be able to measure that we have succeeded by ...".

Just as a clear product goal helps us focus our effort, a clear sprint goal helps us have a direction for the sprint. What we do is not pointless. We are not just trying to do as much as possible from a list.

But in spite of its intention, the sprint goal is often just defined as the forecasted number of items in the backlog we plan to do this sprint. Which is totally against its purpose.

The Scrum Guide 2020 strengthens the original thought about what a sprint goal is, by pointing out that having an overarching goal should be the first topic of the sprint planning meeting.

Start with answering the question why we will do this sprint. Then we can turn to the question of what product backlog items could help us fulfill the sprint goal.

I Can Help!

If you want to get some help around making your backlog and your sprints focus on value, just let me know!

Be it through workshops, trainings, self-study material, me being present coaching you, or something else.