Rick Austin - Portfolio mangement in an agile world [Agile DC]
•
5 gefällt mir•1,194 views
When organizations move to agile for software delivery, there is often tension with traditional portfolio management. This talk will illustrate how an organization can move from traditional portfolio management approaches to one that embraces agile software delivery. Doing so enables organizations to become predictable, improve the flow of value delivered, and pivot more quickly if necessary. We will demonstrate the use of governance that allows a more adaptive portfolio management approach. We will cover topics that enable agile portfolio management including: Lean techniques for managing flow Effective prioritization techniques Long range road-mapping Demand management and planning Progressively elaborated business cases Validation of outcomes Support for audit and compliance needs These topics will be illustrated by real-world examples of portfolio management that have been proven over the last five years with a wide range of clients.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Rick Austin - Portfolio mangement in an agile world [Agile DC]
Ähnlich wie Rick Austin - Portfolio mangement in an agile world [Agile DC] (20)
Mehr von LeadingAgile
Mehr von LeadingAgile (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Rick Austin - Portfolio mangement in an agile world [Agile DC]
- 2. 2 RICK AUSTIN ABOUT ME … Experience applying agile to small teams, large distributed teams, & change management Agile Project Management Volunteer and Leader Expert in Financial Services Industry Georgia State Grad Agile Transition Director, Program Manager Applications Development Manager Director of DevelopmentInformation Technology Director rick@leadingagile.com 678.743.1616 www.leadingagile.com twitter.com/rickaustin facebook.com/leadingagile linkedin.com/in/rickdaustin
- 3. 3 • Using portfolio management so we focus on the most valuable things • Balancing capacity against demand • How to support corporate governance (security, audit etc.) WHAT ARE WE EXPLORING
- 4. 4 PMI’S DEFINITION Portfolio management ensures that an organization can leverage its project selection and execution success. It refers to the centralized management of one or more project portfolios to achieve strategic objectives. Our research has shown that portfolio management is a way to bridge the gap between strategy and implementation. DEFINE PORTFOLIO MANAGEMENT
- 5. 5 PMI’S DEFINITION Portfolio management ensures that an organization can leverage its project selection and execution success. It refers to the centralized management of one or more project portfolios to achieve strategic objectives. Our research has shown that portfolio management is a way to bridge the gap between strategy and implementation. INVESTOPEDIA’S DEFINITION Portfolio management is the art and science of making decisions about investment mix and policy, matching investments to objectives, asset allocation for individuals and institutions, and balancing risk against performance. DEFINE PORTFOLIO MANAGEMENT
- 6. W H A T I S A N A G I L E W O R L D ?
- 7. 7 • Defines capabilities to build • Small enough for the team to develop in a few days • Everything and everyone necessary to deliver • Meets acceptance criteria • No known defects • No technical debt WHAT DO I MEAN? BACKLOGS TEAMS WORKING TESTED SOFTWARE
- 8. 8 • People have clarity around what to build • People understand how it maps to the big picture • Teams can be held accountable for delivery • No indeterminate work piling up at the end of the project WHY ARE THEY IMPORTANT? CLARITY ACCOUNTABILITY MEASURABLE PROGRESS
- 9. 9 • Governance is the way we make economic tradeoffs in the face of constraints • They way we form teams and foster collaboration at all levels of the organization • What do we measure, how do we baseline performance and show improvement? HOW DOES IT SCALE? GOVERNANCE STRUCTURE METRICS
- 10. S T R U C T U R E
- 12. G O V E R N A N C E
- 15. M E T R I C S
- 17. 17 Backlog Size Velocity Burndown Escaped Defects Commit % Acceptance % Ratio Scope Change PROGRAM TEAMS PORTFOLIO TEAMS DELIVERY TEAMS Scrum Kanban Kanban
- 18. 18 Backlog Size Velocity Burndown Escaped Defects Commit % Acceptance % Ratio Scope Change PROGRAM TEAMS PORTFOLIO TEAMS DELIVERY TEAMS Scrum Kanban Kanban Cycle Time Features Blocked Rework/Defects
- 19. 19 Backlog Size Velocity Burndown Escaped Defects Commit % Acceptance % Ratio Scope Change PROGRAM TEAMS PORTFOLIO TEAMS DELIVERY TEAMS Scrum Kanban Kanban Cycle Time Features Blocked Rework/Defects Cycle Time Time/Cost/Scope/Value ROI/Capitalization
- 20. G O V E R N A N C E F L O W
- 21. 21 GOVERNANCE Governance is the method for planning, coordinating and tracking requirements. Agile requirements are progressively elaborated from Epics, to Features and finally Stories. A measurable goal intended to deliver on the intent of an Initiative. Epics are defined and validated by Core Product Teams. A new or improved capability of the system. Features deliver a package of functionality that end users would generally expect to get all at once. Stories are small outcomes designed, built, tested, and delivered in 3- 5 days. Stories are elaborated collaboratively between Delivery and Program Teams. EPIC FEATURE USER STORY
- 22. 22 PORTFOLIO MANAGEMENT DEMAND MANAGEMENT DETAILED PLANNING EXECUTION GOVERNANCE STRATEGIC ALIGNMENT • Maximize Strategic Alignment • Increase Transparency • Organizational focus on delivering the most valuable work • Increase predictability • Reduce Time to ROI • Identify and plan for dependencies • Balance capacity and demand • Reduce rework • Improve quality • Agree to minimal capabilities needed to deliver value • Ensure credible release planning • Assess and guide the progress of value delivery • Minimize delivery risks • Continually make continue, pivot, kill, ship decisions MEASURE EFFECTIVENES S • Revisit business case • Validate fitness function for capability
- 23. 23 GOVERNANCE PORTFOLIO WORK INTAKE SOLUTION DEFINITION COMPLETED PORTFOLIO TEAM PROGRA M TEAM DELIVERY TEAM EPIC DEFINITION (DEPENDENCIES, SIZING & RISKS) DEMAND PLANNING & RELEASE ROADMAP MEASURABLE PROGRESS Feature | Kanban Story | Scrum Epic | Kanban RELEASE TARGETING IN PROGRESS EPIC VALIDATION PROGRAM WORK INTAKE SOLUTION DESIGN COMPLETED RELEASE PLANNING IN PROGRESS FEATURE VALIDATION FEATURE READY MAKE READY STORY READY STORY ACCEPTED IN PROGRESS STORY DONE DETAILED PLANNING (CLARITY & VIABILITY) EXECUTION & ACCOUNTABILITY PORTFOLIO PLANNING RELEASE PLAN & DEFINE OPERATEEXECUTE
- 24. P O R T F O L I O P L A N N I N G
- 25. 25 PORTFOLIO PLANNING Deliverables associated with each Planning level – Strategy to the Scrum teams DeliverablesDescription Strategy Statement Strategic Initiative budget allocation Portfolio Roadmap Portfolio budget allocation Portfolio Priorities Portfolio Planning : 6-12 month horizon, based on the Strategic Initiative budget allocation and the priority of the Programs Release Planning: 2-6 month horizon, Sequencing delivery of Epics, Features, Stories based on business priority Sprint (Iteration) Planning: 1-4 sprint horizon, Delivery team commitments for Stories in the next Iteration Strategic Planning: 12-24 month horizon, Strategy Council provides Strategic Roadmap derived from Group long term and short term strategy Task Planning: One sprint horizon, Delivery team delineates stories into tasks, and assigns tasks to team members Epic Priorities, Epic and Feature Sequencing Delivery Team assignment Task Definition Delivery Team member commitment Strategy Portfolio Program Release Iteration Task Program Roadmap: 2-6 month horizon, based on the Platform and Product budget allocation and the business priorities Story Sequencing Delivery Team commitment Program Roadmap Product budget allocation Product Priorities
- 26. 26 PORTFOLIO MANAGEMENT EPIC BRIEF: Supports the definition and flow of epics from new concept until they are delivered or killed. PORTFOLIO PLANNING SHEET: Decisioning tool that helps determine prioritization of the release backlog. EPIC ROADMAP: Roadmap of epics into the future. PORTFOLIO DASHBOARD: Indicator of health of epics, risks, and dependency impacts. RELEASE PLANS: Credible plan to meet release objectives.
- 27. 27 PORTFOLIO MANAGEMENT DEMAND MANAGEMENT DETAILED PLANNING EXECUTION GOVERNANCE STRATEGIC ALIGNMENT • Maximize Strategic Alignment • Increase Transparency • Organizational focus on delivering the most valuable work • Increase predictability • Reduce Time to ROI • Identify and plan for dependencies • Balance capacity and demand • Reduce rework • Improve quality • Agree to minimal capabilities needed to deliver value • Ensure credible release planning • Assess and guide the progress of value delivery • Minimize delivery risks • Continually make continue, pivot, kill, ship decisions MEASURE EFFECTIVENES S • Revisit business case • Validate fitness function for capability PORTFOLIO WORK INTAKE SOLUTION DEFINITION EPIC VALIDATION RELEASE TARGETING IN PROGRESS
- 28. 28 STRATEGIC ALIGNMENT PURPOSE ACTIVITIES OUTPUT • Align Epics to strategy • Intake all Epics, validate alignment to Strategic Objectives • Ensure alignment to Business Architecture • Defer Epics that are clearly not aligned to strategy • Epic Brief initiated • Strategically aligned Epics in Portfolio Backlog
- 29. 29 EPIC BRIEF Epic Owner completes the Vision section Epic Owner and Product Owner team start the Constraints section Begin the Opportunity / Business Case DESCRIPTION VISION CONSTRAINTS PLANNING • Name • Epic Owner/ Product Manager • Investment Theme (and Capability if known) • Value Statement • Features/Benefits • Dependencies • Risks • Assumptions • Opportunity Case
- 30. 30 PORTFOLIO MANAGEMENT DEMAND MANAGEMENT DETAILED PLANNING EXECUTION GOVERNANCE STRATEGIC ALIGNMENT • Maximize Strategic Alignment • Increase Transparency • Organizational focus on delivering the most valuable work • Increase predictability • Reduce Time to ROI • Identify and plan for dependencies • Balance capacity and demand • Reduce rework • Improve quality • Agree to minimal capabilities needed to deliver value • Ensure credible release planning • Assess and guide the progress of value delivery • Minimize delivery risks • Continually make continue, pivot, kill, ship decisions MEASURE EFFECTIVENES S • Revisit business case • Validate fitness function for capability PORTFOLIO WORK INTAKE SOLUTION DEFINITION EPIC VALIDATION RELEASE TARGETING IN PROGRESS
- 31. 31 SOLUTION DEFINITION PURPOSE ACTIVITIES OUTPUT • Validate business intent and epic viability • (Aka Discovery) • Validate Epic Brief Vision and Constraints • Identify work to address risks and dependencies • Technical Impact Assessment • Epic Brief Vision and Constrains sections • Program Backlog: Features, Architectural and Risk cards • Update WSJF – More on this in a bit
- 32. 32 EPIC BRIEF Epic Owner completes the Vision section Epic Owner and Product Owner team complete the Constraints section Prepare the brief Opportunity/Business Case DESCRIPTION VISION CONSTRAINTS PLANNING • Name • Epic Owner/ Product Manager • Investment Theme (and Capability if known) • Value Statement • Features/Benefits • Personas • Dependencies • Risks • Assumptions • Opportunity Case • Roadmap
- 33. 33 PORTFOLIO MANAGEMENT DEMAND MANAGEMENT DETAILED PLANNING EXECUTION GOVERNANCE STRATEGIC ALIGNMENT • Maximize Strategic Alignment • Increase Transparency • Organizational focus on delivering the most valuable work • Increase predictability • Reduce Time to ROI • Identify and plan for dependencies • Balance capacity and demand • Reduce rework • Improve quality • Agree to minimal capabilities needed to deliver value • Ensure credible release planning • Assess and guide the progress of value delivery • Minimize delivery risks • Continually make continue, pivot, kill, ship decisions MEASURE EFFECTIVENES S • Revisit business case • Validate fitness function for capability PORTFOLIO WORK INTAKE SOLUTION DEFINITION EPIC VALIDATION RELEASE TARGETING IN PROGRESS
- 34. 34 RELEASE TARGETING PURPOSE ACTIVITIES OUTPUT • Identify and plan for dependencies • Balance capacity and demand • Ensure credible release planning • Estimate Features • Determine Capacity • Plan Epics, Risks and Dependencies (Look ahead planning) • Communicate release objectives • Epic Roadmap revised with risks and dependencies • Release Plans • Portfolio Plans updated • Portfolio Risk Dashboard updated
- 35. 35 PORTFOLIO MANAGEMENT DEMAND MANAGEMENT DETAILED PLANNING EXECUTION GOVERNANCE STRATEGIC ALIGNMENT • Maximize Strategic Alignment • Increase Transparency • Organizational focus on delivering the most valuable work • Increase predictability • Reduce Time to ROI • Identify and plan for dependencies • Balance capacity and demand • Reduce rework • Improve quality • Agree to minimal capabilities needed to deliver value • Ensure credible release planning • Assess and guide the progress of value delivery • Minimize delivery risks • Continually make continue, pivot, kill, ship decisions MEASURE EFFECTIVENES S • Revisit business case • Validate fitness function for capability PORTFOLIO WORK INTAKE SOLUTION DEFINITION EPIC VALIDATION RELEASE TARGETING IN PROGRESS
- 36. 36 IN PROGRESS PURPOSE ACTIVITIES OUTPUT • Assess and guide the progress of value delivery • Review Epic Health and Portfolio Dashboard • Monitor & communicate Release Health to Stakeholders • Continue, Change or Stop Decisions • Epic Dashboard • Portfolio Dashboard • Portfolio Kanban Board
- 37. P R I O R I T I Z A T I O N T E C H N I Q U E S
- 38. 38 “If you only measure one thing, measure cost of delay” - D. Reinertsen, The Principles of Product Development Flow COST OF DELAY: • The revenue that could be earned each month a project is in the market • It is a way of communicating the impact of time on desired outcomes COST OF DELAY
- 39. 39 3 Features of a certain value with a CD3 calculation (value / duration) Total amount of value across three features is $19,000 COMPARE FEATURES FEATURE DURATION VALUE CD3 A 3 weeks $3000 1 B 4 weeks $7000 1.75 C 6 weeks $9000 1.5 Note: Value could be expressed as a relative number
- 40. 40 No Priority – Total Cost of Delay: $247k Shortest Job First – Total Cost of Delay: $175k Do The Most Valuable First - Total Cost of Delay: $187k DO BASED ON CD3 – TOTAL COST OF DELAY: $157K PRIORITY IMPACT ON C O S T O F D E L AY
- 41. D E M A N D M A N A G E M E N T
- 42. 42 HOW TO EXPRESS CAPACITY?
- 43. 43 “CAPACITY” CAN BE EXPRESSED AS “TEAM MONTHS” “TEAM SPRINTS” “There are 6.5 “Team Sprints” for Team X remaining for FY17” (e.g. 13 weeks / 2 weeks per sprint) “TEAM RELEASES” “There are 2.25 “Team Releases” for Team X remaining for FY17” (e.g. 13 weeks / 3 Sprints per Release) STORY POINTS “There are 150 Story Points available for the remainder of the year …” (e.g. Average velocity of 25 SPs x 6.5 Sprints remaining) “Only 25% of the “Team Months” for Team X remain for FY17” (e.g. 3 months remaining of 12 months this year)
- 44. 44 ALL WHICH DERIVE THEIR USE FROM STABLE VELOCITY! DELIVERY TEAM …Meaningless without Stable Velocity. “TEAM MONTHS” “TEAM SPRINTS” “There are 6.5 “Team Sprints” for Team X remaining for FY17” (e.g. 13 weeks / 2 weeks per sprint) “TEAM RELEASES” “There are 2.25 “Team Releases” for Team X remaining for FY17” (e.g. 13 weeks / 3 Sprints per Release) STORY POINTS “There are 150 Story Points available for the remainder of the year …” (e.g. Average velocity of 25 SPs x 6.5 Sprints remaining) “Only 25% of the “Team Months” for Team X remain for FY17” (e.g. 3 months remaining of 12 months this year)
- 45. 45 1 2 3 4 5 CAPACITY IS INVESTED T O O B TAI N O U T C O M E S 10 MONTHS 20% ~ 10 TEAM MONTHS 35% ~ 17.5 TEAM MONTHS 20% ~ 10 TEAM MONTHS 25% ~ 12.5 TEAM MONTHS Early on you can “roadmap” out what you’re willing to invest capacity for across investment themes … 35% 25% 2O% 2O% INVESTMENT THEMES Program Capacity Over Next 10 Months = 50 Team Months
- 46. R O A D M A P S
- 47. 47 Rolling Wave Planning, used in Agile processes, embraces the Lean ideal of making decisions at the last responsible moment, when the most possible information is available. This maximizes flexibility and planning accuracy. AGILE USES ROLLING WAVE PLANNING
- 48. 48 MUST HAVE – Minimum subset of requirements that must be delivered SHOULD HAVE – Important but not needed to have a viable solution COULD HAVE – Desired but less important WON’T HAVE – Things we have agreed to not deliver MOSCOW PRIORITIZATION
- 49. 49 ROLLING 12-18 MONTHS EPIC Q3 2018 Q4 2018 Q1 2019 Q2 2019 Q3 2019 Q4 2019 (ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5 ROADMAP EPIC ROADMAP EPIC ROADMAP EPIC ROADMAP EPIC This is … • A Rolling Plan for 12-18 months ahead • A Hypothesis for how to meet the goals • Not what you will do to meet those goals EPIC ROADMAP EPIC ROADMAP EPIC ROADMAP EPIC ROADMAP EPIC ROADMAP EPIC EPIC EPIC EPIC
- 50. 50 MUST HAVE SHOULD HAVE COULD HAVE WISH TO HAVE WISH TO HAVE MUST HAVE SHOULD HAVE COULD HAVE WISH TO HAVE WISH TO HAVE WISH TO HAVE MUST HAVE MUST HAVE MUST HAVE APPLYING MOSCOW TO EPICS Q3 2018 Q4 2018 Q1 2019 Q2 2019 Q3 2019 Q4 2019 (ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
- 51. 51 Do you commit to the could have? WHAT DO WE COMMIT TO? MUST HAVE FEATURES MUST HAVE EPIC COULD HAVE EPIC SHOULD HAVE EPICS COULD HAVE EPIC SHOULD HAVE FEATURES COULD HAVE FEATURES MUST HAVE FEATURES SHOULD HAVE FEATURES COULD HAVE FEATURES MUST HAVE EPIC WISH TO HAVE WISH TO HAVE WISH TO HAVE SHOULD HAVE EPICS WON’T HAVE FEATURES WON’T HAVE FEATURES Q3 2018 Q4 2018 Q1 2019 Q2 2019 Q3 2019 Q4 2019 (ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
- 52. 52 Do you commit to the could have? WHAT DO WE COMMIT TO? NO MUST HAVE FEATURES MUST HAVE EPIC COULD HAVE EPIC SHOULD HAVE EPICS COULD HAVE EPIC SHOULD HAVE FEATURES COULD HAVE FEATURES MUST HAVE FEATURES SHOULD HAVE FEATURES COULD HAVE FEATURES MUST HAVE EPIC WISH TO HAVE WISH TO HAVE WISH TO HAVE SHOULD HAVE EPICS WON’T HAVE FEATURES WON’T HAVE FEATURES Q3 2018 Q4 2018 Q1 2019 Q2 2019 Q3 2019 Q4 2019 (ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
- 53. 53 Do you commit to the wish to have? WHAT DO WE COMMIT TO? MUST HAVE FEATURES MUST HAVE EPIC COULD HAVE EPIC SHOULD HAVE EPICS COULD HAVE EPIC SHOULD HAVE FEATURES COULD HAVE FEATURES MUST HAVE FEATURES SHOULD HAVE FEATURES COULD HAVE FEATURES MUST HAVE EPIC WISH TO HAVE WISH TO HAVE WISH TO HAVE SHOULD HAVE EPICS WON’T HAVE FEATURES WON’T HAVE FEATURES Q3 2018 Q4 2018 Q1 2019 Q2 2019 Q3 2019 Q4 2019 (ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
- 54. 54 Do you commit to the wish to have? WHAT DO WE COMMIT TO? NO MUST HAVE FEATURES MUST HAVE EPIC COULD HAVE EPIC SHOULD HAVE EPICS COULD HAVE EPIC SHOULD HAVE FEATURES COULD HAVE FEATURES MUST HAVE FEATURES SHOULD HAVE FEATURES COULD HAVE FEATURES MUST HAVE EPIC WISH TO HAVE WISH TO HAVE WISH TO HAVE SHOULD HAVE EPICS WON’T HAVE FEATURES WON’T HAVE FEATURES Q3 2018 Q4 2018 Q1 2019 Q2 2019 Q3 2019 Q4 2019 (ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
- 55. 55 Do you commit to should and must? WHAT DO WE COMMIT TO? MUST HAVE FEATURES MUST HAVE EPIC COULD HAVE EPIC SHOULD HAVE EPICS COULD HAVE EPIC SHOULD HAVE FEATURES COULD HAVE FEATURES MUST HAVE FEATURES SHOULD HAVE FEATURES COULD HAVE FEATURES MUST HAVE EPIC WISH TO HAVE WISH TO HAVE WISH TO HAVE SHOULD HAVE EPICS WON’T HAVE FEATURES WON’T HAVE FEATURES Q3 2018 Q4 2018 Q1 2019 Q2 2019 Q3 2019 Q4 2019 (ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
- 56. 56 Do you commit to should and must? WHAT DO WE COMMIT TO? YES MUST HAVE FEATURES MUST HAVE EPIC COULD HAVE EPIC SHOULD HAVE EPICS COULD HAVE EPIC SHOULD HAVE FEATURES COULD HAVE FEATURES MUST HAVE FEATURES SHOULD HAVE FEATURES COULD HAVE FEATURES MUST HAVE EPIC WISH TO HAVE WISH TO HAVE WISH TO HAVE SHOULD HAVE EPICS WON’T HAVE FEATURES WON’T HAVE FEATURES Q3 2018 Q4 2018 Q1 2019 Q2 2019 Q3 2019 Q4 2019 (ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
- 57. 57 IF WE FINISH EARLY? MUST HAVE FEATURES MUST HAVE EPIC SHOULD HAVE EPICS SHOULD HAVE FEATURES COULD HAVE FEATURES MUST HAVE FEATURES SHOULD HAVE FEATURES COULD HAVE FEATURES MUST HAVE EPIC SHOULD HAVE EPICS WON’T HAVE FEATURES WON’T HAVE FEATURES Q3 2018 Q4 2018 Q1 2019 Q2 2019 Q3 2019 Q4 2019 (ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
- 58. 58 FINISH THE ROADMAP MUST HAVE FEATURES MUST HAVE EPIC COULD HAVE EPIC SHOULD HAVE EPICS COULD HAVE EPIC SHOULD HAVE FEATURES COULD HAVE FEATURES MUST HAVE FEATURES SHOULD HAVE FEATURES COULD HAVE FEATURES MUST HAVE EPIC WISH TO HAVE WISH TO HAVE WISH TO HAVE SHOULD HAVE EPICS WON’T HAVE FEATURES WON’T HAVE FEATURES Q3 2018 Q4 2018 Q1 2019 Q2 2019 Q3 2019 Q4 2019 (ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
- 59. 59 ADD NEW & REPRIORITIZE MUST HAVE FEATURES MUST HAVE EPIC COULD HAVE EPIC SHOULD HAVE EPICS COULD HAVE EPIC SHOULD HAVE FEATURES COULD HAVE FEATURES MUST HAVE FEATURES SHOULD HAVE FEATURES COULD HAVE FEATURES MUST HAVE EPIC WISH TO HAVE WISH TO HAVE WISH TO HAVE SHOULD HAVE EPICS WON’T HAVE FEATURES WON’T HAVE FEATURES MUST HAVE EPIC MUST HAVE EPIC Q3 2018 Q4 2018 Q1 2019 Q2 2019 Q3 2019 Q4 2019 (ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
- 60. 60 THAT’S BETTER… MUST HAVE FEATURES MUST HAVE EPIC COULD HAVE EPIC SHOULD HAVE EPICS COULD HAVE EPIC SHOULD HAVE FEATURES COULD HAVE FEATURES MUST HAVE FEATURES SHOULD HAVE FEATURES COULD HAVE FEATURES MUST HAVE EPIC WISH TO HAVE WISH TO HAVE WISH TO HAVE SHOULD HAVE EPICS WON’T HAVE FEATURES WON’T HAVE FEATURES MUST HAVE EPIC MUST HAVE EPIC Q3 2018 Q4 2018 Q1 2019 Q2 2019 Q3 2019 Q4 2019 (ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
- 61. D E T A I L E D G O V E R N A N C E
- 62. 62 GOVERNANCE PORTFOLIO WORK INTAKE SOLUTION DEFINITION COMPLETED PORTFOLIO TEAM PROGRA M TEAM DELIVERY TEAM EPIC DEFINITION (DEPENDENCIES, SIZING & RISKS) DEMAND PLANNING & RELEASE ROADMAP MEASURABLE PROGRESS Feature | Kanban Story | Scrum Epic | Kanban RELEASE TARGETING IN PROGRESS EPIC VALIDATION PROGRAM WORK INTAKE SOLUTION DESIGN COMPLETED RELEASE PLANNING IN PROGRESS FEATURE VALIDATION FEATURE READY MAKE READY STORY READY STORY ACCEPTED IN PROGRESS STORY DONE DETAILED PLANNING (CLARITY & VIABILITY) EXECUTION & ACCOUNTABILITY PORTFOLIO PLANNING RELEASE PLAN & DEFINE OPERATEEXECUTE
- 63. 63 PURPOSE • Intake process for Initiatives to be considered • Define Epics for Initiatives • Validate business intent & epic viability • Ensure credible release planning • Identify & plan for dependencies • Balance capacity & demand • Assess and guide the progress of value delivery • Validate solution • Customer / Vendor UAT • Validate Outcomes ACTIVITIE S • Epic Brief initiated • Validate Epic & Constraints • Identify work to address risks and dependencies • Product Discovery and Product Validation • Communicate release objectives (MVP) • Sufficient release planning is captured in planning toolset • Determine Capacity • Plan Risks & Dependencies • Review Epic Health & Portfolio Dashboard • Monitor & communicate Release Health to Stakeholders • Continue, Change or Stop Decisions • Determine if capabilities provide expected solution • Product Discovery and Product Validation • User acceptance testing • Work with vendors or customers for final solution validation • Measure Outcomes OUTPUTS • Epic Brief Draft • Product Discovery and Product Validation validated with customers • Epic Brief • Cost Estimate • Updated Business Plan – Cost Case • Financial Evaluation • Technology Impact Assessment • Portfolio Roadmap Updated • Portfolio Roadmap • Signoff - Initiative/Epic • Portfolio Planning Sheet • Release Plan • Updated Risk Assessment • Release Planning Signoff – Initiative/Epic • Epic Definition of Ready Validated • Epic Dashboard • Portfolio Dashboard • Product Discovery and Product Validation – Revalidated with customers • Epic Brief updated as completed • Operation Signoff – Program/Epic • UAT Approval • Release Review • Epic Definition of Done validated • Execute Signoff - Epic • Retrospective Analysis RACI (TEAM) • R – Portfolio Team • Program Team • A - Portfolio Team • C – Product Management • I – Delivery Team • R – Portfolio Team • Program Team • A - Portfolio Team • C – Product Management • I – Delivery Team • R – Portfolio Team • Program Team • A - Portfolio Team • C – Product Management • I – Delivery Team • R – Portfolio Team • Program Team • A - Portfolio Team • C – Product Management • I – Delivery Team • R – Portfolio Team • Program Team • A - Portfolio Team • C – Product Management • I – Delivery Team • R – Portfolio Team • Program Team • A - Portfolio Team • C – Product Management • I – Delivery Team PORTFOLIO WORK INTAKE SOLUTION DEFINITION COMPLETEDRELEASE TARGETING IN PROGRESS EPIC VALIDATION Portfolio Tier
- 64. 64 PURPOSE • Intake process for epics to be considered • High level solution design • Validate solution viability • Elaborate stories from features • Identify risks & dependencies • Features are ready for development • Credible plan exists • MMF identified • Assess and guide the progress of value delivery • All features and stories are done for the epic • Features in production ACTIVITIES • Creation of initial epic for Investment Decision by the Portfolio Team • Technology Assessment • Identify solution options • Identify work to address risks and dependencies • Story mapping • Estimate Features and Stories • Plan Risks & Dependencies • Define Test Plans • Validate MMF for initiative • Make release commitment • Estimate Features • Estimate Stories • Review Epic Health & Portfolio Dashboard • Monitor & communicate Release Health to Stakeholders • Continue, Change or Stop Decisions • Deployment to QA environments • Acceptance testing by IVT • Socialization of capabilities • Final defect remediation • NFR Validation • Operational handoff • Warranty support • Update portfolio metrics OUTPUTS • Feature Definition initiated • OOM Estimates (if available) • Program Backlog: Features Definition • Architecture Impact Assessment • Risk and Dependency Assessment • Test Strategy Defined • Feature Estimates • UX Design • High Level Design • Initial Release Plan • Updated risk and dependency lists • Spikes identified • Stories Named • System Test Plan • Integration Test Plan • Regression Test Plan • Solution Design Package • Feature backlog • items prioritized • Feature backlog • items sequenced across teams • Spikes planned • Release Defined • UAT Plan Defined • Feature Definition of Ready Validated • Feature Dashboard • Epic Dashboard • Portfolio Dashboard • Feature approval • Updated documentation • Traceability Matrix • System Test Approval • Integration Test Approval • Regression tests Approval • NFR Testing Approval • Disaster Recovery Plan Updated • Support Manual Updated • Service/Operational Level Agreement • Feature Definition of Done validated • Features released • Release criteria met • No high severity defects RACI • R – Program Team, Delivery Team • A - Program Team • C - Delivery Team • I – Portfolio Team • R – Program Team, Delivery Team • A - Program Team • C - Delivery Team • I – Portfolio Team • R – Program Team, Delivery Team • A - Program Team • C - Delivery Team • I – Portfolio Team • R – Program Team, Delivery Team • A - Program Team • C - Delivery Team • I – Portfolio Team • R – Program Team, Delivery Team • A - Program Team • C - Delivery Team • I – Portfolio Team • R – Program Team, Delivery Team • A - Program Team • C - Delivery Team • I – Portfolio Team • R – Program Team, Delivery Team • A - Program Team • C - Delivery Team • I – Portfolio Team Program Tier PROGRAM WORK INTAKE SOLUTION DESIGN COMPLETED RELEASE PLANNING IN PROGRESS FEATURE VALIDATION FEATURE READY
- 65. 65 PURPOSE • Ready the backlog • Stories ready for delivery teams • Work is done to complete story / feature • Story / feature has been completed • Story / feature has been accepted ACTIVITIES • Create story in defined format • Create acceptance criteria in the defined format • Provide additional documentation as needed • Tie acceptance criteria to feature acceptance • Revise Level of Value • Create story tasks • Develop story functionality • Unit test functionality • Code/Peer Review • Check-in code • Repair defects • Story meets the definition of done • Product owner approves story as meeting acceptance criteria. • Bugs found for the story have been remediated • Ongoing Support • Operational Handoff • Lessons Learned OUTPUTS • User Story is Defined with Scenarios • Acceptance Criteria is complete • Architecture Artifacts • UX Design, Wireframe Artifacts • Story Point Estimate • Story Definition of Ready Validated • Tasks Defined • Task Hours Estimate • Sprint Planning • Monitor Progress on Scrum Board • Standup • Story Development • Story Unit Testing • Story System Testing • Story Done • Story Definition of Done Validated • Story Demo • Story Accepted in ALM Toolset • Operational documentation updated (as needed) • Sprint Retrospective • Delivery Team Metrics RACI • R – Delivery Team, Program Team • A – Delivery Team • C – Delivery Team • I – Program Team • R – Delivery Team, Program Team • A – Delivery Team • C – Delivery Team • I – Program Team • R – Delivery Team, Program Team • A – Delivery Team • C – Delivery Team • I – Program Team • R – Delivery Team, Program Team • A – Delivery Team • C – Delivery Team • I – Program Team • R – Delivery Team, Program Team • A – Delivery Team • C – Delivery Team • I – Program Team Delivery Tier MAKE READY STORY READY STORY ACCEPTED IN PROGRESS STORY DONE
- 66. 66 • Using portfolio management so we focus on the most valuable things • Balancing capacity against demand • How to support corporate governance (security, audit etc.) WRAP UP
- 67. 67 RICK AUSTIN ABOUT ME … Experience applying agile to small teams, large distributed teams, & change management Agile Project Management Volunteer and Leader Expert in Financial Services Industry Georgia State Grad Agile Transition Director, Program Manager Applications Development Manager Director of DevelopmentInformation Technology Director rick@leadingagile.com 678.743.1616 www.leadingagile.com twitter.com/rickaustin facebook.com/leadingagile linkedin.com/in/rickdaustin
Hinweis der Redaktion
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- This is an initial qualitative filter made with minimal information. By removing Epics early from Planning, the organization avoids wasting significant time refining epics that will not be built in the near term. Strategy for very large or very small requests
- This is an initial qualitative filter made with minimal information. By removing Epics early from Planning, the organization avoids wasting significant time refining epics that will not be built in the near term. Strategy for very large or very small requests
- As more detail is available, the value and cost estimates may change significantly. Now is the time to make those changes in the planning sheet to ensure the highest value work is being addressed and lower value work is deferred.
- This is an initial qualitative filter made with minimal information. By removing Epics early from Planning, the organization avoids wasting significant time refining epics that will not be built in the near term. Strategy for very large or very small requests
- [TODO: Need to work on a good graphic]