When prioritizing requirements in a project, have you ever been in a situation in which virtually all requirements are High Priority or Critical? As you can imagine, ALL requirements being High priority is as "good" as NO requirements having ANY priority at all. Hmm, not very helpful, isn't it? Is there anything we can do about that? In this presentation/workshop we'll go through some ideas and practices on how to improve the requirements prioritization process. Agenda topics: - Why are we talking about Requirements Prioritization? - What are we talking about? - Who cares? Why? - When do (should) we do it? - How do we do it? Some useful techniques... - Pitfalls & "Best" Practices The workshop goes beyond the knowledge presented in this document, working as team with a faster and better Prioritization Process. The outcomes of that experiment in a future presentation.

1. HOW TO PRIORITIZE REQUIREMENTS:
BETTER & FASTER!
Razvan Radulian, Why-What-How Consulting
Making the “impossible” possible!
Research Triangle Park IIBA Chapter Meeting

2. AGENDA
Part I (pre-workshop):
• Core concepts, aligning with IIBA/BABOK (2 & 3)
• Pre-workshop activities (watch videos and reflect :)
Part II (workshop):
• Activity: Prioritize!
• Using what we’ve learned so far (Pre-workshop) to
define a better and faster Prioritization process
• Advanced/”unique” concepts and practices
• Activity: Try it again! (if time allows)
Part III (workshop wrap-up and follow-up)
• Lessons-learned and Takeaways
• Follow-up

3. PRE-WORKSHOP ACTIVITIES (1 OF 2)
To get more out of this workshop…
1. Read this slide-deck before the workshop
2. Watch 5 short videos (listed on following slide) to see what we can learn from…
• Getting stuck in traffic
• Sorting 2500 photos
• Playing “Poker”
• Cleaning up
• “Visiting” Moscow [sorry, no video at this time]
As you watch the videos, think about how we may combine (potentially, adapt)
these “disconnected” bits of information to come up with a better and faster way
to prioritize requirements…
…we’ll do just that during our workshop!

4. PRE-WORKSHOP ACTIVITIES (2 OF 2)
Watch the following videos:
Getting stuck in traffic:
• Public Workshops - Triangle Regional Transit Program
https://youtu.be/QSxomb_7hnk (15-min)
Sorting 2500 photos:
• How to edit a photo shoot in 5 minutes (time-lapse)
https://youtu.be/A2uH7dcBHTY (4-min)
• 3 ways to rate and cull images in Lightroom:
https://youtu.be/o8xRWc3BmGE?t=34s (7-min)
Playing “Poker”:
• Agile in Practice Planning Poker
https://youtu.be/0FbnCWWg_NY (4-min)
Cleaning up:
• Scrum Repair Guide Grooming the Product Backlog - Mike Cohn
https://youtu.be/KXJuss2w39w (5-min)
“Visiting” Moscow:
• Sorry, no video at this time…

5. QUICK NOTE ON HOW TO READ THIS
DOCUMENT…
 Top-level topic/branch: expanded in additional slides…
• Leaf-level information: no additional slides (expanding this topic)
Trademark note:
All places in this document that refer to IIBA and/or BABOK should be
read as IIBA® and/or BABOK®.

6. CORE CONCEPTS
Why are we talking about it?
What are we talking about?
Who cares? Why?
When do (should) we do it?
How do (should) we do it?
Techniques
Pitfalls & "Best" Practices

7. WHY ARE WE TALKING ABOUT IT?
Does it REALLY matter?

8. WHY ARE WE TALKING ABOUT IT?
Are we working on the right requirements?
How many failed/challenged projects?
Scope or Cope?
How wisely do we use our resources?
Risk Management anyone?

9. ARE WE WORKING ON THE RIGHT
REQUIREMENTS?
Standish Group (2002)*:
2/3 of implemented
requirements are
RARELY or NEVER
used!
* Kind of old data, but quite easy to
confirm it is still current by opening
almost any commercial application
(prime examples: MS Word or Excel ;-)
Never
45%
Rarely
19%
Sometimes
16%
Often
13%
Always
7%

10. Source: Standish CHAOS Report (2012)
Successful
42%
Challenged
49%
Failed
9%
Agile
Successful
14%
Challenged
57%
Failed
29%
Waterfall
HOW “SUCCESSFUL” ARE OUR PROJECTS?

11. SCOPE OR COPE!
YES :)
Scope Management:
Predefined and agreed-upon
process:
• Analysis
• Design/planning
• Building
• Verification/Testing
• Implementation
NO :(
“Cope” with changes:
Seat of the pants approach:
• Scope creep
• Feature creep
(aka. Gold Platting)
Following a Scope Management Process/Approach?

12. RISK MANAGEMENT ANYONE?
Requirements should be prioritized based on:
• Business Value
• Risk involved…
• From not implementing a requirement
• From implementing a requirement
Unfortunately, often times, the risks are treated as…
… an AFTER-THOUGHT?

13. IIBA’S VIEWS (BABOK): PURPOSE…
BABOK 2:
Ensures that analysis and
implementation efforts
focus on the most critical
requirements.
BABOK 3:
To rank requirements in
the order of relative
importance.
Why or… what?!?

14. WHAT ARE WE TALKING ABOUT?
Critical, must have, mandatory, nice-to-have, optional, delighter…
Shall, Will, Must, Should, Could, Might, Want…
… are we ALL talking the same language?!?

15. WHAT ARE WE TALKING ABOUT?
CORE CONCEPTS
 Definition…
 Prioritization vs. Urgency…
 Requirements Analysis…
 Deciding how to decide

16. CORE TERMS (DEFINITION):
REQUIREMENTS PRIORITIZATION (WHAT)
BABOK 2 (Section 6.1.2):
A decision process used to
determine the relative
importance of requirements.
The importance of requirements may be based on
their relative value, risk, difficulty of implementation,
or on other criteria.
These priorities are used to determine which
requirements should be targets for further analysis
and to determine which requirements should be
implemented first.
BABOK 3 (Section 5.3.2):
The act of ranking requirements
to determine their relative
importance to stakeholders…
Priority can refer to the relative value of a
requirement, or to the sequence in which it will be
implemented.
Prioritization is an ongoing process, with priorities
changing as the context changes.

17. CORE TERMS (DEFINITION):
REQUIREMENTS PRIORITIZATION (HOW)
BABOK 2 (Section 6.1.2):
A decision process used to determine the relative
importance of requirements.
The importance of requirements
may be based on their relative
value, risk, difficulty of
implementation, or on other
criteria.
These priorities are used to determine which
requirements should be targets for further analysis
and to determine which requirements should be
implemented first.
BABOK 3 (Section 5.3.2):
The act of ranking requirements to determine their relative
importance to stakeholders…
Priority can refer to the relative
value of a requirement, or to the
sequence in which it will be
implemented.
Prioritization is an ongoing
process, with priorities changing
as the context changes.

18. CORE TERMS (DEFINITION):
REQUIREMENTS PRIORITIZATION (WHY)
BABOK 2 (Section 6.1.2):
A decision process used to determine the relative
importance of requirements.
The importance of requirements may be based on their
relative value, risk, difficulty of implementation, or on other
criteria.
These priorities are used to determine
which requirements should be targets
for further analysis and to determine
which requirements should be
implemented first.
BABOK 3 (Section 5.3.2):
The act of ranking requirements to determine their relative
importance to stakeholders…
Priority can refer to the relative value of a requirement, or
to the
sequence in which it will be
implemented.
Prioritization is an ongoing process, with priorities changing
as the context changes.

19. CORE TERMS:
PRIORITIZATION VS. URGENCY
Priority (importance):
What are the most important “things” we need?
Urgency (timing):
What do we need [to do] first?

20. BA FUNDAMENTALS:
REQUIREMENTS ANALYSIS
BABOK 2:
(in Requirements Analysis)
• Prioritize Requirements
• Organize Requirements
• Specify and Model
Requirements
• Define Assumptions and
Constraints
• Verify Requirements
• Validate Requirements
BABOK 3:
(in Requirements Life Cycle Mgmt.)
• Trace Requirements
• Maintain Requirements
• Prioritize Requirements
• Assess Requirements Changes
• Approve Requirements

21. WHO CARES?
Why do THEY care about it?

22. WHO CARES? WHY?
DO-ERS AND CONSUMERS...
 Business side…
 Implementation side…
 Facilitator(s)…

23. WHO CARES?
BUSINESS STAKEHOLDERS
• Customer(s)
• Sponsor
• User(s)
• Marketing, Sales...

24. WHO USES THAT INFO?
IMPLEMENTATION STAKEHOLDERS
• Implementers (IT and more)
• QA/Testers
• Trainers
• Usability and User-experience experts
• Support

25. WHO MAKES IT HAPPEN?
FACILITATOR(S)
• Business Analyst
• Project Manager

26. WHEN DO WE DO IT?
When SHOULDwe do it?

27. WHEN DO (SHOULD) WE DO IT?
Plan-driven approach
(e.g. Waterfall):
• One-time
• Upfront
• Less (overall)
Change-driven approach
(e.g. Agile):
•Many times
•As-needed
•More (overall)

28. HOW DO WE DO IT?
How SHOULDwe do it?

29. HOW DO WE DO IT?
 The Process…
 The Inputs…
 The Outputs (again, Who cares? Why?)…
 The Criteria…

30. HOW DO WE DO IT:
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 a while, step back and re-evaluate the process itself
• If necessary, improve

31. HOW DO WE DO IT:
INPUTS
BABOK 2:
• Business Case
• Business Need
• Requirements
• Requirements Management
Plan
• Stakeholder List, Roles, and
Responsibilities
BABOK 3:
• Requirements
• Designs
Hmm… say that again!?!

32. HOW DO WE DO IT:
OUTPUTS (AGAIN, WHO CARES? WHY?)
BABOK 2:
Requirements [Prioritized]
• Categorized…
• Ranked…
BABOK 3:
•Requirements(prioritized)
•Designs (prioritized)

33. HOW DO WE DO IT/OUTPUTS:
REQUIREMENTS [PRIORITIZED]
Categorized:
•High, Medium, Low
•MoSCoW…
•Shall, Will, Might…
(Don't!)
Ranked:
•1, 2, 3,..., 999
•Sprint "Backlog"
… lessons from sorting 2500 photos:
Come to the workshop to find out!

34. HOW DO WE DO IT:
CRITERIA
BABOK 2 (Criteria):
• Business Value
• Business or Technical Risk
• Implementation Difficulty
• Likelihood of Success
• Regulatory or Policy Compliance
• Stakeholder Agreement
• Urgency
BABOK 3 (Factors):
• Benefit
• Penalty
• Cost
• Risk
• Dependencies
• Time Sensitivity
• Stability
• Regulatory or Policy Compliance

35. HOW DO WE DO IT:
TECHNIQUES
BABOK 2:
 Decision Analysis
 Risk Analysis
 MoSCoW
 Timeboxing/Budgeting
 Voting
BABOK 3:
• Backlog Management
• Business Cases
• Decision Analysis
• Estimation
• Financial Analysis
• Interviews
• Item Tracking
• Prioritization (?!?)
• Risk Analysis and Management
• Workshops
Apples and…
…oranges?!?
Wow, what
just happened
here?

36. MOSCOW
FROM BABOK 2 (NOT DEFINED IN BABOK 3!?!)
Must:
A requirement that must be satisfied in the final solution for the solution to be
considered a success.
Should:
A 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.

37. OK, LET’S TRY TO UNTANGLE THE “REST”!
Requirements Prioritization
Activity (Section 6.1)
Techniques:
• Backlog Management
• Business Cases
• Decision Analysis
• Estimation
• Financial Analysis
• Interviews
• Item Tracking
• Prioritization
• Risk Analysis and Management
• Workshops
Prioritization Technique
(Section 10.33)
Approaches:
• Grouping
• Ranking
• Time boxing/Budgeting
• Negotiation
BABOK 3 splits Requirements Prioritization Activity
(from BABOK 2) into:

38. TECHNIQUE:
DECISION ANALYSIS
• Framing the Problem
• Objectives/Criteria
• Evaluating (e.g. impact/outcome & probability)
• Decision Tables & Decision Trees

39. TECHNIQUE:
VOTING
Allocating fixed amount of resource.
• "5" Dots
• $100 or 100-points
• Other tokens

40. 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?
Product Backlogs or “Lessons we should have learned”
• See again the CHAOS Report (2011): Waterfall vs. Agile

41. TECHNIQUE:
RISK ANALYSIS
• Impact & Likelihood
• Assumptions & Constraints
• Risk Mitigation Factors

42. TECHNIQUE:
TIMEBOXING/BUDGETING
PM's "Triple" Constraint:
• Time (Schedule)
• Money (Budget)
• Scope (Product, Project)
• Quality, Risks…
Agile's “tricks”:
• Product Backlog
• Estimates
• Planning & Commitments
All In, All Out, Selective

43. PART II:
THE EXPERIMENT &
ADVANCED CONCEPTS
Try it again!
Lessons-learned
Best Practices
PARTS II & III WILL BE PRESENTED AT THE WORKSHOP.

44. SOME [OF THE MANY POSSIBLE]
CHALLENGES & PITFALLS...
• Again, what are we working on?!?
• Remember that 65% statistic?
• Scope Creep or Gold-plating?
• ALL High-priority = NO Priorities!
• "Flying by the seat of your pants“ approach
•Moving-parts problem:
• The Moving Target!
• The Moving Road/Highway!
• The Moving Drivers!

45. EXPERIMENT 1: FIRST TRY…
We have a list of 250 requirements.
Prioritize it!
Use whatever approach/technique that you/your team think(s)
works best
You have 10-15 minutes to do it.

46. "BEST" PRACTICES
Sorry…
…there are no
"Best Practices“,
only Good Practices!

47. GOOD PRACTICES (1)
Do it…
EARLY, but not too early!
OFTEN, but not too often!
FAST, but not too fast!

48. GOOD PRACTICES (2)
Follow a Prioritization PROCESS:
• Don’t have one? Create it!
• Inefficient? Improve it!
• Good? Use it!
Expect it to change!

49. GOOD PRACTICES (3)
• Clear & committed Roles & Responsibilities
• Strong Support…
... hey, Execs, are you listening?
• Once in a while, step back and REFLECT...
... better yet, learn and improve!

50. REMEMBER THIS?
MY FAVORITE “TECHNIQUE(S)”…
Categorize:
•High, Medium, Low
•MoSCoW…
•Shall, Will, Might…
(Don't!)
Rank:
•1, 2, 3,...,9
•Sprint "Backlog"
Categorize, then Rank (only what’s worth ranking)!
… what I learned from sorting 2500 photos.

51. 1. CATEGORIZE: MOSCOW
Must be
satisfied
Must be
built in
MUST  
SHOULD  
COULD  
WON’T  

52. BETTER MOSCOW?
“Using the following
table, let’s prioritize our
requirements!
Our approach goals:
• Do as many as possible
• Do it as fast as possible
• Improve quality of our
decisions
• …”
Requirement
Must
Should
Could
Won’t
Consensus
Req A 6 1 M
Req B 1 5 1 S
Req C 3 1 2 3 ?
Req D 1 6 W
Req E 7 M
Req F 1 6 C
Req G 3 1 3 ?
…

53. FINAL EXERCISE:
GROUP ACTIVITY/DISCUSSION
Finally, how do we use the
information from all those
“disconnected” videos (listed at the
beginning of the document) to come
up with a faster and better
Prioritization Process/Approach?

54. RELATED TOPICS
• Enterprise Analysis
• Project & Resource Management
• Programs& Portfolio Management
• Agility & Discipline (Risk-driven Management)
• Facilitation

55. THANKS!
My contact info:
Razvan Radulian
LinkedIn: whywhathow
E-mail: razvan@w5hy.com
Twitter: @w5hy
It is Common-sense...
... just not that common!

56. Q&A