Product Creation Quickstart: Learn How to Prioritise Tasks Using the MoSCoW Method | Jeb Riordan | Skillshare

Product Creation Quickstart: Learn How to Prioritise Tasks Using the MoSCoW Method

Jeb Riordan, Project Manager | Web Developer | jebriordan.com

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
6 Lessons (13m)
    • 1. Introduction to the MoSCoW Method for Prioritising Tasks

      1:18
    • 2. The MoSCoW Method

      2:15
    • 3. Four Categories of Priority

      1:46
    • 4. How to Prioritise: The Concepts

      3:38
    • 5. Final Thoughts

      3:00
    • 6. Class Project

      1:01

About This Class

Because of the strict time-boxing of the sprint development cycle and the need to minimise the time to market of a viable product, it’s absolutely imperative the features and requirements that add the highest business value are developed first.

So the Clients wish list of features and the items in the Product Owners product backlog need to be prioritised. But just as  important, is the need to reach a common understanding with all stakeholders on the importance they place on the delivery of each feature and product backlog item

The MoSCoW Method of prioritisation is one of many that have been developed over the years and is used extensively in software development projects

And the definitions of the four priority categories help stakeholders fully understand the impact of setting a priority to every feature and requirement.

If your into product creation using Agile/Scrum you need to know how to prioritise every task that the development team need to complete.

So, sign up for the class and let’s go explore MoSCoW…

Transcripts

1. Introduction to the MoSCoW Method for Prioritising Tasks: because of the strict time boxing of the Sprint development cycle on the need to minimize the time to market of a viable product, it's absolutely imperative that the features and requirements that at the highest business value are developed first, so the client Swiss list of features on the items in the product owners product backlog need to be prioritized. But just as important is the need to reach a common understanding with all stakeholders on the importance they place on the delivery of each feature and product backlog item. The Moscow method, the prioritization is one of many that have been developed over the years on is used extensively in software development projects on the definitions of the four priority categories. Help stakeholders fully understand the impact of setting a priority. Teoh every feature and requirement if you're into product creation. Using agile scrum, you need to know how to prioritize every task that the development team need to complete. So sign up for the course and let's go explore Moscow 2. The MoSCoW Method: so we have a whole long list of product features and requirements that the client and the product owner want in the final product. This list is the product backlog. Now we can't complete them all in one sprint. So we need to select the highest priority items to be included in the next sprint back lock . And once we've frozen the sprint backlog and because we have probably bitten off more than we can chew, we need to prioritize the items in the sprint backlog for completion in the Sprint time box . So we need a structured, repeatable logical method for prioritizing items in the list. There is such a technique. It's called the Moscow method, a method for reaching a common understanding with stakeholders on the importance of delivering each feature and record. Moscow is an actual in loosely made up from the first letters of the prioritization categories they are must have should have, could have and would like, but probably won't get. The method is used where a deadline is fixed, like in a scrum sprint. So the development ing focus all efforts on the most important requirements requirements that provide the maximum business value, the development team would first focus on and delivered the must have requirements on in a discipline scrum t. The must have requirements will be delivered before the end of the sprint. All the sprint goal will not be achieved on the sprint will be considered a failure and we can't have that. Can we? Once all the must have requirements have been delivered, they should have and that could have items are worked on if there is time. The Moscow method structured, repeatable, logical maximum business value first on a prioritized into four categories. 3. Four Categories of Priority: So let's describe the four categories. Must have requirements are critical to the current delivery in the current time box to Sprint. All must have requirements must be delivered by the end of the Sprint or the Sprint has failed. The academics have even thought of a nick. An acronym for Must Must is a minimum usable subset should have requirements are important but not absolutely necessary. Foot delivery and the current sprint. They can be as important as the most Hafs, but I may be not so time critical for the current sprint, and they probably will be re categorized to Must have for the next Sprint could have sought desirable but not absolutely necessary. They could improve the end product for a little more development costs. They will probably be included if the overall project timeframe is not compromised on budget and resources are available. All stake holders of Greek that the requirements labeled as would like that probably won't get, or at least critical, lowest business very items that will probably not make it to the final product I would like , but probably won't get. Items are not planned into the current delivery schedule, but still included in the product backlog. For now, the four prioritization categories must have should have, could have and would like, but probably won't get. 4. How to Prioritise: The Concepts: So how do we do it? The minimum usable subset of requirements that the delivery team guarantees it will deliver in the current sprint. If this item is not delivered by the target date, then there is no point in deploying the solution by the target date. The solution is not legal. Without it, the solution is not safe. Without it on, a viable solution cannot be delivered without it. Maybe the question. What happens if this recording is not met? If the answer is canceled the project, then it must be must have requirement. If there is some kind of work around that could be included, then it could be a should have. Or maybe you could have. But that doesn't mean it will not be delivered. Only that delivery is not guaranteed in this development cycle. Should have are important but not critical, maybe painful to leave out. But the solution was still work. Maybe there is a work around that could be implemented, albeit temporary, may be considered the impact in terms of business value or the number of people affected. If the requirement is not met, that could have wanted or desirable, but not as important. on, we'll have less impact than a shooter. This list of could have's are at risk of not being delivered in the current sprint. They will only be delivered in a best case scenario where all the workers smoothly and there is time towards the end of the time box to consider working on them. The could haves are the first choice to be dropped from the current sprint. If time is running out, note that it is sometimes very difficult to differentiate between a should have, and it could have so once again, very important to define the rules the very beginning. And we do that by identifying some objective criteria that separates the should haves and could haves, probably based on some quantitative estimate of the impact of not including the requirement would like, but probably won't get. These are the requirements that the scrum team of a great will not be delivered at this time. These requirements are still included in the product backlog because, after all, they're part off the clients wish list and included in the overall scope of the project. Keeping them in the product backlog also add voice the temptation to include the murder later date on also sets the expectations of all steak orders of what will be included in the final product I would like, but probably won't get. Items also can help keep focus on, the more important must have could have and should have items how to do it. The must haves are the minimum usable subset The should have are important but not critical . The could haves are desirable but not important, and they would like, but probably won't get well. They will not be delivered this time. 5. Final Thoughts: now a quick comparison between waterfall project management in the agile scrum product creation in traditional waterfall projects. All requirements are treated as must have, since they are included in the scope of the project, the requirements are met, but more often than not, the time schedule is compromised. Well, it's different in creating a product using scrum because the time frame is fixed and it's the scope, all the list of requirements that is adjusted. So it is extremely important to prioritize older requirements of the very beginning. Now it's more than likely that the beginning, all the requirements are considered as must have. What We're only human right, and we really want to include all the product backlog items in the final product in the given time frame. But that's not really realistic, so we need to balance the categories a little. On the overall consideration is that anything other than a must stop is a contingency. Remember the must stop definition off the minimum usable subset that the delivery team guarantee to deliver. So for an individual sprint, the percentage of must haves will typically be around 60% of total effort. The shoot house and they could have make up the remainder of that of Leffert and that would like but probably won't get this. Items are not included at all. So some final notes make sure the whole scrum teen on the key stakeholders understand the Moscow technique on the rules around prioritization. Start out with all requirements is would like but probably will get and then justify why they need a higher priority. Ask boy. The requirement is needed for the final product. Answer the current increment of the product. Can a requirement be split into several items and is it necessary to deliver all the items at this time? What happens if the requirement is not meant? If the answer is canceled, then it's a must stop for sure. If there is a work around, then the record mint is not a must have Moscow must have, should have, Could have would like, but probably won't get used to prioritise requirements for the final product and for the current sprint to meet the Sprint goal, allocate no more than 60% total effort to the must haves 6. Class Project: If you have been around project management for any time, you will have observed that there is a document template to managing control Any and all processes on product creation used in the scrum framework is no different. So is there a document template out there somewhere that documents the Moscow prioritization of product features and requirements? Your class project is to go out there into the Internet and find a suitable template for recording on managing the priority of a set of product features using the four Moscow categories off. Most top should her could have would like, but probably won't get, download a sample and then uploaded into your project area and then make comment on its suitability and usefulness. Good hunting.