Cómo la Guía Scrum actualizada impulsa la concentración, la alineación y la aportación de valor

por JJ Sutherland | December 4, 2020 | Blog

Making an idea concrete. That’s the hard part. Just having a vision isn’t enough, you have to figure-out what you are going to do tomorrow to start the long journey to making that idea into something real. And then there is the tricky part. Is what you are going to do actually the right thing to do? You have to get rapid feedback on real progress to know that.

That is what matters. That is the point of Scrum. 

It’s not just something you do. You do it to get somewhere. To deliver value. 

Al actualizar la Guía Scrum 2020, los co-creadores de Scrum no cambiaron Scrum en sí. Lo que sí hicieron el Dr. Jeff Sutherland y Ken Schwaber fue encontrar mejores formas de describirlo. Mejores formas de explicar el propósito de cada elemento del marco. 

Arguably the most notable update in the 2020 Scrum Guide shows how this clarity will drive better outcomes.

Scrum Artifacts and Commitments

I honestly can’t tell you how many times I’ve seen this scenario play out. We go into an organization and find a bunch of teams working on stuff that no one wants. 

It’s like watching a masterclass on the dark art of zero value delivery. 

The problem isn’t bad teams, or bad backlogs, or even bad Product Owners. The problem is there is no connection between what the organization wants to achieve and what the Scrum Teams are doing Sprint to Sprint. Nothing that ties the vision with the concrete steps needed to make it real. 

This is why each of the three Scrum Artifacts now has a corresponding commitment. 

As the 2020 Scrum Guide states, ‘These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.’ Each of the new commitments enhances ‘transparency and focus against which progress can be measured.’ 

The commitment for the Product Backlog is the Product Goal. For the Sprint Backlog, it is the Sprint Goal. For the Increment, it is the Definition of Done.

The Sprint Goal

El Objetivo del Sprint es el objetivo único del Sprint. Aunque el Objetivo del Sprint es un compromiso del Developers, proporciona flexibilidad en cuanto al trabajo exacto necesario para alcanzarlo. El Objetivo del Sprint también crea coherencia y enfoque, animando al Equipo Scrum a trabajar juntos en lugar de en iniciativas separadas.

It is far too easy to come out of Sprint Planning with a Sprint Backlog that is a fairly random assortment of Product Backlog Items that everyone knows kind of need to get done, but not any sense of why, exactly. Why this group of PBI’s rather than some other ranking? What do they add up to? Why is the Product Owner prioritizing this way?

Just as we can individually lose focus by moving from one thing to another leaving a travesty of half-done work in our wake, so to can a Scrum Team. The Team needs to focus on what the purpose of the Sprint is. What do all these things add up to? What are we trying to accomplish? Or to put it more simply it answers the most important question in Scrum, why?

Most of the time, unfortunately, not everything in the Sprint Backlog has anything to do with the Sprint goal. There is almost always some business as usual stuff that just has to get done. That’s okay, what is important is that everything that the Scrum Team is working on is in that Sprint Backlog, so that it is visible just how much of their capacity is being used for the things the customer actually wants and how much is taken up with stuff that has nothing to do with that really important thing that is the Sprint Goal.

A Navy SEAL implementing Scrum on his Team recently told me something that has stuck with me, “Effort is our currency.” Having a clear Sprint Goal says where that currency should be spent and having a transparent Sprint Backlog shows where it is actually being spent. This should lead the Team and Stakeholders to re-evaluate just what value is actually being purchased.

The Sprint Goal is the Team’s commitment to what will be delivered by the Sprint Backlog. The Sprint Backlog is an intimate description of what that Goal is.

Definición de Hecho

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

The moment a Product Backlog item meets the Definition of Done, an Increment is born.

The Definition of Done is the Team’s commitment to quality and value. If something does not meet the Definition of Done it can’t be released and should never be demoed at Sprint Review.

The worst form of waste, according to Taiichi Ohno, the creator of the Toyota Production System, is undone work. Energy has been expended, hours have been put in, some of that currency has been spent, but there is nothing of value created. A half-written process, an experiment halfway through, a piece of code halfway written, a service began but not delivered. 

The Definition of Done gives the Scrum Team a clear idea of what standards the Team needs to meet to be finished with a Product Backlog Item. And the Team commits to reaching that Product Increment at the end of each and every Sprint.

Part of the value of the Definition of Done is that it gives the Scrum Team a clear marker on when things are done. It gives you one of the greatest deliverables in Scrum: The work not done. It tells Scrum Teams where to stop.

One time I was speaking with someone whose job it was to deliver documentation of best practices in a large organization so they could be shared across hundreds or even thousands of Teams. He had a deadline of something like one every six weeks or something. When I asked him what his Definition of Done was, he replied with an all too common refrain, the due date. When I suggested that he define done upfront I could see his whole face change. “You’ve just given me half my life back.”

Instead of working up until a due date, he began to work to a Definition of Done, which gave him the ability to stop working when it was done and move on to something else. 

Objetivo del producto

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users, or customers. A product could be a service, a physical product, or something more abstract.

One of the things I repeat over and over to my clients, well, just about anyone who will listen actually, is “Don’t do Scrum to do Scrum. Do Scrum to get somewhere.” 

The Product Goal is in a way the sum of all the Team’s Sprint Goals. It is the state that the Product Backlog describes. It is where the Scrum Team is trying to get to.

Any product or service or process or release or whatever needs to have a goal. A goal that is likely many Sprints into the future. When I sit down to write a book I have a goal, a finished book that says what I want to say in the way I want to say it and into the hands of a reader. That takes time. It usually takes me a year to eighteen months. Now that goal is a big one, and I have to keep it in mind. But I also have to ask the question ‘What am I going to do next Sprint to get closer to that goal?’ And then even more importantly, ‘how do I measure if what I am doing is getting me closer to my Product Goal,’ a finished book? 

In speaking with Jeff and Ken about why they added the Product Goal as a commitment in the Scrum guide they said it was addressing a dysfunction that they commonly see in Scrum Teams. The Teams go from Sprint to Sprint, maybe even have Sprint Goals, but they lose track of where they want to get to. What is the sum of all of those Sprints? Are we getting closer to our Product Goal or are we just constantly firefighting on the most urgent thing and losing track of the most important thing: value in the hands of the customer. 

Jeff and Ken want Scrum Teams, particularly Product Owners, to keep the Product Goal always visible and always in front of mind. It is far too easy to get distracted by the next shiny object or the most recent crisis, or even worse, someone else’s crisis and lose sight of what the end goal actually is and to make sure that everything the Team is doing is getting closer to that mark. 

The Nature of Commitment

Successful use of Scrum depends on people becoming more proficient in living five values:

Commitment, Focus, Openness, Respect, and Courage

The Scrum Team commits to achieving its goals and supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals. The Scrum Team and its stakeholders are open about the work and the challenges. Scrum Team members expect each other to be capable, independent people, and are respected as such by the people with whom they work. The Scrum Team members have the courage to do the right thing, to work on tough problems.

Commitment, to me, is the heart of Scrum. It is the value that is supported by all the other values. It is the commitment of the Scrum Team to deliver value, to reach goals, to solve problems, and to support each other in doing so. It is a commitment not to Scrum, per se, but to using Scrum to reach the goals they have set for themselves.

The 2020 Scrum Guide hasn’t changed Scrum, it is a better description of it. Scrum hasn’t changed, it’s only that the co-creators have learned more about how to express it. The 2020 Guide with its new three commitments tied to the three artifacts isn’t new. They were always there. They were always implied. But Jeff and Ken felt they needed to be more explicit, that without that Scrum Teams weren’t delivering the value they should be capable of delivering. 

A Scrum Team commits to deliver something of value. A Product Goal. Each and every Sprint Goal is their commitment to getting closer to that. And every increment, every time something hits that Definition of Done is their commitment to delivering quality and value in every Product Backlog Item they create.