Product details

At its core, the MoSCoW method is simply a prioritization framework that can be applied to any kind of situation or project, but it works best when a large number of tasks need to be ruthlessly whittled down into a prioritized and achievable to-do list. The core aim of the process is to classify tasks into four buckets; Must, Should, Could and Won’t. As you can probably fathom, Must is the highest priority bucket, and Won’t is the lowest. You can also presumably now see where the funny capitalization in the term ‘MoSCoW’ derives from. One of the primary benefits of a MoSCoW exercise is that it forces hard decisions to be made regarding which direction a digital product project will take. Indeed, the process is usually the first time a client has been asked to really weigh up which functions are absolutely fundamental to the product (Must), which are merely important (Should) and which are just nice-to-haves (Could). This can make the MoSCoW method challenging, but also incredibly rewarding. It’s not uncommon for there to be hundreds of user stories at this stage of a project, as they cover every aspect of what a user or admin will want to do with the digital product. With so many stories to keep track of it helps to group them into sets. For example, you may want to group all the stories surrounding checkout, or onboarding into one group. When we run a MoSCoW process, we use the following definitions. Must – These stories are vital to the function of the digital product. If any of these stories were removed or not completed, the product would not function. Should – These stories make the product better in important ways, but are not vital to the function of the product. We would like to add these stories to the MVP build, but we’ll only start working on them once all the Must stories are complete. Could – These stories would be nice to have, but do not add lots of extra value for users. These stories are often related to styling or ‘finessing’ a product. Won’t – These stories or functions won’t be considered at this stage as they are either out of scope or do not add value.

The first two slides of the template are similar in design and structure. These slides can be used to provide general information to the team about the client’s needs. The slides will be useful for the product owner, development team, and scrum master. The next slide groups user stories into vertical columns. You can also set a progress status for each user story. The last slide gives you the ability to specify the time spent on each user story. After summing up the time for each group, the team can understand how long it will take them to complete each group. All slides in this template are editable based on your needs. The template will be useful to everyone who uses the Agile method in their work.