Reviewing the New Edition of the Scrum Guide

Episode 26

August 24, 2011




The Agile Weekly Crew discuss changes to the Scrum Guide.

Episode Notes

Jade Meskill, Clayton Lengel-Zigich, Roy van de Water, Derek Neighbors and Drew LeSueur talk about new changes to the SCRUM Guide.

“The Development Team”

Commitment vs Forecast

Burn down charts

Release planning not necessary

Sprint backlog items bye bye

Ordered vs prioritized


Jade Meskill:  Hello and welcome to another episode of ScrumCast. I’m Jade Meskill.

Clayton Lengel‑Zigich:  I’m Clayton Lengel‑Zigich.

Roy van de Water:  I’m Roy van de Water.

Derek Neighbors:  I’m Derek Neighbors.

Drew LeSueur:  I’m Drew LeSueur.

Jade:  Today we want to talk about the new addition of the Scrum guide that came out from There’s been a lot of controversial changes that have been made. Some tweaking to the language, a few different things and we’re just going to go down the Scrum update bullet point by bullet point. Share some of our feelings and opinions.

To kick it off, let’s talk about the first change that they talked about here. The team of people performing the work of creating an increment, is the development team regardless of the work performed by individual team members, they are known as developers. What do you think about this?

Roy:  I like it. I can tell by the way you are looking at me that you don’t like it Jade.


Jade:  I’m just moderating here. [laughs]

Roy:  I like the essential idea of it because I’ve seen with multiple scrum teams that when they go in they run across the concept…we even came across with this at Integrum last week where we said, “What if only one guy is able to perform this specific task”?

We have all these people who are able to work but there’s one thing like, “That’s Jade’s job. Jade’s the only one who can handle that.” I think that’s a big problem. I think that is what they’re trying to address here, is that everybody should be cross‑functional, everybody should be able to perform any of the work inside of this sprint.

Clayton:  I think some of the hangup comes from as a developer, like software engineer, you think of the word developer meaning someone who writes software. I think if you take a step outside of that you could say the word developer really means someone who’s developing something that gets to potential shipable software. I guess I’m OK with this one. I don’t think there’s too much wrong with it.

Derek:  I think that one of the problems you have is on a lot of teams you might have Q&A, and database administrator, an architect. Everybody identifies themselves differently, and so in other language if it’s said the programmers there would be people who say, “I’m not included in the team because I’m a Q&A person, I’m not a programmer.”

By switching it to developer I think they’re using a little bit softer language. I think you could even argue that it allows for scrum outside of software. So from a project management framework perspective, a developer could be anybody creating something. If I’m developing something, whether it be a courseware, or a piece of art, or whatever, I’m a developer. I think that they are softening the language for the some ability to go outside of the network.

Drew:  Yeah, I agree as well, I think the core idea of this change is to unite the team, and let’s give them the same name.

Jade:  All right, let’s move on. The next bullet point ‑‑ Development teams do not commit to completing the work planned during the sprint planning meeting. The development team creates a forecast of work it believes will done, but that forecast will change as more becomes known throughout the sprint.

Roy:  That sounds like the exact opposite of a locked‑in sprint. The idea’s always been ‑‑ we lock in the time, the development team gets to establish the scope. If, now we get half‑way through the week and I don’t think I’m going to be able to make it. In traditional Scrum, that would be a huge deal and you would have to have an early sprint termination, and you’d have to replan or restart your sprint, and that should be a painful process because that should happen very rarely.

Derek:  To me, this is the pussification of Scrum.

Jade:  That’s the exact word I used before we started.

Derek:  Straight up ‑‑ it went from, this is a contract whereby you commit to the work ‑‑ you get to decide how much work you commit to, you commit to it, and the other side of the contract is that you do not have to accept change that comes in as part of that contract.

In fact, at one time, my understanding is that the right way to abnormally terminate a sprint because of change, was to physically throw yourself on the floor and scream bloody murder like a young toddler until you got your way that the change went away or that management was sufficiently known that bad things were happening between the contract ‑‑ between the team, the development team and the product owner.

And now we’re using language that says, “Well, you know, the team just kind of says that they would like to get this stuff done, but if the world changes, and stuff happens and we’re not really making a commitment.”

Roy:  I think, too, the guy that coined that way of doing an abnormal sprint termination is Kent Schwaber, one of the guys who signed the…

Derek:  That’s correct. I think what they are trying to do is remove absolutism or pragmatism, and I think by softening the language they’re going to do the exact opposite of that. So they went from something where it’s very hard ‑‑ you terminate the sprint in this way, and you’re a total asshole about it ‑‑ even if it’s the right thing to do.

To now, “We don’t want to ever say you ever really make a commitment because that’s sometimes not the right thing to do,” and I think that really it’s a middle ground where you should be making a commitment.

The commitment should be something that you really honor. But, if there is valid reason to change, to terminate, or to do that, or there is some ability to negotiate, I think you should be able to do that. I think, by going to the wishy‑washy language, they really don’t help anybody. You’re going to have teams who say, “I don’t have to commit to anything. What are you talking about”? If I can only do a 5, even though I told you I could do a 50, that’s Scrum.

Clayton:  Yeah. I think that the second part of this, where it talks about how more we’ll become known during the sprint, I think that’s just another way of saying “negotiation.” I think we do that now already, where, if something comes up, you can negotiate that. Maybe it’s a big deal, maybe it’s not.

I think the change from commitment to forecasting, what’s been interesting for me is, if following all this on Twitter, there’s been a lot of people that have said things like, “I think ‘commitment’ is a great word, because I want the development team to feel the weight of the world on their shoulders, like they feel like, ‘Hey, this is a really big deal.’”

Then, other people are saying, “Gees, the weight of the world, and I want to make the development team feel like they have to do it.” Those are all very negative words. I agree with you that’s a pussification.

Derek:  Scrum pussies.

Clayton:  Right. It’s like, “Let’s be very gentle and let’s be very cautious of not making people feel bad,” that kind of thing. I agree that there’s a lot to said be for the feelings, the emotions, and the words that we use, but, at the same time, I don’t think that the “commitment” stuff is negative, necessarily. I don’t think that has to be a negative thing. I think that can be viewed as a positive thing.

Roy:  I think that too. As far as the negative emotions of saying, “You have to get this done,” “Well, yeah, I committed to it. I said that I would get this done,” and whether you see that as negative or not, it shouldn’t be a negative thing. If I said I can get this done, then there shouldn’t be anything negative about me getting it done. That should be a positive thing.

Derek:  I’m pretty trying to go back to my wife and say that I’m not really happy that we’re married and I made a commitment. I would like to forecast that we will be together for the next six to seven years…


Derek:  …and we can renegotiate another six to seven years…

Jade:  …as more information becomes available.

Derek:  …if we get more information.


Clayton:  I will say that, since I read the actual longer‑winded update about “order” versus “prioritize,” which we’re going to get to in a second, I will say I will withhold judgment on this one until we get the full explanation, but my gut feeling is that it’s what we’ve been talking about.

Roy:  My other thing is one of the things that Derek mentioned when he was talking about the pussification of Scrum, where the idea of the commitment is that I say I’m going to get this done and commit to absolutely getting this done and locking the sprint. That’s my part of the deal.

The other part of the deal is that I won’t get interrupted with any requests. That’s not really a sacrifice, but, if I don’t make that promise that I’m going to get something done, and if I don’t give something from myself, then why should the other people, why should stakeholders or product owners respect the fact that I have a locked‑in sprint? If I can change my mind halfway th