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