BETTER & FASTER! HOW TO PRIORITIZE REQUIREMENTS: Razvan Radulian, Why-What-How Consulting. Making the impossible possible!

Transcription

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 (15-min) Sorting 2500 photos: How to edit a photo shoot in 5 minutes (time-lapse) (4-min) 3 ways to rate and cull images in Lightroom: (7-min) Playing Poker : Agile in Practice Planning Poker (4-min) Cleaning up: Scrum Repair Guide Grooming the Product Backlog - Mike Cohn (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! Often 13% Sometimes 16% Always 7% Never 45% * 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 ;-) Rarely 19%

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

11 SCOPE OR COPE! Following a Scope Management Process/Approach? 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)

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 SHOULD we 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 SHOULD we 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 Ranked: 1, 2, 3,..., 999 Sprint "Backlog" Shall, Will, Might (Don't!) 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 Wow, what just happened here? Apples and oranges?!? BABOK 3: Backlog Management Business Cases Decision Analysis Estimation Financial Analysis Interviews Item Tracking Prioritization (?!?) Risk Analysis and Management Workshops

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! BABOK 3 splits Requirements Prioritization Activity (from BABOK 2) into: 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

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

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