Scrum's Commitments: Muddy or clear? - Fredrik Wendt

In this special video episode, Fredrik Wendt discusses a thing that he finds strange in how the Commitments are set up in the current Scrum Guide (SG2020).

The Commitments are not all of the same kind, which makes understanding the groupings and how we can use them to improve and guide value delivery (and quality) more difficult for Scrum practitioners.

After listening to this episode we hope you walk away with sharper understanding of Scrum's Commitments, their importance AND their differences.

Are you listening to this without visuals? Please also check out the video on our Youtube channel, as Fredrik supports his reasoning with visuals which makes the argument even easier to follow. Find the video here: https://www.youtube.com/watch?v=A6rttY6pSFs

If you like this kind of focused, detailed exploration of Scrum's details, please let us know, because as Scrum-Nerds we can certainly do more (with Fredrik and/or other guests).

Want to learn more from Fredrik, please check out the previous episode we recorded with Fredrik, about influence and value.

Have any other feedback? Questions you'd like answered? Ideas for guests or topics? Please reach out through any of our channels, like http://scrumfacilitators.com or linkedin.

Are you working with Scrum/Agile and have similar stories and tips to share? Or do you know someone that you want to voluntell to be a guest? Reach out! podcast@scrumfacilitators.com

Also check out our website, LinkedIn and Meetup

Transcript

0:05

Hello and welcome to the Scrum Facilitators community podcast. I'm a back again with Fredrik Wendt and this is a special thing because we're doing a really short maybe a bit of scrum nerdery thing, but a short thing that's separate of the longer podcast. So if you, you're listening to this or watching this and think Who's Fredrik? Well, you can just check out the podcast we already released. And that's a nice introduction and some other interesting topics that we won't get into now. So what are we here for? Frederick said to me, Well, I have this interesting thing about the commitments in Scrum. They're in the Scrum Guide since 2020. It's the Product Goal the sprint goal and the definition of done. Those are commitments in terms of the Scrum Guide. So I'm very curious where this goes and we'll see if we can make you think a bit or give you new insights and learn something for ourselves as well. So Fredrik, please tell us why this topic and then take us along. So like you said, there was a change in the 2020 version where they introduced this concept that every artifact has a commitment attached to it. Right? And so when I started thinking about that change and whether I supported that or not, I'm going to draw here for the people that are watching. But to me, those commitments are different in nature, right? So we have, you know, the product backlog. I'm going to use PBL here as we all know that. And it says some of the items on this artifact are supposed to take us closer to the product goal. Right? So that's the commitment for the product backlog. Now we have the Sprint backlog and this one again. And whatever we do here. And how have you used this tool? You're supposed to help us, you know, move closer to the Sprint Goal to help us realize this Sprint Goal and I should say the same thing for for for the product Backlog. It's something that moves us towards, you know, this value that we want to see. You know, every sprint is a is an investment. You know, roughly €50,000. If you haven't calculated this, go ahead and do that. But that's what most and scrum teams cost and per sprint. So scrum guide and scrum has often said, you know, it's not enough just to go in and do random stuff in the sprint. Right. You should know why you are investing these much this much money. Yeah. So what's the outcome? And that is the the why question of sprint planning, right? Why are we investing this €50,000? And so we want to formulate that into the Sprint goal so that we have a clear outcome that we're trying to achieve an impact change, a value change, ideally. And then we have this thing called the increment, the third artifact in scrum. So we have product backlog, sprint backlog and the increment. And so the scrum guide says that the commitment for the increment is called the definition of done previously. This used to tell us when our increment is potentially releasable, you know, when it's ready to go, when it's really we think we're done. There is no more work to be done. This can be released now and be of value to the consumer, whoever that is right now. And so the question is now, is the increment going to help us get to the definition of done? You know, these arrows that I drawn to the left, you know, the product backlog items, are they helping us achieve the sprint, the Product Goal? Well, yeah, I mean, the items on the Sprint backlog. Yeah, but the increment. Well what what something happen here. Yes. Yes. Because the definition of done tells us when we have an increment. Yes. So this is interesting. Yeah. Change for me. Right. Because I'm just going to say one more thing Sjoerd and that that the items on the left here, the product backlog and the sprint backlogs, they are essentially plans right. It's a plan of how to get to a new state, how to get something to happen, how to have a change in value, how to have a change in impact on the market or something like that. And your users, of course. So both of these there are plans, but the definition of done is not a plan. I'm sorry, the increment is not a plan. And the increment artifact that is an actual output, right? That is the thing we have. You know, the thing we produced was the Sprint backlog and the product backlog. Those are plans. You know, these are, you know, very different types of artifacts, you know, aspirations, aspirations, whereas the increment, that's an output, it's a result. Yes. So for me now this makes a bit strange now since the product goal obviously is also an aspiration, we want to get there, but we don't know if it's the right goal. We might change it, same for the Sprint Goal, we strive towards it, but we don't promise that we get that we're promised we're going to try to get there. Right. But when it comes to the definition of done, we don't say, well, this is the best way. We hope we're going to get there. It might be wrong. No, this is something we say. This is the quality we need. We agreed on this. We're not going to budge. I'm not going to say done unless it meets the definition of done right. So this is actually promise. Whereas the Sprint goal on the product goals, they're not a promise in the same way. Yes, Does that make sense to you? It does. And so there there's a clear difference, I think you're correct in that. So and if we talk about definition of done, especially for teams that are are not at that stage that you mentioned like done is releasable there's no remaining work are done can even be released for some teams or even data has been gathered to see if the the the change has the desired impact. You know that's can all be part of the definition of done. But I think the interesting thing here is that for teams that are not there yet, they don't have that like really ambitious I would say definition of done that actually scrum desires. Yeah you know to raise the transparency you have this part and that's what we call in trainings the definition of undone like the stuff that you want to do but is not yet attainable for this team to add to the definition of done. Because if like dependencies, regulations that they cannot release themselves or other stuff, I don't know. There's always this part and I think that part is actually more like a sprint goal or a product goal than the definition of done itself because that is an aspiration, right? That is the remaining part that we want to get into our definition of done. So there's there's an interesting thing I think I would like to highlight. And it's a if you look at it less strict. Yeah, now we have like three artifacts, three things that are supposed to raise transparency. So product backlog raises transparency to our plans for the future. Sprint backlog raised transparency to our current plans and the increment is supposed to raise transparency with regard to current value, you can you can measure something there and the commitments they are you could also see them less strict as guides guides for this plan like we have a plan and the product goal guides us what we should focus this plan on Sprint Goal guides us what we should focus the Sprint backlog on. Like an north star or a compass. Yeah, yeah. Yeah. And the definition of done is actually a guide in terms of quality, in terms of how much we should do or have done to get an increment. So if you look at it that way, it makes more sense. I think however, this lumps in the definition of done and the increment, the aspirational increment with Sprint backlog and Sprint Goal again because yeah, when you talk about aspirational about what do we have to do to get to the next increment, you're talking about sprint backlog plan again. So yeah. Yeah, yeah. Yeah. Because you talked about transparency, right. And transparency is the notion of knowing where we are, right? Yes. If we don't if we don't know where we are, you know what's done, what's not done. We don't have transparency because there's no longer a shared understanding of, you know, what do we think is done, what have we done, etc., or where do we need to go? So unless we have a shared understanding, I would say we don't have transparency. So that's the thing where the definition of done if if we if we start taking shortcuts and not always adhering to the definition of then we lose transparency, right? Whereas if we don't achieve the sprint goal, that doesn't mean transparency is lost. No it's probably gained. Yeah, if we do it right, it's probably gaining transparency like, yeah, okay. You know, I understand that's a difference. I'm really not follow you lose transparency whether the other ones aren't they're not the same kind of BS to what I'm saying. Those are different things and this is. Why I do agree. I do agree. So you know, your argument that argument is very clear. And and I'm trying also to step into the shoes of Ken and Jeff a bit and think, okay, why did did why would they put us in the same boat right in the same string of commitments? And I think it's also something to do with in previous Scrum guides, there was more. We didn't have the Product Goal we didn't have this notion of commitments as a category that's attached to the artifacts. But we did talk about we do commit to the Sprint goal and we do commit to the definition of done. So I think it stems from there and it is on first for unfortunate and but yeah, there is a reason for it of course. And the thing is so with your insight in that there's a difference, do you have suggestions like would you change the guide or how would you present this differently? That's for another session. I think it's a good escape. Yeah. I think that's the best I can come up with right now. For me, this is important to highlight for people. I love the idea that we have a definition of done because this is what brings transparency on where the current state of the product is right. And that's often been a problem in our industry. In the software industry, it's unclear. It works on my machine and works on that machine, but not in that environment from not for those customers, whatever it is, you know, all of those uncertainties, we've tried to wash them away because they impact decision making. It's it's really hard to get good decisions from people if they don't understand where we are. So I for me, this commitment here, the definition of done is crucial in getting the empirical process control to to really work well. Right. Because if we don't have known now state there's no way to compare that to with the wanted state. And so for me this is the key and these I love being able to formulate what's the outcome? Why are we investing this much money, right. The Product Goal that's for another session as well, if you want to. But but I'm not such a big fan of that one because it's kind of dumbing everything down to one thing, and I'm not sure that's the right thing. So let's do another session soon on that and see if or where we get in another 10 minutes, because that's where we are at now. So for the listeners and viewers, this is like an experiment, right? So we're trying to do very brief, but a I'd say detailed investigation of, I think deep dove. A deep dove. And we try to keep it short. So I'm very glad that you said let's go into that for another time because we will probably sometime and I hope we continue this conversation some other day. But for now, I think let's see what our editer makes of this. And if you have any questions, if you saw this or listen to this, have any questions, feel free to reach out to me or Frederick through LinkedIn. You can find us and yeah, just add or ask a comment or whatever on the place you find this video or this podcast and we will try to to see that and and respond to it and maybe do a next video based on comments or questions. We'll see. So thank you for listening. Thank you for presenting and challenging the scrum, guys. That's always fun and we'll see where it goes. Thank you, Fredrik. Thank you and nice talking to you.