MoSCoW

Before the session starts, add all your ideas, tasks, or user stories inside the board. What should I use? Use sticky notes and add your name.

You can start classifying each task as you add them to the board or you can wait until the meeting to start evaluating all the tasks and requirements together. Must:** Is this a "must"? What would happen if you don't do it? Is this essential? Would the project fail if one of these tasks or requirements are missing or incomplete? "Must" tasks or requirements are essential to success and are non-negotiable. Should:** How important is this task or requirement? "Should" tasks or requirements are considered critical, or high-priority tasks and for that reason should be completed whenever possible. Sometimes these need to be added or work on during the next sprint but the team can't forget about these requirements. Could:** Do we absolutely need this? How desirable is this requirement to our users or customers? Can I leave them out? What would happen? You will consider a "Could" requirement or task whenever is a highly desirable feature and will add value to your product but you know you can leave them out whenever there are time or resource constraints. Would:** Anything you will say " Would like to have..." but is just a nice to have and are consider non-critical tasks and only when there are time and resources will be considered. A good question to ask yourself and the team is: " What would happen if we don't do anything about this task or requirement?" Would the project fail? If "yes" you should add the task inside the "Must" section. If the answer is "no" keep asking questions. Is this a critical task for our project? Would this reduce our chances to get clients or would our product be harder to use? Is this important? For who? Why? If the team considers the task or requirement as a critical one this must be added inside the "could" section. Do we absolutely need this? Can we leave this task or feature out? If the answer is "yes" you will evaluate if the task or requirement is a "could" or a "would" task by asking the following question: Is this something that would be nice to have or we absolutely need this because our user considers this feature or product desirable and very attractive?

Sometimes the must and could section ends up with most of the sticky-notes. Somehow someone in the meeting always thinks everything is important. The reality is that teams get overwhelmed with too many "critical" and "very important" tasks as they don't know what they should be doing next. Take the time to discuss, as team what are the most important "must-do" tasks by choosing the first three.