When organizations move to agile for software delivery, there is often tension with traditional portfolio management. Rick Austin illustrates 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.
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 be adaptive and support continuous improvement
• 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
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
19. 19
Backlog Size
Velocity
Burndown
Escaped Defects
Commit %
Acceptance % Ratio
Scope Change
PROGRAM
TEAMS
PORTFOLIO
TEAMS
DELIVERY
TEAMS
Scr um
Kanban
Kanban
Cycle Time
Features Blocked
Rework/Defects
Takt Time/ Cycle Time
Time/Cost/Scope/Value
ROI/Capitalization
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
EFFECTIVENESS
• Revisit business
case
• Validate fitness
function for
capability
23. 23
GOVERNANCE
PORTFOLIO
WORK INTAKE
SOLUTION
DEFINITION COMPLETED
PORTFOLIO
TEAM
PROGRAM
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
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
EFFECTIVENESS
• 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
EFFECTIVENESS
• 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
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
EFFECTIVENESS
• 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 and guard rails
• Epic Roadmap revised with risks and dependencies
• Release Plans
• Portfolio Plans updated
• Portfolio Risk Dashboard updated
35. 35
EPIC BRIEF
Summarize results
in the Planning
section of the Epic
Brief as a check
point to ensure
sufficient planning
is done
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
36. 36
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
EFFECTIVENESS
• Revisit business
case
• Validate fitness
function for
capability
PORTFOLIO
WORK INTAKE
SOLUTION
DEFINITION
EPIC VALIDATION
RELEASE
TARGETING
IN
PROGRESS
37. 37
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
38. P R I O R I T I Z A T I O N
T E C H N I Q U E S
39. 39
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
40. 40
“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
COST OF DELAY
41. 41
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
42. 42
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 A Y
45. 45
“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)
46. 46
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)
47. 47
1
2
3
4
5
CAPACITY IS INVESTED
T O O B T A I 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
49. 49
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
50. 50
ROLLING 12-18 MONTHS
EPIC
Q3 2017 Q4 2017 Q1 2018 Q2 2018 Q3 2018 Q4 2018
(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
51. 51
MUST
HAVE
Q3 2017 Q4 2017 Q1 2018 Q2 2018 Q3 2018 Q4 2018
(ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
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
52. 52
MUST HAVE
FEATURES
Q3 2017 Q4 2017 Q1 2018 Q2 2018 Q3 2018 Q4 2018
(ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
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
You Know A Great Deal Here
WON’T
HAVE
FEATURES
WON’T
HAVE
FEATURES
WHAT DO WE “KNOW”?
53. 53
Do you commit to the could have?
WHAT DO WE COMMIT TO?
MUST HAVE
FEATURES
Q3 2017 Q4 2017 Q1 2018 Q2 2018 Q3 2018 Q4 2018
(ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
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
54. 54
Do you commit to the could have?
WHAT DO WE COMMIT TO?
NO
MUST HAVE
FEATURES
Q3 2017 Q4 2017 Q1 2018 Q2 2018 Q3 2018 Q4 2018
(ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
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
55. 55
Do you commit to the wish to have?
WHAT DO WE COMMIT TO?
MUST HAVE
FEATURES
Q3 2017 Q4 2017 Q1 2018 Q2 2018 Q3 2018 Q4 2018
(ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
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
56. 56
Do you commit to the wish to have?
WHAT DO WE COMMIT TO?
NO
MUST HAVE
FEATURES
Q3 2017 Q4 2017 Q1 2018 Q2 2018 Q3 2018 Q4 2018
(ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
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
57. 57
Do you commit to the could have?
WHAT DO WE COMMIT TO?
MUST HAVE
FEATURES
Q3 2017 Q4 2017 Q1 2018 Q2 2018 Q3 2018 Q4 2018
(ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
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
58. 58
Do you commit to the could have?
WHAT DO WE COMMIT TO?
NO
MUST HAVE
FEATURES
Q3 2017 Q4 2017 Q1 2018 Q2 2018 Q3 2018 Q4 2018
(ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
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
59. 59
Do you commit to should and must?
WHAT DO WE COMMIT TO?
MUST HAVE
FEATURES
Q3 2017 Q4 2017 Q1 2018 Q2 2018 Q3 2018 Q4 2018
(ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
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
60. 60
Do you commit to should and must?
WHAT DO WE COMMIT TO?
YES
MUST HAVE
FEATURES
Q3 2017 Q4 2017 Q1 2018 Q2 2018 Q3 2018 Q4 2018
(ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
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
61. 61
Realign to reflect the most likely outcome.
THIS IS A “RELIABLE” COMMITMENT
MUST HAVE
FEATURES
Q3 2017 Q4 2017 Q1 2018 Q2 2018 Q3 2018 Q4 2018
(ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
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
62. 62
IF WE FINISH EARLY?
MUST HAVE
FEATURES
Q3 2017 Q4 2017 Q1 2018 Q2 2018 Q3 2018 Q4 2018
(ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
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
63. 63
FINISH THE ROADMAP
MUST HAVE
FEATURES
Q3 2017 Q4 2017 Q1 2018 Q2 2018 Q3 2018 Q4 2018
(ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
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
64. 64
ADD NEW & REPRIORITIZE
MUST HAVE
FEATURES
Q3 2017 Q4 2017 Q1 2018 Q2 2018 Q3 2018 Q4 2018
(ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
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
65. 65
THAT’S BETTER…
MUST HAVE
FEATURES
Q3 2017 Q4 2017 Q1 2018 Q2 2018 Q3 2018 Q4 2018
(ACTIVE) PLANNED Q+2 Q+3 Q+4 Q+5
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
67. 67
GOVERNANCE
PORTFOLIO
WORK INTAKE
SOLUTION
DEFINITION COMPLETED
PORTFOLIO
TEAM
PROGRAM
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
68. 68
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
ACTIVITIES • 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
69. 69
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
70. 70
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
71. 71
• Using portfolio management so we focus on the most valuable things
• Balancing capacity against demand
• How be adaptive and support continuous improvement
• How to support corporate governance (security, audit etc.)
WRAP UP
72. 72
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
Notes de l'éditeur
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
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