Testing Enterprise scrum through Scrum for Program Management in large organisation. Program should be understood as a collection of projects, activities, support and operations moving toward a business related goal. This goal can consist of different natures: time bound, risk bound, etc...

1. Scrum Program Management
towards Enterprise Scrum
working
document

2. Big Picture
scrum
team
scrum
team
scrum
team
scrum
team
scrum
team
scrum program

3. Levels of Protections
scrum
team
scrum
team
scrum
team
scrum
team
scrum
team
scrum program
Scrum Program protects
team initiatives from
Management decisions
to ensure a permanent
flow of coherent value

4. Program
Vision
Team
Goal
Team
Goal
Team
Goal
Team
Goal
Team
Goal
Team
Goal
capabil
ity
capabil
ity
capabil
ity
capabil
ity
capabil
ity
capabil
ity
feature
feature
feature
feature
feature
feature
story
story
story
story
story
story
self organised
teams
3MonthsReleaseasSafe-
to-failcontainer
How to structure Program Backlog?

5. Program
Vision
Team
Goal
Team
Goal
Team
Goal
Team
Goal
Team
Goal
Team
Goal
capabil
ity
capabil
ity
capabil
ity
capabil
ity
capabil
ity
capabil
ity
feature
feature
feature
feature
feature
feature
story
story
story
story
story
story
self organised
teams
3MonthsReleaseasSafe-
to-failcontainer
How to structure Program Backlog?
defined by each
team

6. Program cadence
The Program cadence is set on a pace of 3 months:
over 3 months you increase the risks of stop-and-
gos from Management
under 3 months, the change is too important to
ensure both value generation and business agility
(response to business, customer or user oriented
requests)

7. Framework (naming convention)
Team also known as Scrum team is a group of 7 +/- 2
people including Product Owner, Scrum Master and at
least one developer and one tester. A team is stable, this
mean that a team member is fully dedicated to its team.
Floaters are people working for several teams, they are
floating.
Crowd is the ensemble of all the teams working in a
program organisation. Like for birds, the crowd is
swarming in a same direction.

8. Basic Framework
Release
Backlog
Release
Update
Release
Update
Release
2 weeks 2 weeks 2 weeks 2 weeks 2 weeks 2 weeks
1 month 1 month 1 month
Release Scope
change change
Change here is related to “strategical” change lead by management.
Business change is managed at team level and managed by the POs at sprint end or planning.
Emerging change from development is managed within the sprint like traditional scrum.

9. How to start
Program
Vision
Team
Goal
Team
Goal
Team
Goal
Team
Goal
Team
Goal
The Chief Product Owner shares the strategical roadmap
with the crowd.
Program Vision is the answer to “what means done in 3
months?”
The strategical roadmap is shared with the teams and they
design their “goal” or “team vision” on what part of the
Program they are able to develop.
During Program Planning workshop, team’s goals are put
together for alignment and dependencies are made visible
and countermeasures taken.

10. How to manage it
once a week the POs are gathering into a Scrum-
of-scrums and ask to 4 questions:
what have you done since last time we met?
does something impeding your progress?
what do you plan next?
are you putting something in someone’s
shoes?
objective of the meeting is replanning due to
emerging changes and alignment of the efforts
that’s not a status meeting
usually, the POs are giving feedback in front of
the Release Plan.

11. Release Update
Facilitated by Chief Product Owner
This is a Program Review in front of the crowd and program
stakeholders
It’s the Inspect-and-Adapt of the Release Roadmap
New changes can be added into the Program Backlog and
items from same size or value are removed.
Removed items are taken into account for the next release or
totally removed if no longer necessary.

12. Roles
(CPO) Chief Product Owner: responsible and accountable for the
Program Backlog. CPO activity is mostly alignment and
coordination of team efforts. The CPO is protecting the crowd
from unplanned strategical requests. He or She is responsible for
the time-to-market and the return of investment.
(SC) Scrum Coach (not an authority): he or she is supporting the
crowd and the CPO by shielding the program from interferences
due to impediments, risks and distractions. The SC is facilitating
the dynamic of the crowd with the support of the team’s scrum
masters. He or she is leading the change for the program and its
stakeholders.

13. appendix

14. Principle
set up
program
vision
what mean
release done?
each work stream defines its
own vision for the next 3
months
all visions are consolidated into a
program vision and challenged
dependencies are evaluated and are
constraints to prioritisation
collective validation of the
release of the next 3 months
incl. goals
3 months
fixed scope
1 single
consolidate
d vision
sort from
low to high
dependency
collective
engagement
and
organisatio
n

15. Release supportive organisation
Next 3 months
Next 6 months
Go liveProgram
Roadmap
• Design a high level architecture supporting the roadmap.
• Architecture should be improved at each release milestone.
• Self-Reorg: Based on that roadmap, ask team members which team they want to support
during the next 3 months release
Architecture Update Architecture Update Architecture Update
ReleaseReview
RoadmapUpdate
Retrospective
ReleaseReview
RoadmapUpdate
Retrospective
ReleaseReview
RoadmapUpdate
Retrospective
1 day workshoprelease release release
Self - reorg Self - reorg Self - reorg

16. Tracking Progress
Go-live
Release
Release
ProgramBacklog=sumofallBacklogs
Change request and
updates drop-outs
NextGoLiveProgr.Backlog
Treasury
ICO
Ex.Control
Royalties
R2R
Controlling
• Progress tracked bottom up
• Sprints are aligned: starting
and ending at the same time
• Program velocity is the sum of
all team´s velocities
• At Sprint end, Release
roadmap is updated according
to each sprint outcomes

17. Scrum Program Meetings
Scrum level Scrum Program level
Daily standups Weekly Scrum-of-scrums
Sprint Planning Release Planning
Sprint Review Release Review
Monthly Roadmap update
Sprint Retrospective Roadmap Retrospective
Recommendation:
Release Planing, Release Review
and Roadmap Retrospective
should be handled during a one
day collaborative workshop
option
1

18. Program Level
DAILY MEETINGS
• DAILY STAND UP
• Attendees: Scrum Team (Development Team, Scrum Master, Product Owner)
• Moderation: Scrum Team (self organised)
• Purpose: status meeting, highlight impediments
• Duration: 15 minutes
• When: each day, same time, same location
WEEKLY MEETINGS
• REFINEMENT MEETINGS
• Attendees: Scrum Team (Development Team, Scrum Master, Product Owner) + people to respond on team issues
• Moderation: Scrum Master
• Purpose: grooming both Sprint and Product Backlog in Development perspective, Planning Poker (effort estimation),
collaborative solution focused meeting
• Duration: 45 minutes
• When: once a week
• SCRUM-OF-SCRUMS
• Attendees: Product Owners, Management (passive) & Customers (passive)
• Moderation: Chief Product Owner
• Purpose: status meeting on development, identify and respond on overlaps and hints
• Duration: 45 minutes
• When: once a week, same day, same place
• GROOMING
• Attendees: Product Owners,& Customers (passive)
• Moderation: Product Owner
• Purpose: user stories and product backlog grooming, set up business values on user stories
• Duration: 45 minutes
• When: once a week, same day, same place
BI-WEEKLY MEETINGS
• SPRINT PLANNING
• Attendees: Management & Customers (on-demand), Scrum Team
• Moderation: Product Owner
• Purpose: defining Sprint Objective and Sprint Backlog
• Duration: 45 minutes
• When: at Sprint start
• SPRINT REVIEW
• Attendees: Management & Customers (active), Scrum Team
• Moderation: Product Owner
• Purpose: show and tell of sprint outcomes, inspect/adapt from the stakeholders
• Duration: 45 minutes
• When: at the end of the Sprint
• SPRINT RETROSPECTIVE
• Attendees: Scrum Team
• Moderation: Scrum Master
• Purpose: inspect/adapt from the development process,
• Duration: 45 minutes
• When: after Sprint Review
• ROADMAP UPDATE
• Attendees: Management, Customer, RUN (HB Operations), Users
• Moderation: Chief Product Owner
• Purpose: Update the roadmap according to Sprint outcomes
• Duration: 45 minutes
• When: after Sprint Review
MONTHLY MEETINGS
• RELEASE MEETING
• Attendees: Management & Customers (active), PO Team
• Moderation: Chief Product Owner
• Purpose: show and tell of sprint outcomes, inspect/adapt from the stakeholders
• Duration: 45 minutes
• When: at the end of the Release
option
2

19. “Feel free to improve it.”
–Pierre E. Neis
www.agilesqr.com