Requirements Prioritization Razvan Radulian, MBA June 10th, 2014 NWA IIBA Chapter Meeting
Nov 29, 2014
Requirements PrioritizationRazvan Radulian, MBA
June 10th, 2014
NWA IIBA Chapter Meeting
Agenda
• Why are we talking about it?• What are we talking about?• Who cares? Why?• When do (should) we do it?• How do we do it?• Techniques• Pitfalls & "Best" Practices
Quick note about my approach (W5Hy)First (W5H), understand…
•Why/Why not•What/What not•Who: By Whom/For Whom•When/When not•Where/Where not• How/How Not
… then (y), explore:
•Why [not] That?•Why [not] Them?•Why [not] Then?•Why [not] There?•Why [not] That Way?
KISS: Above all, Keep it Simple and Short!• Simple, not simplistic!• Short, but no [lazy] short-cuts!
[Noticed my minimalistic style?]
Why are we talking about it?
• Statistic: 65% of IMPLEMENTED Requirements are rarely or never!• CHAOS Reports: How many successful projects?!?• Waterfall: 14%• Agile: 42%
• Scope Creep or Scope Management?• Project & Resource Management• Risk Management
What are we talking about? Core concepts• Definition…• Prioritization vs. Urgency…• Requirements Analysis…• Deciding how to decide
Terms: Requirements Prioritization
• The process of determining the relative importance of a set of items in order to determine the order in which they will be addressed.
Source: BABOK Glossary
Terms: Prioritization vs. Urgency
• Importance: What's most important to do• Timing: What do we need to do first
Fundamentals: Requirements Analysis• Prioritize Requirements• Organize Requirements• Specify and Model Requirements• Define Assumptions and Constraints• Verify Requirements• Validate RequirementsSource: BABOK, Requirements Analysis Knowledge Area (6.1)
Who cares? Why? Do-ers and Consumers...• Business side…• Implementation side…• Facilitator(s)…
Who: Business stakeholders
• Customer• Sponsor• User(s)• Marketing, Sales...
Who: Implementation stakeholders
• Implementers (IT and more)• QA/Testers• Trainers• Usability and User-experience experts• Support
Who: Facilitator(s)
• Business Analyst• Project Manager
When do (should) we do it?
• Plan-driven approaches (e.g. Waterfall)• Change-driven approaches (e.g. Agile)• Initiating/Planning vs. Monitoring & Control
How do we do it?
• The Process…• The Inputs…• The Outputs (again, Who cares? Why?)…• The Criteria…
How: The Process (simplified)
• Plan and design a/the Requirements Prioritization process• Execute• Elicit and understand the requirements• Analyze and evaluate• Decide
• Monitor and upon change requests, repeat...• Once in awhile, step back and re-evaluate the process itself• If necessary, improve
How: The Inputs
• Business Case• Business Need• Requirements (ah, yeah!)• Requirements Management Plan• Stakeholder List, Roles, and Responsibilities
How: The Outputs (again, Who cares? Why?)• Requirements [Prioritized]• Categorized…• Ranked…
How: Outputs: Requirements [Prioritized]• Categorized• High, Medium, Low• MoSCoW…• Shall, Will, Might… (Don't!)
• Ranked• 1, 2, 3...• Sprint "Backlog"
How: The Criteria
• Business Value• Business or Technical Risk• Implementation Difficulty• Likelihood of Success• Regulatory or Policy Compliance• Stakeholder Agreement• Urgency
Techniques
• MoSCoW…• Voting…• Ranking…• Decision Analysis…• Risk Analysis…• Timeboxing/Budgeting…
Technique: MoSCoW
• Must• A requirement that must be satisfied in the final solution for the solution to be
considered a success.
• Should• High-priority item that should be included in the solution if it is possible. This is often a
critical requirement but one which can be satisfied in other ways if strictly necessary.
• Could• A requirement which is considered desirable but not necessary. This will be included if
time and resources permit.
• Won't• A requirement that stakeholders have agreed will not be implemented in a given
release, but may be considered for the future.
Technique: Voting
• Allocating fixed amount of resource.• "5" Dots• $100 or 100-points• Other tokens
Technique: Ranking & the Pareto Principle• Sorted Priorities• Avoiding the "High, Medium, Low" heuristic behavior • The Law of the Few (80/20, Pareto Principle)
• Focus on the important 35%• Remember the 65% statistic?
• Agile: Product Backlogs or the Lessons we should learn • See again the CHAOS Report (2011): Waterfall vs. Agile
Technique: Decision Analysis
• Framing the Problem• Objectives/Criteria• Evaluating (e.g. impact/outcome & probability)• Decision Tables & Decision Trees
Technique: Risk Analysis
• Impact & Likelihood• Assumptions & Constraints• Risk Mitigation Factors
Technique: Timeboxing/Budgeting
• All In, All Out, Selective• PM's "Triple" Constraint:• Time (Schedule)• Money (Budget)• Scope (Product, Project)• Quality, Risks…
• Agile's “tricks”:• Product Backlog• Estimates• Planning & Commitments
Some [of the many possible] Pitfalls...• Again, what was that 65% statistic?!? • Scope Creep or Gold-plating?
• 99% High-priority = NO Priorities!• "Flying by the seat of of your pants"• The Moving Target!• The Moving Highway!• The Moving Participants!
... and some "Best" Practices (1 of 2)• There are no "Best Practices"!• Do it early, but not too early!• Do it often, but not too often!• Just-in-time Prioritization...
• Follow a process • If you don't have a process...
• Design one and experiment with it• Adopt and adapt (sorry, no silver-bullets!)
• Expect it to change
... and some "Best" Practices (cont’d)• Clear and committed Roles & Responsibilities• Strong Support (Hey, Execs, are you listening?)• Once in awhile, step back and reflect...
... better yet, learn and improve!
Related Topics
• Enterprise Analysis• Project & Resource Management• Programs& Portfolio Management• Agility & Discipline (Risk-driven Management)• Facilitation
Thanks!
• My contact info:Razvan [email protected]
• Ask, share, helpIt is Common-sense...... just not that common!
Q&A