Suggestions on how to do better Software Release Planning for large number of Feature Teams using SCRUM & part of same Program & Release Cadence

1. Better Release Planning for Feature Teams
Sep 2017 Amit Singh
PMP, ACP, CSM, SASM
1

2. Why?
• Important stakeholder decisions are accelerated in a day—
not after many weeks of emails exchanges around, trying to
find the right person to make the decision, but RIGHT NOW.
 All stakeholders face-to-face (but typically multiple locations)
 Management sets the mission, with minimum possible constraints
 Requirements and design emerge
 Important stakeholder decisions are accelerated
 Teams create—and take responsibility for—plans
 All Teams aligned with common expectation and vision
2

3. Program Increment – PI Planning Summary
• Facilitated by the Release Manager, this event will include
all key members of the Release Feature Teams, whenever
possible.
• It will take place over two days- (3 hours Global & 4 hours local
Planning), and occurs within the Innovation and Planning
Iteration.
• The result of planning is a commitment to an agreed set of
Program objectives for the Release.
3

4. Program Increment Planning benefits
1. Establishing face-to-face communication across all team members and stakeholders
2. Building the social network the Features depends upon
3. Aligning development to business goals with the business context, Vision, and Team
and Program Increment Objectives
4. Identifying dependencies and fostering cross-team/ cross-ART collaboration
5. Providing the opportunity for “just the right amount” of Architecture and User
Experience (UX) guidance
6. Matching demand to capacity, eliminating excess Work in Process (WIP)
7. Fast decision-making
4

5. Input and Outputs of Release Planning
Inputs to PI planning include:
• Business context (see Content Readiness below)
• Roadmap and vision
• Top features from the Program
A successful PI planning event delivers two primary outputs:
• Committed PI Objectives – a set of “SMART” objectives
• Program Board – the planning board highlights the new feature delivery dates,
feature dependencies among teams and cross-Products and relevant milestones.
5

6. Prior Readiness
• Organizational readiness
– strategic alignment and teams and Program scope setup
• Content readiness
– management and development preparedness
• Facility readiness
– the actual space and logistics for the event
6

7. Agenda for Release planning
7

8. Day 1- Business Context
• A senior executive/line-of-business owner describes the current state of the
business and presents a perspective on how well current solutions are
addressing current Customer needs.
8

9. Day 1 : Vision & Planning Context
• Product/Solution Vision – Product Management presents the
current program vision (typically represented by the next top
10 upcoming features) and highlights any changes from the
previous PI planning meeting, as well as any upcoming
Milestones.
• Planning Context and Lunch – The Release Manager presents
the planning process and expected outcomes of the meeting.
9

10. Day 1- Architecture & Engineering
• Architecture Vision and Development Practices
System Architect/Engineering presents the architecture vision. In addition, a senior
development manager may present Agile-supportive changes to development practices, such
as test automation, DevOps, Continuous Integration and Continuous Deployment, which are
being advanced in the upcoming PI.
10

11. Day 1: Draft Plan & Review
• Teams present key planning outputs, including draft objectives, potential
risks, and dependencies. Business Owners, Product Management, and other
teams and stakeholders review and provide input.
11

12. Day 1: Program Board
12

13. Day 1: Team Breakouts #1
• Teams estimate their capacity for each Iteration and identify the
backlog items they will likely need to realize the features. Each team
creates their draft plans, visible to all, iteration by iteration.
13

14. Day 1: Hourly Scrum of Scrum
14

15. Day1: Management Review and Problem-Solving
15
Management negotiates scope and resolves any challenges of resource
constraints, and dependencies by agreeing to various planning adjustments.
The facilitates and keeps key stakeholders together for as long as necessary
to make the decisions needed to reach achievable objectives

16. Day 2 Agenda
• Planning Adjustments – The next day, the meeting begins with managers
describing any changes to planning scope and resources.
16

17. Day 2: Team Breakouts #2
• Teams continue planning, making the appropriate adjustments & finalizes
their objectives for the Release, to which the business owners assign business
value.
17

18. Day 2: Final Plan Review and Lunch
• All teams present their plans & impediments to the group.
• If the plan is acceptable to the customers, the team brings their PI objective
& program risk sheet to the front of the room so that all can see the
aggregate objectives unfold in real time.
18

19. Day 2: Program Risks
• During planning, teams have identified critical program-level risks and impediments
that could affect their ability to meet their objectives.
• These are addressed in a broader management context in front of the whole group.
One by one, the risks are addressed clearly, honestly, and visibly & categorized.
19

20. • Confidence Vote – Once program risks have been addressed, teams vote
on their confidence in meeting their program PI objectives.
• Each team conducts a “fist of five” vote.
• If the average is three or four fingers, then management should accept the commitment.
• If the average is fewer than three fingers, then planning adjustments are made and plans
are reworked.
• Any person voting two fingers or fewer should be given an opportunity to voice their
concern. This might add to the list of risks, require some re-planning, or simply informative.
20

21. • Plan Rework – If necessary, teams rework their plans until a high
confidence level can be reached. This is one occasion where alignment and
commitment are valued more highly than adhering to a timebox.
• Planning Retrospective and Moving Forward – Finally, the Release
Manager leads a brief retrospective for the PI planning event to capture
what went well, what didn’t, and what can be done better next time
21

22. Program Objective
• After the planning event, the PMO and other stakeholder summarize the
individual team PI objectives into a set of program PI Objectives and use this
to communicate externally and to track progress toward the goals.
• The program proceeds to execute the PI, tracking progress and
adjusting as necessary to the changes that occur as new knowledge emerges.
• Execution of the PI begins with all the teams conducting planning
for the first iteration, using their PI plans as a starting point. This is fresh
input for the normal Iteration Planning processes that follow.
22

23. Program & Team Objectives
23

24. Next steps after PI Planning:
• Product Management -Uses the Program PI objectives to update the
roadmap and improve the forecast for the next Release
• PMO -The program board is often used during the SOS meetings to track
dependencies, or it may not be maintained (manually) after that time.
• Teams – member leave the PI planning event with a pre-populated
iteration backlog for the upcoming PI. They take their team’s PI Objectives,
iteration plans, and risks back to their regular work area.
• Program risks remain with the PMO, who ensures that the people
responsible for owning or mitigating a risk have captured the information,
and are actively managing the risk.
24

25. PostScript #1: Use Stretch Objectives
25

26. PostScript #2: Architectural Runway
• It consists of the existing code, components and technical infrastructure
needed to implement near-term features without excessive redesign & delay.
• There comes a point at which emergent design is an insufficient response to
the complexity of large-scale system development Leading to following:
• Excessive redesign and delays reduce velocity
• Systems become difficult to integrate, validate and maintain
• Decline of system qualities, known as Nonfunctional Requirements (NFRs)
• Reduced collaboration and synchronization among teams
• Low reuse of common components and redundancy of solution elements
26

27. PostScript #3: Architectural enablers(NFRs)
Implementing Architectural Runways enablers:
• The enabler is big, but there is an incremental approach to implementation. The
system always runs.
• The enabler is big, but it can’t be implemented entirely incrementally. The system will
need to take an occasional break.
• The enabler is really big, and it can’t be implemented incrementally. The system runs
when needed. In other words, do no harm.
27

28. PostScript #4: Pre & Post Planning events
28

29. PostScript #5: Inspecting last PI Objectives
29

30. PostScript #6: Vision Document snapshot
30