can be held back until a future delivery timebox. Could have Requirements labelled as Could have are desirable but not necessary and could improve the user experience or customer satisfaction for a little development cost. These will typically be included if time and resources permit. Won't have (this time) Requirements labelled as Won't have, have been agreed by stakeholders as the least-critical, lowest-payback items, or not appropriate at that time. As a result, Won't have requirements are not planned into the schedule for the next delivery timebox. Won't have requirements are either dropped or reconsidered for inclusion in a later timebox. (Note: occasionally the term Would like to have is used; however, that usage is incorrect, as this last priority is clearly stating something is outside the scope of delivery). (The BCS in edition 3 & 4 of the Business Analysis Book describe 'W' as 'Want to have but not this time around') Variants Sometimes W is used to mean wish (or would), i.e. still possible but unlikely to be included (and less likely than could). This is then distinguished from X for excluded for items which are explicitly not included. Use in new product development In new product development, particularly those following agile software development approaches, there is always more to do than there is time or funding to permit (hence the need for prioritization). For example, should a team have too many potential epics (i.e., high-level stories) for the next release of their product, they could use the MoSCoW method to select which epics are Must have, which Should have, and so on; the minimum viable product (or MVP) would be all those epics marked as Must have. Oftentimes, a team will find that, even after identifying their MVP, they have too much work for their expected capacity. In such cases, the team could then use the MoSCoW method to select which features (or stories, if that is the subset of epics in their organisation) are Must have, Should have, and so on; the minimum marketable features (or MMF) would be all those marked as Must have. If there is sufficient capacity after selecting the MVP or MMF, the team could then plan to include Should have and even Could have items too. Criticism Criticism of the MoSCoW method includes: Does not help decide between multiple requirements within the same priority. Lack of rationale around how to rank