Save £12 Million every year > Save £3 Million every quarter   
The Big Agile Toolkit: no Dogma, no Bias, no Accreditation, no Exams & no Fees   
 User Requirements  User Requirements   Outside-In Software Development   Outside-In Software Development

Within the requirements prioritisation activity you are trying to decide the priority of a series of requirements. When performing requirements prioritisation, your project will investigate each requirement to determine and assign a preference and use this to identify the priority, primacy or significance one requirement has over another requirement.

This is an arbitrary or subjective level of priority that signifies the extent of leaning your project has towards the requirement. The measures you use to determine this priority are up to your project. However, first we need to clear up a couple of points. Priority is not necessarily Sequence and it is not necessarily Urgency. Priority is Importance. You will have requirements that your project believe are important. You may have a set of requirements that your organisation state is mandatory. These requirements however do not necessarily need to be addressed or worked on first. Your project will sign up to deliver something called the Minimum Acceptable Delivery (M.A.D.). We will deal with this elsewhere. However, as long as the estimate (and therefore budget) for your work will cover the Minimum Acceptable Delivery, you will sign up to deliver the requirements and only the requirements inside the M.A.D.

The requirements inside the M.A.D. can be sequenced in any way that the project deems suitable and assigned a set of urgency levels appropriate to each requirement. Your project may assign sequence or urgency based on risk. So, your project may elect to address the risky requirements first to 'get them out of the way' thus minimising risk for the rest of the project. However, your project may elect to address the requirements that deliver the most added value first to demonstrate positive benefit for the organisation and thus improve the appeal of the project within the rest of the organisation.


Furthermore, however you assign priority it up to the project. The MoSCoW rules are a long standing almost ancient, in agile timescales, prioritization technique used during requirements gathering.

M stands for must have fundamental requirements. S stands for should have. These are the important requirements we would like to address if Scope adjustments allow. C stands for could have and W stands for will not have requirements. These last options are what are often called nice to have requirements but it is a pointless option to offer when considering the priority of important business requirements. It is like offering foolish to have or suggesting you have pointless to have requirements.

Choose some simple method to assign priority. High, Medium or Low; One, Two or Three; or whatever is simple and fit for purpose. At the end of the day, if you really want a priority assignment method that starts with MoSC, can we suggest a word that suits a technique singularly lacking the important elements of a modern swift responsive fit for purpose technique: MoSCHate. (Moschate: pron: mos-keyt, adjective : having an old musky smell).

All this intoxicating word play is not appropriate, beneficial or helpful, though. Your requirements are important. Your requirements are the functional delivery solution opportunities to be satisfied within your project. You originate them, select them, estimate them and gradually emerge them into a solution that offers them for assessment to your business partners and includes them in the final agreed delivery.

The topic of requirements prioritization is not very comprehensively blessed with many different approaches. Do a search of the web and you will see or have a look at WikiPedia where you will see a disconnected array of techniques with limited connection to Requirement prioritization. But there is good reason for this. The process is not complex. You must define the Requirements and apply prioritization. That is it. You cannot make the process into a complex demanding process. Prepare a Requirements List and establish your Prioritized Story Board. Then, during your Daily Forum, determine which requirements will be satisfied as part of the Build and Fix process, added to the Build and Fix List, then ultimately developed, assessed and delivered. Seriously, there is very little more to do.

Ultimately, you want to define your Minimum Acceptable Delivery (M.A.D.) and the selection of requirements you will commit to satisfy. We will extend the description of the M.A.D., the description of user stories, user requirements capture and other related topics as we progress through the Toolkit.

Buffer



 User Requirements     User Requirements   Outside-In Software Development    Outside-In Software Development



Glossary:     a  »   b  »   c  »   d  »   e  »   f  »   g  »   h  »   i  »   j  »   k  »   l  »   m  »   n  »   o  »   p  »   q  »   r  »   s  »   t  »   u  »   v  »   w  »   x  »   y  »   z


#personas  »   #artefacts  »   #archetypes  »   #patterns  »   #change  »   #personas  »   #increasingoutput  »   #reducingvariation  »   #improveefficiency  »   #abstraction  »   #predictionandcontrol  »   #management  »   #organisations  »   #socialnetworktheory  »   #failfast  »   #quality  »   #waste  »   #complexity  »   #learning  »   #adapt  »   #inspect  »   #improvement  »   #models  »   #complexadaptivesystems  »   #informationflow  »   #sytemsthinking  »   #butterflyeffect  »   #unpredictability  »   #chaos  »   #emergence  »   #emergentbehaviour  »   #distributedcontrol  »   #continuousimprovement  »   #complexityscience  »   #gametheory  »  
 Agile In 6 Steps    |    Projectivity    |    Instant Agile    |    Risks    |    Auditing Agile Projects 
Big Agile Toolkit Book (Amazon Japan)   |   Big Agile Toolkit Book (Barnes and Noble)
Buy the Big Agile Toolkit Book   |   Buy the Big Agile Toolkit Kindle eBook
Prioritising Requirements






   


The Big Agile Toolkit

 SPADE: Successful Pragmatic Agile Delivery Everytime™ 
   
Topic: 223  Page: 232/444  Progress: 52.3%
 About    |    Author 
Follow @BigAgileToolkit


This content can be copied to third parties for personal use if you acknowledge the source of the material with website URL (http://www.bigagiletoolkit.com/) and Twitter hashtag (#BigAgileToolkit).
In all other cases, no part of bigagiletoolkit or associated text or website may be copied reproduced or redistributed in any form or by any means without prior permission in writing from the author.
Agile Project Governance for Cost Conscious Companies™

All rights reserved.