Why is our definition of done so long?
I don’t like to call the definition of done the checklist for how we do things around here. I used to say that because you might be including every single little thing in your process when you do that, but does it have the essential elements of how do we know that this work is done?
So why is our definition of done so long? In some cases, actually, it’s not long at all. My most common experience is that when I ask people what’s in their definition of done they say we met the acceptance criteria. There’s a lot more to done than just meeting the acceptance criteria. This typically happens when there’s a kind of a traditional approach to delivery and scrum has been wrapped inside that approach. I often call it water scrum fall and in waterfall, it’s very professional, it’s very good but it doesn’t have a thing called a definition of done. So this concept is alien to waterfall.
When people think of done, they think, oh, we just met the acceptance criteria. We just did what our customer is looking for. But we might be lacking transparency if we don’t have additional criteria there. What I often see as well is almost the opposite of that, where there’s too much in the definition of done and I did this in the past myself as well in a large bank where I with others created an organizational definition of done, which was then inherited by the teams as a minimum that they would not have to rethink how to comply with financial regulations and so on. We thought that was a good idea but what that resulted in was essentially we had a very detailed definition of done and it was so detailed that really people didn’t remember what was on it. It probably was put on a confluence page or metaphorically stuck in a drawer where people forgot about it.
I often did mini audits if you like across groups of say 400 people, just checking in, do you even know the depth of what the definition of done, do you respect it? Do you continually improve it? And I was told people improve it, but actually they didn’t even know what it was.
So how can you improve your definition of done if you don’t even know what the one is that you have, and if you don’t even respect it.
So there’s no basis for continuous improvement in scrum at least if you’re not using your definition of done, but while we might want to be careful about making sure that people haven’t forgotten anything, it does say something about us when we do have a very detailed definition of done. Imagine a list that had 30 items on it. What does that say about what’s going on in that environment? And I would put it to you that what it says is that there’s a lack of trust. It typically happens when maybe there are some suppliers involved.
It might be nothing to do with the suppliers. And I’m not saying it’s their fault, but there’s this kind of organizational lack of trust in other people, it could be other teams and it could be at other sites. But essentially it comes down to lack of trust and it always begs the question where does the definition of done end and where does waterfall begin? We often hear people complaining about a definition of ready as a gate, you can’t bring it in cause it’s not ready, which is not a very scrummy approach. You still have a last chance to sort things out during sprint planning.
But the definition of done, when it’s a really long detailed list, it’s likely that people won’t be complying with it. You’ve lost the plot then, people will not understand why should they do all these things? It’s just too much. So what ends up happening is because there’s too much, nothing happens.
So this begs the question: What would happen if we had higher trust in the system? And what impact would that have on the definition of done? So what I often do is a liberating structure called critical uncertainties, and you could pick any two dimensions of a problem. Say on the horizontal axis, I would have the level of trust. So on the left-hand side, I might have low trust and on the right-hand side I might have high trust and the vertical line would be to do with the definition of done the minimum would be you had one, a clear, but basic definition of done, not no definition of scrum, in scrum you have a definition of done, that’s it.
A basic but clear definition of done at the bottom and at the top a very detailed, definition of done. And so you draw the vertical line, you draw the horizontal line, you end up with four quadrants. You end up with a situation where we have low trust and a very detailed definition of done.
We’ve got low trust and a very basic definition of done. We’ve got high trust, very basic definition of done but clear and high trust, a very detailed definition of done, but clear, and what you can do with critical uncertainties, you can ask people, how would you think people would be behaving in those quadrants?
So for example, if you had low trust and a basic, but clear definition of done, actually things could fall between the cracks because there’s no trust. Maybe they won’t, maybe everything will be fine. Maybe we will actually earn trust, but what could happen? Things could fall between the cracks.
It becomes apparent to people and reinforces that sometimes we have a detailed definition of done because we don’t have enough trust.
And then you go to the high trust side and say, what would happen? What kind of behaviors would you see if you had high trust and a clear, but basic definition of done? And they say nice things, it’d be lovely.
What would happen if you had a very detailed definition of done with high trust?
It might actually erode trust. And so for me, it all comes back to trust then. So if you have high trust, you don’t need to have a very detailed definition of done I would put to you. How do you increase trust?
Let’s come back to the scrum values for a start. In scrum, we’ve got the five scrum values. I use the mnemonic FOCCR. It’s funny. Meet the Fockers then change the K to a C. Focus, openness, courage, commitment, and respect. Have the scrum team and its stakeholders really committed to those scrum values and if they’re really striving to improve on those, trust should increase. Trust is also at the base of the triangle of the five dysfunctions of a team. If you don’t have trust there are lots of things that don’t happen.
So how do you increase trust? I guess is the question and I don’t have all the answers, but I think one of the things is, might be no harm now and again, to do a sprint review. How are we doing against the scrum values? How are we doing against the three pillars of scrum as well? Transparency, inspection, and adaptation. How transparent are we? Are people clear on what’s actually really happening? By looking at the three artifacts, the product backlog, the sprint backlog and the increment, but also I would refer back to Richard Hackman’s work as well, because he was an expert on teams.
He studied teams in the US federal agencies, and it’s not all about us singing songs all around the campfire and everybody’s happy. It’s a two-way street really. To increase trust, we also need to deliver, we need to deliver ideally what we said, we’d deliver in the spring goal.
That’s what we commit to in scrum we commit to delivering the work from the spring goal. And so I think it’s a two-way street. I think we need to be looking at how we’re behaving with each other. We need to be striving to improve how we’re doing on the scrum values and we need to be delivering. And it’s not true in my opinion, that we need to wait for the team to be happy and we need to build up trust before the team can deliver. You might not have a team for very long if that’s your approach because the team might never deliver. And we do need to face some reality.
Sometimes when we’re being open, we need to have the courage to say the things that need to be sorted.
So how do we use definition of done more efficiently at sprint planning?
So really the definition of done should already be there before you go into sprint planning. A lot of people kind of get confused that the best place to review the definition of done is actually at the sprint retrospective. But people say, hang on the retrospective is at the end of the sprint, what do we do before we start the first sprint?
It doesn’t say this in the scrum guide. My personal opinion is when I start up with a team, we elaborate. What’s the vision for the product. If there’s a vision, what’s the product goal. Let me try it. I might use a story map to break down the product goal into sub goals, into high-level items, into more detailed items.
And you end up with the product backlog on the wall. I would also encourage the team to create their definition of done before they start their first sprint planning and I will write another blog on sizing, so I won’t get too much into sizing, but when you’re looking into can we do this item in the sprint?
Do we think we’re comfortable about bringing this item in? You can use the definition of done as your reference point if you’d like to say actually to get this done, we have to do all these things. Do we really think that we can comfortably get that done within the sprint? How comfortable do we feel about that?
The mistake that a lot of teams make is they don’t refer to their definition of done at all. So then surprise, surprise, at the end of the sprint, they don’t have a lot of work done because actually they didn’t even know what done actually meant. I would use the definition of done as a reference point for planning and really, if you want to improve how the team uses the definition of done, I would say, even though you can have an organizational definition of done, and even though the intent behind that is to ensure that we don’t forget things. Be careful. I’m thinking with one of my clients at the moment of moving away from that kind of a model and moving more to a situation where the teams, the people in the teams are deciding what done means.
If multiple teams are working on the same product, they need to work with each other to figure that out, but let them figure it out. And then let’s together try to figure out a way, how can we increase trust so that we don’t need to have such a detailed definition of done so that we do comply with our definition of done and that then gives us a basis for continuous improvement. The light bulb moment here is that when we ask teams to improve their definition of done, a lot of people think, oh, I have to add more items to my definition of done, I have to do even more things. I’ll leave this question with you.
Maybe if you improve trust maybe there’ll be fewer items in your definition of done. That’s my nugget for today. Thank you.