The MoSCoW method for SCRUM

Find this Podcast “The MoSCoW method for SCRUM” on the ThreeWill Soundcloud, Stitcher, and iTunes.

Podcast Transcript: The MoSCoW method for SCRUM

Danny:Hello and welcome to the ThreeWill podcast. This is your host Danny Ryan and today I have here with me Bob Morris. Bob, how are you doing?


Bob:Doing great, Danny, how are you?


Danny:I’m doing wonderful and you are, your title is Principal Scrum Master.


Bob:Yes. Yeah, it has a nice ring to it, huh?


Danny:Doesn’t it? When I’ve tried to say that I want to bow to you or I want to do some sort of … It sounds like a very official title, I like it. What we’re going to talk about today is some real world project management topics. I think it’s always nice to talk about reality, what is some of the things that you read in books and then you have the real world and how do we apply some of that to the real world? We’ve had plenty of discussions on this podcast about process and most folks know that we typically use Scrum on projects, which is one of the Agile processes that are out there. We actually had a conversation this morning with Rob and we were talking about how we combine some of these different processes depending upon what we’re trying to do.


What I wanted to talk with you was about Scrum, about how do we deal with the fact that things change? How do we continue to be flexible? What is it that we need to do in order to maintain flexibility in the projects that we have?


Bob:I think we’ll talk about one specific aspect of how we typically execute our projects and as you mentioned, we use an Agile Scrum project approach. I guess this whole discussion is predicated on the point that change is part of human nature. One of the things that we commonly deal with on projects is customers’ expectations get set pretty firmly upfront with our projects on features and functionality and cost and schedules, but the problem is, is that the detailed business objectives and requirements that go along with those expectations tend to change as the customer learns more about what it is we’re doing and they start seeing things actually getting a little flesh and bone on. This is all about how we deal with that.


I guess the central conundrum you have is something that relates to an old project management concept people from there with the triple constraints, sometimes people call it an iron triangle. Basically, it’s just saying that you’ve got scope, time and cost and that applies to any project. Doesn’t matter if you’re using Agile Scrum or any other approach. Typically a change in one of those areas and the most typical change is maybe an increase in scope, it’s going to impact those other areas. It can impact both of those other areas. Increase in time and increase in cost. In the real world and expectations that customers have, that’s just not a realistic way to deal with those kinds of specific changes that occur along the way. In other words, every time we have a change, we don’t immediately say that these other things, time and cost, you’re going to have to change.


Danny:Yep. Somebody the other day threw an iron triangle at my head and it hurt so much.


Bob:Yeah, they’re heavy. It’s heavy, yeah, it’s dangerous.


Danny:It is heavy. It seems like we’re going to … It is one of those tenants that you have to deal with that, but change is inevitable. It’s one of those things that just it happens and how do we deal with that in the real world? I know there’s a recent project that we want to dive into and let’s talk about how this played out with dealing with some of those real world constraints?


Bob:As you mentioned at the top, one of the most common approaches we use for our projects is Scrum, which is an Agile project approach. A lot of times, there’s a term that gets used a lot in Agile Scrum circles called the art of the possible. It’s something that we use to describe how this approach helps us cope with those changes. Essentially, what this phrase means is just all about avoiding perfectionism. Sometimes you hear people use the phrase, “Perfect is the enemy of good.”


We had a recent project and we’re talking about a project that had thousands of hours of human effort involved in it. It started out being something that was … It seemed relatively straightforward, a lot of it had to do with porting code from one platform to the other. Even in projects like that, that upfront look like they’re going to be pretty clean and no changes, inevitably you start getting these changes. People come up with ideas, they see new capabilities and a new platform they weren’t previously aware of. The team comes up with ideas as well. It’s not just the product owner, and so it’s inevitable that you’re going to have these changes.


Danny:Yep. I think one of the key aspects you’re hitting on is, is a project can fail if you’re inflexible.




Danny:It’s one of those things if you started out, you can be technically correct and, “Hey, you agreed upon this,” and when we’re working on projects, we do change controls, but we typically try to work with the original budget that was put in place and try to add flexibility as a part of the project, instead of trying to say, “Hey, you agreed to this in the beginning, we’re sticking with this and blinders on, we’re moving ahead.”


Bob:Yeah. That’s sort of the philosophy, but trying to make that actually happen, that’s where the art comes in, the art of the possible. Basically, the main mechanism we use for that, something that, I think, everybody is familiar with that has been involved in Scrum projects in the past is the product backlog. That’s the list, essentially, of the requirements that we need to fulfill in order to say, “We’re done with this project.” We use that product backlog in a very particular way. We call it ordering the priorities. It’s something we do on a continuous basis with our customers as we go through the project and it is what allows us to fight the good fight in terms of not letting perfect overwhelm the good enough in a project.


Whenever change occurs, we always respond with this technique of ordering the priorities. It’s basically, a couple of steps. The first step, I think, most people, again, that are familiar with Scrum are already aware of and that is assigning a priority level to everything in our backlog. There is a pretty standard way of doing this. We’ve subscribed to that as well, it’s called the MoSCoW method, which is just an acronym for must have, should have, could have. We even have a level called won’t have. We will include things in that backlog we won’t have just so we have clarity with our product owner or a customer on things that maybe were considered, but are not going to be in scope from the project. The way normally the projects work is everything that’s in that must have category, we know we must have them in order to say that we’re done with the project. Things that are in the should have and could have, those are the things that we might deliver if we have availability, a budget and a schedule permits. We’re typically trying to be optimistic on those things.


The problem with stopping there is it just doesn’t give enough information to the team on what they need to do day to day and the project to be efficient. There’s a second step to this, which is we actually go in and, again, this is on a continuous basis with our product owner or a customer and we order those backlog items with each of those priorities and we review those and basically, the order tells the team what to do first. This ordering is something that can be based on business or technical constraints. For example, we may say, “We need to build out some development environments before we can actually start creating the first bill.” Those 2 steps, that’s really the key that we’re using here to try and bring this concept of order the possible to the project.


Danny:A quick question. You’re doing this … We’re first working with a customer and we put together the initial backlog and then we have them, at that point in time, they’re the ones who decide which of those must have, should have, could have, won’t have, so they’re the ones who are setting that up. What stops a customer from saying, “I want all must have.” This may be just if everything’s a must have, then we’re going to set the budget pretty high, because we need to get all of that done, then we’re just factoring that into the overall time and cost of the project.


Bob:Right. I think the key to that is we align on expectations at the beginning of the project. We have a high level backlog at the beginning of a project. It could be that everything in there is a must have. I’ve seen some projects like that. It could be that there are things recognized upfront that from a business perspective, would be nice to have, but they don’t absolutely have to have them. They might not be in the must have category. The key thing is as we go through the project, we’re working off that initial alignment of expectations and we’re very protective about making sure that both, we and the customers are in agreement and alignment on what gets into that must have category for things that end up getting added to the project.


In some cases, we’ll go into a project and, again, you learn as you go. A lot of times we’ll end up there’ll be new items that may come into the backlog that a product owner makes a decision that actually that’s got more value to the business than some of the original things. This approach that we’re using here accommodates flexibility as far as that goes. As long as we’ve got something in must have and the existing backlog that we haven’t started on and there’s no dependency on other things, they could actually pull that out and substitute something of equal amount of effort and we’ll just absorb that change as part of the project.


Danny:Is this where you start talking about story points where you say you may be able to change one that’s of similar story points to another …


Bob:Exactly, yep.


Danny:Then I think it’s interesting that on the second step of this as well, it sounds like you’re looking at both business and technical constraints. I think some of the technical, what I would think there would be, you would look at the story points. What’s the estimate on this? Sometimes when you’re filling up that shopping basket, you might not reach for something that you know is really expensive when you could get 2 of something else. You are really factoring in both business and technical constraints to what’s the order of what I’m doing?


Bob:Yeah, it essentially boils down to taking what could be very big decisions in terms of cost and time and features and breaking it into a set of very small decisions. Then a lot of times, it’s much easier to make a bunch of small decisions than one huge decision. Certainly less risk.


Danny:You’ve mentioned an analogy with a house in a tropical rain forest. Tell me how does this play out to that?


Bob:Sometimes to try and give people and understanding of why we’ve got these priority levels and then we need to order those, this is something that’s pretty well-known, I guess in Agile project circles. It’s a house in a tropical rain forest. I think it’s predicated on the idea that there are many things you could think of that would be must have for that kind of a project, the construction, walls, roof, floors, all those things. There could even be things that are should haves, meaning maybe the decision between silver and gold-plated plumbing hardware or 10 year and 15 year shingles. Those things represent what we call the backlog. They’re really great guides in terms of figuring out what do you really need to get finished? To give the most value to a customer at a predictable cost and duration of the project.


Again, you could really make a mistake, for example, if you go in and the first thing you start doing is putting in floors. It’s in a tropical rain forest, so you’re going to get rain and it’s going to destroy the floor. You need that extra layer of information to order these must have items, so that you know well, you’ve got to put up 4 posts first and then put the roof on top of that and then you can start building the floor and the walls while you’re dried in. That’s the idea of ordering within the priorities.


Sometimes people wonder why you’re ordering things that are maybe in the should have category? As we’re going through the project, if we have something in a should have category and we have confidence that we’re going to get everything that’s in the must have category finished, we want to know, “Well, if we have extra time, what’s the very next thing we should work on?” We don’t want to have to go back and have a lot of meetings and discussions, so you order that should have list and the team knows they can just take the first thing off the list.


Danny:Another thing I like about this is that typically project … We’re talking like a project has a start date in day. Typically, what happens for us is we’re working on maybe the first phase of something and it might have multiple phases to it. What I think of is these must haves or what we have to have maybe for this first phase of the project. What I like about this is you all must roll very easily into the second phase and some of the should haves might become must haves for that phase, but at least you’re maintaining a list of …


This is a living, breathing creature that you’re creating and with it, there’s your first phase, you’re really just worrying about the walls and the roof and the floors, but then the second phase you’re worried about other things that pop up to the priority, but at least you’ve got them captured in the backlog and you go through it. I guess, that’s part of the planning for phase 2 as you go to the backlog again and then say, “What things might be must have that are in second phase?”


Bob:Yeah, in fact, it’s a good point, Danny. You talk about growth of the backlog in the should have, could have area. When we see that in a project, that’s certainly not a sign of poor health of a project. That’s actually a healthy project and it provides ways to our customers. Maybe they’re not going to do that now, but they’ve got a head start on planning and understanding what really should come next? What’s the next thing that could provide value? Even if it’s not something they’re going to budget for to do right now.


Danny:Excellent, excellent. It’s with having the requirements and ordering the requirements and knowing what’s going to happen next, it seems like there’s a better flow to the project, as well.


Bob:Yeah. Earlier when I was taking about splitting big decisions up into a bunch of smaller decisions, is sometimes a product owner will have some other stakeholder even come in with a new idea, something that really would improve something that we’re trying to deliver. When they look at that at a detailed level and they think about, “What will that mean in terms of trade-offs of other things?” If I want to stick within my current budget, maybe I can’t do that unless I’m willing to pull something else out. It really requires them to make those kind of value decisions at a very detailed level and they’re able to do that, other than just saying, “Everything that I previously identified, just do it, here’s a new thing, tell me how much it’s going to cost and we’ve got to go through the change management process.” It’s a lot more efficient way of trying to make those judgements.


Danny:For wrapping this up, let’s talk about a recent project that you had, it seemed like you had a relatively straightforward set of requirements. Tell me more about that particular project.


Bob:It certainly wasn’t one of our smaller project, we’re talking about thousands of hours of work.


Danny:I like this, I like this a lot. I wish this was our typical type of project.


Bob:This was, I think, I mentioned earlier, it was, initially we thought to be something that was going to be pretty straightforward, involves porting some code from an earlier version of an application over to a new platform.




Bob:The first priority is don’t disrupt the user experience. This should be completely transparent to users. It’s inevitable when you’re doing that work, you start noticing some of those little inefficiencies maybe in the application that you’d like to clean up, since you’re already in there working with the code or maybe you see a way to do something differently that could really leverage some new functionality of the new platform. That’s how those changes crept in there. There’s wasn’t a lot of wiggle room in terms of trying to add new things and there wasn’t a lot of wiggle room to remove things, because ultimately, we had to port over all the existing functionality to this new platform. We had, I guess you could say, scarce resources in terms of the ability to add things or enhance things in our project.


This worked really well, because it allowed us to be very, very smart with the scarce resources in terms of being able to add a few things that didn’t require a lot of work, but really had a lot of bang for the buck and we were able to do that. We ended up delivering this project, again, it was thousands of hours very, very close in terms of the original cost estimate, but it actually had some features and functions that were enhanced above what was in the original plan, so a pretty good outcome for everybody. Our product owner was able to point to sticking to our budget and, at the same time, his users were happy because they saw some changes and improvements.


Danny:I love a good, happy ending. Yeey. It seems to me that your role on some of these projects is really just to report reality. You’re almost that you’re trying to help the client make good decisions as you’re going along on this project. You’re guiding them and helping them to make sure that they’re doing the right things, with setting priorities, with making sure what we’re working on next is the next highest value thing for us to work on.


Bob:First of all, the Scrum Master name sounds strange to a lot of people that aren’t involved in this kind of work. The most common way that I tell people what it is, is it’s a coach role, it’s a coaching role. Our philosophy here is that coaching world is not just for the ThreeWill team, but it’s for our customers as well. We don’t take that responsibility lightly and that’s one of the things we do, is to help coach our customers through this process of making these smaller decisions that lead to really good, large outcomes.


Danny:Awesome, awesome. I think it’s a great way of ending this principal coach or I’ll just call you coach head coach.


Bob:Yeah, let’s head to the showers.


Danny:Okay. With that, let’s wrap it up. Bob, thank you so much for taking the time to do this, I really appreciate it.


Bob:My pleasure.


Danny:Thank you everybody for listening today and have a wonderful day. Take care, bye bye.


Danny RyanThe MoSCoW method for SCRUM

1 comment

Join the conversation

Join the conversation

This site uses Akismet to reduce spam. Learn how your comment data is processed.