Comprendre la définition de "prêt", les critères d'acceptation et la définition de "fait".

par Tom Bullock, Kevin Ball, Jack Harmening | 26 juin 2020 | Blog

This post is part of our new ScrumCast series of conversations with thought leaders who have successfully helped transform organizations and​ empower teams and individuals. Each episode will explore organizational Agility and Scrum patterns, tactics, and techniques that drive real-world success. Subscribe to our YouTube channel for the latest ScrumCast episodes. 

Definition of Ready, Definition of Done, and Acceptance Criteria. These are three very important but often overlooked elements of any Élément du carnet de commandes du produit (PBI).

High performing teams and organizations know how to use each effectively. And how they interplay to boost coordination, productivity, and minimize the effects of dependencies. 

In this episode of ScrumCast, Scrum Inc. consultants and trainers Kevin Ball and Jack Harmening join host Tom Bullock to discuss how to use each of these elements to set your team up for success. 

Here are some of the highlights of their conversation.

Start With A Clear Definition Of Ready 

An effective Backlog is more than just a prioritized to-do list. Each Product Backlog Item must contain all the information needed for the Scrum Team to know they can complete the work in a single Sprint. That is where the Définition de Prêt comes into play.

JACK HARMENING: “The Definition of Ready gives a sense of perspective. When we create Product Backlog Items, we have to choose how we’re going to write them. The Definition of Ready is the specific portion of that language that helps us understand if we actually can do this work. So it's one thing to write a story and have this kind of idea in your head about what you want to be done. It's another thing to start to shape that to the point where a team can take that in and say, yeah, this is something we can do in a Sprint.”

Both Jack and Kevin are advocates of using the I.N.V.E.S.T. criteria when writing PBI’s. 

I - IMMEDIATELY ACTIONABLE, a team can begin work on the item right away.

N - NEGOTIABLE, the team can discuss details about the PBI and how it is to be accomplished.

V - VALUE, the PBI produces value to customers/stakeholders.

E - ESTIMABLE, the team can estimate how much effort it will take to complete.

S - SMALL, the work can be accomplished in a single Sprint. 

T - TESTABLE, the increment can be tested 

JACK HARMENING: “Ultimately comes down to is this a bite that we can even take, right? We don't want to take on too much. We want to be able to process this information and get this work done.” 

“A common pitfall I’ve seen is when cross-team collaboration is necessary to get a project done. A lot of times people will have Definitions of Ready but they won’t talk to each other about how to align them. So if a team needs to talk to another team to get something done, then they need to know about their Definitions of Ready. You need to communicate those ideas with each other so that when the work comes in, it's ready to go.” 

Know Your Acceptance Criteria

Acceptance Criteria details just what needs to be done for the PBI to be considered complete. This helps teams estimate, test, and accomplish the work. The concepts of Acceptance Criteria and Definition of Done sound very similar. But they are quite distinct. 

KEVIN BALL: “The Acceptance Criteria is what the customer needs. The Definition of Done is what the organization needs. So if you have your Acceptance Criteria built into the story (PBI), we know exactly what kind of hoops to jump through. We know exactly what gates need to be closed and completed it before it can be moved to done. 

I set up a healthcare organization team, about 12 teams actually, and in the first few Sprints, the teams weren’t writing Accepted Criteria. They started asking why weren’t [they] able to complete this work? The answer was ‘Well, I didn’t know what really needed to be done.’ The Acceptance Criteria was failing. It wasn't complete.”

Common Acceptance Criteria Pitfalls

Acceptance Criteria should be clear about what needs to be done for the work to be considered complete. But they shouldn’t spell out how. Or be so prescriptive that they eliminate creativity. 

KEVIN BALL: “The Acceptance Criteria for a PBI needs to have just enough information that the team understands what needs to be done, right? We're not robots. We know how to do the work. Bring just enough information so the team understands what is needed for an MVP, Minimum Viable Product, at the end of a Sprint.”

JACK HARMENING: “The analogy that I like to lean on is the bumpers when you go bowling on a bowling lane. You're trying to avoid your team getting nothing done and landing in the gutter, but you still want to have the freedom to allow them to pick the right route to get as many pins in this case as they can.

Depending on the type of store you're dealing with, depending on the type of work you're doing, there are different types of Acceptance Criteria and ways to write those out. Ultimately it's in service of the team to be able to avoid the worst-case scenarios, but still, have the freedom to choose between many best-case scenarios.” 

Définition de "Fait

Les Définition de "Fait describes what is needed for groups of similar PBI’s to be considered complete. 

KEVIN BALL: “Here, I like to use the USDA as an analogy. The USDA has to inspect all types of food before it goes to the grocery store, right? There are thousands of different types of food. There's a whole bunch of different Product Backlog Items in your backlog as well, but they all go through the same criteria.

The food has to be fresh, has to be picked at this date, has to be packaged in a certain way, has to have the expiration date, and list the ingredients in it. 

The same thing with your Product Backlog Items or your body of Product Backlog Items and your Definition of Done. It needs to be checked and have quality control. A person may need to look at it before it goes out. Does it fit that definition of done for that body of work, those group of product backlog?” 

JACK HARMENING: “And it gets to the perspective, right? So the Acceptance Criteria, that perspective that we're taking when we write them is usually still about the customer, the end-user, or the next person that we're handing something off to.

And the definition of done takes a company's perspective. And that tends to, as Kevin outlined, that tends to be in a risk mitigation form or quality control.”

Common Definition of Done Mistakes

KEVIN BALL: “The most common mistake I see with Definition of Done is that the organization has not thought deeply enough about it. That's the very first mistake. 

The second thing when it comes to the realization that they need a Definition of Done, they take too much time and waste too much time coming up with a Definition of Done versus having one of the teams make a Definition of Done for their body of work and then start to scale that to other parts of the organization. So, in other words, come up with a reference model for your Definition of Done, for your process, and how you create it. Then test that and inspect and adapt it so it scales to other parts of the organization.”

JACK HARMENING: “To me, the worst is Definitions of Done are those that exist just to check a box rather than as a tool of communication between teams. Good Definition of Done helps us understand our work better or help teams understand how we can make sure that work is flowing.

We've all lived in worlds where you pass your work off to another team and they're like, this is completely unusable. Right? If we're using our Definitions of Done as window dressing rather than as a conversation starter where we're getting people involved, then it's not going to be useful enough to be worth the time.”

To view the full conversation on Definition of Ready, Acceptance Criteria, and Definition of Done with Kevin Ball, Jack Harmening and Tom Bullock, click here.