![\"The](\"https:\/\/www.teamly.com\/blog\/wp-content\/uploads\/2021\/12\/The-Moscow-Method-Defined.png\")
<\/p>\nIf a genie granted you one wish, what would you ask for? To retire at 40? A second home in Hawaii?<\/p>\n
What if he granted you three wishes?<\/p>\n
Since this is just fantasy, let’s go ahead and dream really big…..imagine you had ten!<\/p>\n
Chances are, with ten wishes, you’d be tied up in knots, flummoxed, trying to find clarity amongst your \u201cmust haves.\u201d<\/p>\n
Identifying priorities in a really complicated project feels about the same.<\/p>\n
When looking through the product backlog feels like rifling through the kitchen catch-all drawer, how do you distinguish the \u201cmust-dos\u201d from the \u201cmust-do-right-nows\u201d?<\/p>\n
Even when you know the deadline, and a lot of other constraints, it’s hard to know where to actually begin.<\/p>\n
When you’re tangled up in a must-trap, it feels like the only way out is for a genie to appear, sort through everything, and tell you: \u201cHere. This is what you need to work on Right. Now.\u201d<\/p>\n
The truth is, you can get untangled yourself. The MoSCoW Method of prioritization lets you know what you need to work on now, and what tasks can be put off until tomorrow. And it’s really simple to boot!<\/p>\n
That’s not too hard to believe, is it?!<\/p>\n
<\/p>\n
When you hear about the MoSCoW Method for the first time, it probably conjures up images of St. Basil’s Cathedral, the Kremlin, and Red Square.<\/p>\n
The truth is, however, that the MoSCoW Method has nothing to do with Russia at all!<\/p>\n
It was developed in 1994 by Dai Clegg, a software developer working at Oracle. MoSCoW really represents the acronym, MSCW. The vowel sounds are added to make it easier to pronounce (and it makes it sound pretty cool, too!).<\/p>\n
Each letter in MoSCoW represents a separate layer for task prioritization: Must<\/strong>, Should<\/strong>, Could<\/strong>, and Won’t<\/strong>. By organizing tasks into these categories, a team finds clarity around what it needs to work on right now, and in the near future.<\/p>\n Here’s a breakdown of the kind of tasks that go in each category.<\/p>\n It’s all pretty simple, huh? The MoSCoW Method is helpful in the initial stages of project planning, as it’s about clarifying and crystallizing what the project really is all about. It helps to manage expectations for all stakeholders.<\/p>\n Let’s look at an example of using the MoSCoW Method at the beginning of a project. Let’s say you’re planning the remodel of a kitchen.<\/p>\n The musts<\/strong> include the primary reasons for the remodel, such as moving the dishwasher next to the sink, improving the lighting, and increasing the size of the sink.<\/p>\n The shoulds<\/strong> are things that need to be taken into account, secondarily. This may include things like putting outlets in the right places.<\/p>\n Coulds<\/strong> are special things to add, such as custom cabinets or a tile backsplash, so long as they work into the time frame and budget.<\/p>\n Won’ts<\/strong> are things that just won’t happen, given the overall constraints. These might include things like adding a Viking stove, because it’s too expensive, or a marble countertop, as it wouldn\u2019t handle moisture.<\/p>\n MoSCoW makes it easy to chart a course at the beginning of a project. Let’s look at a few reasons the MoSCoW Method assists in successful project implementation.<\/p>\n The MoSCoW Method, as you’ve just witnessed, is pretty easy to explain and understand.<\/p>\n Unlike scrum or many of the principles in agile, anyone can figure out MoSCoW in just a few minutes.<\/p>\n This simplicity allows the business, customer, developers, and any other stakeholders in a project all to participate and make meaningful contributions toward determining the musts, shoulds, coulds, and won’ts of a project.<\/p>\n When all stakeholders are able to participate in discussing projects, and all of the tasks are ordered and prioritized, it makes the entire project transparent.<\/p>\n It’s much easier to get stakeholders on board when they see all the cards laid out, and can offer their own perspective.<\/p>\n And as any project manager will tell you, having every stakeholder understand the goal and constraints of a project from the beginning is critical to its success.<\/p>\n When a project has too many North Stars, or there’s some sort of a \u201clet’s do this\u201d mentality without much of a plan, the team flails and it creates a lot of dissension later on.<\/p>\n The MoSCoW Method creates clarity around what a project sets out to do (and what it won’t do) from the very beginning. This is perhaps its greatest strength.<\/p>\n When all the stakeholders understand a project’s final objective, it really helps to manage expectations down the road, and decreases the likelihood of having to change course late into the project.<\/p>\n As you can see, Clegg was really onto something when he developed the MoSCoW Method. It didn\u2019t catch on just because of the great name.<\/p>\n Nor is it sheer perfection, however.<\/p>\n Although an effective project management tool, The MoSCoW Prioritization Method isn’t fool-proof. Let’s look at a few of its flaws.<\/p>\n But wait! Isn’t simplicity one of MoSCoW’s strengths?<\/p>\n Well, as with so many things in life, one of the strengths of the MoSCoW Method is also one of its biggest weaknesses.<\/p>\n Although MoSCoW is a great way to plot out a project at the beginning, this isn’t a stopping point.<\/p>\n Simply putting tasks into four categories doesn’t provide enough clarity to move forward. When you have six to eight things in the \u201cmust\u201d category, it’s necessary to dig and refine a bit further to determine where to actually begin.<\/p>\n Additionally, if these \u201cmust\u201d tasks are really huge, they need to be broken down and simplified into stories that can be completed in a sprint.<\/p>\n For larger complex projects, it’s also helpful to organize stories into epics, themes, and features in order to find clarity around priorities and determine what to put into a sprint.<\/p>\n A project with a lot of stakeholders generally means a variety of interests and motivations.<\/p>\n An agile team plans each iteration with the end user in mind. However, managers higher up in the chain of command may well work toward different incentives, and create \u201cmusts\u201d that don’t really benefit the project, but that are motivated by politics or pay.<\/p>\n With a variety of conflicting \u201cmusts\u201d<\/a>, the agile approach of working toward the end user gets sidelined, and a team may end up having to complete a \u201cmust\u201d that doesn’t really improve the deliverable at all.<\/p>\n The MoSCoW Method is a bit like waterfall in that it creates a set of priorities at the onset.<\/p>\n The team can easily become cemented into these objectives, even when the client’s needs change, or the market changes in the duration of the project.<\/p>\n As it wouldn\u2019t allow for fluidity and change, depending entirely on MoSCoW Method may lead to a dissatisfied client.<\/p>\n As you can see, although MoSCoW has a lot of strengths, it’s not something that a team should lean on entirely. It’s important to be aware of this method’s shortcomings as well, and to use it judiciously.<\/p>\n Using the MoSCoW Method really helps agile teams prioritize the product backlog for the upcoming iterations. Plus, it keeps the team from wasting time on pointless tasks.<\/p>\n However, when using the MoSCoW Method, it’s necessary to keep the principles of the Agile Manifesto front-of-mind as well.<\/p>\n Here are a few pointers.<\/p>\n Although a scrum team in isolation can easily come up with its own musts, shoulds, coulds, and won’ts, this list would look pretty different than someone else who has a stake in the project.<\/p>\n The Agile Manifesto says to value \u201cindividuals and interaction over processes and tools\u201d and that \u201cour highest priority is to satisfy the customer.\u201d<\/p>\n In creating the product backlog, a team needs to gather input from all stakeholders.<\/p>\n An integrated list of priorities that considers all perspectives makes a project better poised to chart a path that satisfies the end user.<\/p>\n Although it\u2019s helpful to us MoSCoW to identify a project’s \u201cmusts\u201d and \u201cshoulds,\u201d an Agile team also needs to be cognizant of the principle from the Agile Manifesto that states: \u201cwelcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.\u201d<\/p>\n Mental agility refers to a team’s ability to adapt and course correct.<\/p>\n When a team identifies that the client’s needs have changed over the course of a project, it uses this mental agility to scrap some of its plans, and readjust.<\/p>\n Clarifying \u201cmusts\u201d and \u201cshoulds\u201d provides much-needed guidance. But it’s just as necessary to allow for course correction.<\/p>\n The MoSCoW Method can look a bit like a gantt chart: it plots out an entire project at the very beginning.<\/p>\n This big-picture approach goes against the agile process of creating increment during each sprint, reflecting then pivoting.<\/p>\n In order to be agile, teams need to keep the big-picture approach, but to focus on each sprint as well. The increment, feedback and reflection may alter the course.<\/p>\n In sum, the MoSCoW Method is a helpful tool for an agile team. But it shouldn’t be used like a compass. Some of the rigidity implicit in the MoSCoW Method really brushes against the agile methodology and could chart the team off course.<\/p>\n Have you ever seen that hilarious motto people have on t-shirts and mugs that says, \u201cI can only please one person per day. Today isn’t your day. Tomorrow isn’t looking good either.\u201d?<\/p>\n Ha ha, at least it’s honest. Determining our musts, shoulds, coulds, and won’ts is a skill we use in all the areas of our lives.<\/p>\n The MoSCoW Method provides a simple approach to prioritization for projects.<\/p>\n This simplicity allows a team and all the stakeholders to work collaboratively and chart a clear course at the beginning of a project.<\/p>\n But it’s not entirely perfect. When using MoSCoW, an agile team first and foremost needs to bear agile principles in mind.<\/p>\n\n
\nA must<\/em> is any task that’s essential to a project. It’s part and parcel to the overall objective, and not doing it would create a bottleneck.
\nMusts include any feature requirement from a client. These are the things to put into a sprint backlog for the upcoming iteration.<\/li>\n
\nShoulds<\/em> are things that need to be completed, but aren’t on the front burner. These can stay in the product backlog for a later i<\/li>\n
\nCoulds<\/em> are ancillary tasks; things that would be nice to do, given that resources are available. They don’t need to happen in this iteration or the next. Coulds go into the product backlog.<\/li>\n
\nWon’ts<\/em> are any tasks that just can’t happen within the constraints of the project, and aren’t required to meet basic requirements. Won’ts are removed from the product backlog.
\nWon’ts are also sometimes referred to as \u201cwould haves\u201d or \u201cwish to haves,\u201d because they can be things that would improve a deliverable, but are just outside of the scope or budget.<\/li>\n<\/ul>\n![\"An](\"https:\/\/www.teamly.com\/blog\/wp-content\/uploads\/2021\/12\/An-Example-Using-MoSCoW.png\")
<\/p>\n<\/span>An Example Using MoSCoW<\/span><\/h2>\n
![\"Strengths](\"https:\/\/www.teamly.com\/blog\/wp-content\/uploads\/2021\/12\/Strengths-of-the-MoSCoW-Method.png\")
<\/p>\n<\/span>Strengths of the MoSCoW Method<\/span><\/h2>\n
A Simple Conceit<\/h4>\n
Broad Buy-in<\/h4>\n
Crystal Clear Objectives<\/h4>\n
![\"Weaknesses](\"https:\/\/www.teamly.com\/blog\/wp-content\/uploads\/2021\/12\/Weaknesses-of-the-MoSCoW-Method.png\")
<\/p>\n<\/span>Weaknesses of the MoSCoW Method<\/span><\/h2>\n
It’s Too Simple<\/h4>\n
Bogus \u201cMusts\u201d<\/h4>\n
Fixation on Musts<\/h4>\n
![\"MoSCoW](\"https:\/\/www.teamly.com\/blog\/wp-content\/uploads\/2021\/12\/MoSCoW-With-Agile-Teams.png\")
<\/p>\n<\/span>MoSCoW With Agile Teams<\/span><\/h2>\n
Gather Input from All Stakeholders<\/h4>\n
Use Mental Agility<\/h4>\n
Stay in the Weeds<\/h4>\n
\n<\/span>Conclusion<\/span><\/h2>\n