Embedded Files
Having all the detail in relation to effort (in days) & cost in hand, all relevant stakeholders are able to better gauge the time lines and the total investment in achieving the said solution.
Yet, surely NOT all requirements MUST be in the solution. Surely not all tasks are required to be implemented prior the solution being used in its designated environment. We therefore must prioritise.
This is where MoSCoW comes in. MoSCoW enables all stakeholders to agree and define where individual requirements are placed within the Prioritisation group as defined in the image to the left.
This exercise requires the team to analyse every user story and their associated tasks. A particular user story may be a MUST but not all tasks associated with the user story are actually MUSTs.
The defined MUSTs here must approximately amount to ~20% of the portion of the tasks pertaining to the Minimal Viable Product (MVP). This shall in reality deliver a good chunk of the solution enabling the product get to Market sooner as well as begin to generate revenue and business benefit.
The rational behind the 20% tasks / 80% business benefit practice is to:
Invest in the most useable functionality of the product which shall deliver most of the business benefit to both the company and user base;
Reduce the time to market, therefore receiving user feedback sooner;
Position the future of the product in an efficient manner. Still being in its infancy, the product team may quickly adapt to change when compared to larger solutions in a more mature stage.
Google Sites
Report abuse