HOW TO PRIORITIZE REQUIREMENTS:

BETTER & FASTER!

Razvan Radulian, Why-What-How Consulting

Making the “impossible” possible!

Research Triangle Park IIBA Chapter Meeting

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

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!

PRE-WORKSHOP ACTIVITIES (2 OF 2)Watch the following videos:Getting stuck in traffic:

• Public Workshops - Triangle Regional Transit Programhttps://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…

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®.

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?TechniquesPitfalls & "Best" Practices

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

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?

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 ;-)

Never45%

Rarely19%

Sometimes16%

Often13%

Always7%

Source: Standish CHAOS Report (2012)

Successful42%

Challenged49%

Failed9%

Agile

Successful14%

Challenged57%

Failed29%

Waterfall

HOW “SUCCESSFUL” ARE OUR PROJECTS?

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?

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?

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?!?

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?!?

WHAT ARE WE TALKING ABOUT? CORE CONCEPTS

Definition…

Prioritization vs. Urgency…

Requirements Analysis…

Deciding how to decide

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.

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 relativevalue, 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.

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.

CORE TERMS:

PRIORITIZATION VS. URGENCY

Priority (importance): What are the most important “things” we need?

Urgency (timing):What do we need [to do] first?

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

WHO CARES?Why do THEY care about it?

WHO CARES? WHY? DO-ERS AND CONSUMERS...

Business side…

Implementation side…

Facilitator(s)…

WHO CARES?

BUSINESS STAKEHOLDERS

•Customer(s)

• Sponsor

•User(s)

•Marketing, Sales...

WHO USES THAT INFO?

IMPLEMENTATION STAKEHOLDERS

• Implementers (IT and more)

•QA/Testers

• Trainers

•Usability and User-experience experts

• Support

WHO MAKES IT HAPPEN?

FACILITATOR(S)

•Business Analyst

•Project Manager

WHEN DO WE DO IT?When SHOULD we do it?

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)

HOW DO WE DO IT?How SHOULD we do it?

HOW DO WE DO IT?

The Process…

The Inputs…

The Outputs (again, Who cares? Why?)…

The Criteria…

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

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!?!

HOW DO WE DO IT:

OUTPUTS (AGAIN, WHO CARES? WHY?)

BABOK 2:

Requirements [Prioritized]

• Categorized…

• Ranked…

BABOK 3:

•Requirements(prioritized)

•Designs (prioritized)

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!

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

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?

MOSCOWFROM 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.

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:

TECHNIQUE:

DECISION ANALYSIS

• Framing the Problem

•Objectives/Criteria

• Evaluating (e.g. impact/outcome & probability)

•Decision Tables & Decision Trees

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?

Product Backlogs or “Lessons we should have learned” • See again the CHAOS Report (2011): Waterfall vs. Agile

TECHNIQUE:

RISK ANALYSIS

• Impact & Likelihood

•Assumptions & Constraints

•Risk Mitigation Factors

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

PART II:THE EXPERIMENT &

ADVANCED CONCEPTSTry it again!

Lessons-learned

Best Practices

PARTS II & III WILL BE PRESENTED AT THE WORKSHOP.

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!

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.

"BEST" PRACTICES

Sorry…

…there are no"Best Practices“,

only Good Practices!

GOOD PRACTICES (1)

Do it…

EARLY, but not too early!

OFTEN, but not too often!

FAST, but not too fast!

GOOD PRACTICES (2)

Follow a Prioritization PROCESS:

• Don’t have one? Create it!

• Inefficient? Improve it!

• Good? Use it!

Expect it to change!

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!

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.

1. CATEGORIZE: MOSCOW

Must be satisfied

Must be built in

MUST

SHOULD

COULD

WON’T

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

Mu

st

Sho

uld

Co

uld

Wo

n’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 ?

…

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?

RELATED TOPICS

• Enterprise Analysis

•Project & Resource Management

•Programs& Portfolio Management

•Agility & Discipline (Risk-driven Management)

• Facilitation

THANKS!

My contact info:Razvan RadulianLinkedIn: whywhathowE-mail: razvan@w5hy.comTwitter: @w5hy

It is Common-sense...

... just not that common!

Q&A