Any discussion about software development processes based on a few classical approaches how to create modern software. We have to establish some cadence to deliver products with the expected frequency keeping in mind the market needs. An Iteration length should reflect necessary speed of adaptation to product backlog changes. Teams should prepare for every iteration and groom the backlog items. And of course, there is should be priorities. It seems like the priorities management approach is absolutely intuitive and you do not have to have a deep understanding in standardising to use it in your software development. Still, establishing any process means declaration of general principles for every team member. And here lies complications: how to explain for any team member what means some digit or word next to a task or product bug? Especially in projects with many teams. It’s always possible to invent your own system of priorities, but it leads to necessity of explanation principles of your system for every new team member. If the project is big and you have a lot of new co-workers, well that's a problem. Therefore it's easier to use some time-tested international standards or approaches. In this article I would like to discuss using of MoSCoW method for prioritisation in product development as de-facto most common way to streamline work during iterations, that provide fast and measurable results. As an illustration I will provide an example of custom-made prioritisation method and problems that I faced with this approach. Then we going to dive into the MoSCoW method decomposition to consider every priority with live examples. An article may be useful for product managers or anyone chasing the well working product development process. Having fun with the custom-made approach regarding item priority A very long time ago, in one product team, we were trying to solve a problem with item priorities in our development cycles. The process itself was highly immature: implementation deadlines were often violated, the team had to work overtime, and product releases were of unsatisfactory quality. At that moment we used numeric priorities 1-2-3-4 and they didn’t help at all. Then we decided to streamline communication between team members and introduced an additional priority “5”. This priority would become the highest priority, more important than “1”, and mean “showstopper” - the ticket or item that should be implemented ASAP, despite any other task in the iteration backlog. Of course, this decision generated dozens of questions: Why is “5” more important than “1”? Because historically we had myriad priority “1” items, and “0” was used for the tasks that had to be prioritised later. Changing the meaning of “0” means a thoughtful review of the entire backlog, implementation of some migration, and nobody wanted to do it. How does it happen that we have so many priority “1” tasks in the iteration that we have to introduce an additional priority? And what is the purpose of 2-3-4? These are the most important questions that show the process immaturity, because team members had no idea what the difference was between 2-3-4. All these tasks were just “optional”. How do we explain these illogical rules to new team members? These rules were impossible to explain, and this improvement didn’t help to make things right. Why is “5” more important than “1”? Because historically we had myriad priority “1” items, and “0” was used for the tasks that had to be prioritised later. Changing the meaning of “0” means a thoughtful review of the entire backlog, implementation of some migration, and nobody wanted to do it. Why is “5” more important than “1”? Because historically we had myriad priority “1” items, and “0” was used for the tasks that had to be prioritised later. Changing the meaning of “0” means a thoughtful review of the entire backlog, implementation of some migration, and nobody wanted to do it. How does it happen that we have so many priority “1” tasks in the iteration that we have to introduce an additional priority? And what is the purpose of 2-3-4? These are the most important questions that show the process immaturity, because team members had no idea what the difference was between 2-3-4. All these tasks were just “optional”. How does it happen that we have so many priority “1” tasks in the iteration that we have to introduce an additional priority? And what is the purpose of 2-3-4? These are the most important questions that show the process immaturity, because team members had no idea what the difference was between 2-3-4. All these tasks were just “optional”. How do we explain these illogical rules to new team members? These rules were impossible to explain, and this improvement didn’t help to make things right. How do we explain these illogical rules to new team members? These rules were impossible to explain, and this improvement didn’t help to make things right. Of course, a prioritisation method wasn’t the general problem in this process. There were fundamental issues in approach about planning, risk management and strategy itself. But if you have plenty of challenges on your table, invention of your own obscure methodology doesn’t look like the best decision. Hereby, I would like to smoothly move on to using standards in task prioritisation in software development. Introducing the “MoSCoW” approach Some standards are strictly codified in international best-practice RFCs from bodies such as the IETF or IEEE, while others have become standards in their own right. The one I would like to introduce falls into the latter category. The MoSCoW methodology is not the only approach to task prioritisation, but one of the most efficient and universal methods to start doing things right. The approach was proposed by Dai Clegg in the book “Case Method Fast-Track: A RAD Approach” (1994) and became highly popular. The name “MoSCoW” has no connection to the northern capital and was created as an acronym of prioritisation categories: Must Have, Should Have, Could Have, Won’t Have. These categories may be associated with numeric priorities 1-2-3-4 and help to unambiguously determine the sequence of tasks or items in the product development iteration. The clear purpose of each category makes this method such a gem, and during this article, I would like to cover each priority with examples in Agile development. Case Method Fast-Track: A RAD Approach M S Co W First, it is necessary to establish an example scenario for using the approach. Let’s assume that we are members of a product team that is developing a B2B product. In this product, our customers can store and exchange files for their projects. To keep it simple, our team will add some basic feature, such as “User invitation” - the functionality of adding a new participant to a project. We promised our customers that we would implement this feature by a certain date; we have a commitment. Now, the team has to plan the next iteration to release the new version of the product before the deadline to maintain the company’s reputation. The team has the capacity - available time slots that could be used for the development. In this example, we will not segment team members by speciality (Dev, DevOps, QA), and will imagine our squad as a canonical universal Scrum team. The user invitation scenario has prepared technical requirements, UX/UI. The feature was already decomposed into meaningful items that make sense, and all these items were estimated. We know how many resources we should invest in this feature. Let’s assume that we are members of a product team that is developing a B2B product. In this product, our customers can store and exchange files for their projects. To keep it simple, our team will add some basic feature, such as “User invitation” - the functionality of adding a new participant to a project. We promised our customers that we would implement this feature by a certain date; we have a commitment. Now, the team has to plan the next iteration to release the new version of the product before the deadline to maintain the company’s reputation. The team has the capacity - available time slots that could be used for the development. In this example, we will not segment team members by speciality (Dev, DevOps, QA), and will imagine our squad as a canonical universal Scrum team. The user invitation scenario has prepared technical requirements, UX/UI. The feature was already decomposed into meaningful items that make sense, and all these items were estimated. We know how many resources we should invest in this feature. This is high time to use a prioritisation approach, and without further ado, let’s categorise this items. Must Have — 1 Must Have “1” priority is used for tasks, features, product backlog items, user stories or bugs that have to be included in the next development iteration. For example, during planning we realised that some tasks should be developed via agreements with clients or they are business-critical for some other reason. The main idea is these items are crucial and non-negotiable. The team has to estimate them, assume risks and plan them. If the estimation is more than the available time, items should be decomposed until the Minimal Valuable Product (MVP) can be created during the iteration. Building on the example of a new product feature, let’s assume we want to implement an “invite a new user to a project” feature. The “Must Have” category reflects MVP tasks and creates basic functionality. The iteration result has to provide a meaningful scenario and suitable tasks for the “1” priority: Implement the <Invite user> button in the project users list. Develop basic functions of the “Invite user” pop-up. Send a notification to the new user with authentication instructions. Implement the <Invite user> button in the project users list. Implement the <Invite user> button in the project users list. Develop basic functions of the “Invite user” pop-up. Develop basic functions of the “Invite user” pop-up. Send a notification to the new user with authentication instructions. Send a notification to the new user with authentication instructions. Should Have — 2 The second category is close to the “Must Have”. But it is something that we could postpone or deliver later. If we have an agreement with the client about user invitations, the MVP functions will be released as mandatory options in priority “1”. Nevertheless, there are always plenty of improvements that are necessary to implement, but they may be omitted in the declared scope. During the development stage, the team could face some risks with “Must Have” tasks, and second priority features should be postponed because they are not part of the MVP. For example, in the feature “User invitation”, the product should help to onboard new users. In the “Must Have” priority, the team will develop the critical scenario of creation and invitation. But it’s also important to send feedback to the inviting administrator that a new user has successfully logged in. It’s possible to use the feature without this feedback, but with this notification, the product is definitely better and the administrator will know that everything is fine. That’s how the second priority is established - we are improving the main process, something important for the business, only keeping in mind that this feature is additional. A “Should Have” product bug is something that breaks the scenario, but there is some reasonable workaround, available for an ordinary and non-technical user. It’s better to always fix these bugs during the iteration, but they could be negotiated near the deadline, because it’s still possible to release with them. Could Have — 3 This category is about improvements or minor visual defects that make a difference in general and could enhance the overall feel of the product, but they are not critical right now or deeply optional for the scenario. It would be nice to develop these things, only if the risks of "Must Have" or "Should Have" priorities are mitigated. During planning, the product team should think of "Could Have" items like this: the first priority has to be done. We should apply maximum effort to deliver the second priority. If everything is going OK, we are expecting to develop third priority items, but if we've failed, it shouldn't affect business. In the case of the "User invitation" feature, the third priority is some additional improvements in the user invitation form. As a third priority feature, the administrator could set up automatic notifications if a user hasn't logged in during the next three days. The project administrator could send this reminder manually if they notice the absence of a second priority notification, but it would be a nice touch to implement automatic reminders initially. Without this improvement, the product works fine and fulfils the terms of the contract, which makes it "Could Have". A "Could Have" priority as a product bug is something about rare features or visual bugs that are reproduced in some unusual environments. These bugs could be fixed if we do not have unfinished features or product bugs of other categories. Third priority bugs could be moved to the next iteration without lengthy negotiations, because they are not blocking the product release. For example, the majority of our customer base uses web browsers on a specific engine and we have an insignificant defect in an unpopular engine. It would be great to fix this bug, but if everyone is busy with more important tasks, there is no problem having this issue in the release. Won’t have — 4 A useful category that shows items that definitely won’t be released during the iteration. However, it’s important to have them if there is some capacity left. The product team could plan the iteration and segment tasks and bugs as first, second and third priority. And it happens that tasks are easier than was planned. The developers will have additional time that could be used for the fourth priority. These items are always developed in branches and are never intended to be merged in the current iteration, but this makes things easier for the next iteration. What kind of tasks are suitable as a “Won’t have” backlog? First of all, there are technical debt tasks. Highly important ones could be “Must Have” or “Should Have” priority as well, but regular code improvements for the codebase maintenance are a great example of the fourth priority. Developers have an opportunity to improve the code after the business-crucial tasks and use these improvements in the next iterations. If some changes are breaking and require non-typical QA execution, making improvements before new iterations also provides an opportunity for timely grooming. Also, it’s useful to add as the “Won’t have” priority some items that are going to be the first “Must Have” priority in the next iteration. We know that after the basic user invitation, we should integrate detailed user permission settings into this scenario, to simplify the administrator flow. This feature will be the MVP of the next iteration. If we have some capacity, it’s great to start developing it as fourth priority; that will lower the risks in the future. During the planning of the next iteration, this item’s priority will be updated to the “Must Have”. It’s better not to have product bugs of the fourth priority, because this category shows that the bug won’t be fixed during the iteration and it will just create additional mess on the backlog board. Still, priority could be used for the bugs that require architectural changes that are dangerous for the current iteration and their testing should be planned in the next one. Nevertheless, the main goal of this category is – everyone knows that this fix should not be merged in the current iteration and this helps to release the product more safely. Pros of using the priority approach The general one - this is a clear understanding of priorities meaning. In the beginning of this article I made an example of the custom-made priority approach with four categories, which nobody comprehended and the team has to introduce the fifth priority for the most important tasks. The MoSCoW approach fixes this incoherence and provides strict rules what the team members have to do next. These rules also serve as a team benchmark and helps to show the problems in the team planning approach. As example, if the team cannot develop all planned items of the first “Must Have” priority, not to mention other priorities, it shows deep issues in the process: The feature requirements wasn’t so good and clear. There was a mistake in the feature decomposition. The team somehow underestimated the complexity of tasks. Someone decided to change the idea during the iteration. The feature requirements wasn’t so good and clear. There was a mistake in the feature decomposition. The team somehow underestimated the complexity of tasks. Someone decided to change the idea during the iteration. The team has to provide retrospective and figure it out the source of the problem and find the solution to fix broken development process. After few iterations the process should streamline. On the same time stable completion of the third and fourth priorities is not so good either. It means that we are good in estimating and risk management, but it also shows that team is quite relaxed or underloaded. Maybe we could plan additional items of “Must Have” or “Should Have” priorities. Development process require a balance and some challenges to keep all team members sharp and looking for the improvements. Cons of the approach In the aforementioned example, tasks were categorised by priority for one particular iteration, but that doesn’t mean overall priority according to the company’s business. Tasks that are tagged as “Could Have” in the current iteration could become “Must Have” in the next one, and these changes require additional time during every planning session for the iteration manager. Moreover, the approach still has a problem with the sequence of tasks in one category. If the iteration has few “Must Have” items, which of them should be developed first? This sequence still should be discussed through iteration planning and coordinated via specific software. There is no silver bullet for the whole development process, but using approaches such as MoSCoW helps to streamline basic processes. Conclusion There are a lot of methods and approaches for prioritisation. However, I think the MoSCoW approach is one of the easiest to start with general improvements to the software development process. This approach is more suitable for B2B market products and product development with clearly formulated tasks and vision. It’s necessary to have a plan for subsequent iterations to use this approach correctly. In a chaotic and fast-changing environment this approach may malfunction and create so many high-priority tasks, that will affect release predictability. The same issue may appear without proper planning and estimation processes. But nevertheless, using this approach will help to identify all these problems as soon as possible and launch an initiative for streamlining and making well-functioning product development.
![Clean Code: Single Responsibility, Open/Closed, Liskov Substitution SOLID Principles in TS [Part 4]](https://hackernoon.imgix.net/images/erom0wkF6nZC8UOvFBqlbSeNR4J2-br933z6.jpeg?auto=format&fit=max&w=3840)
