Scribd
Upload
660 views11 pages

Safe & Scrum Master: PI Planning

The document outlines the responsibilities of a Scrum Master for pre-planning and planning sprint events in an agile project. It discusses facilitating feature breakdown, user story writing, dependencies mapping, and velocity planning. It also covers scheduling ceremonies, facilitating breakout sessions, risk analysis, and ensuring the team's capacity is not exceeded. A typical 2-day planning event schedule is provided along with an overview of key SAFE principles like continuous delivery, limiting work-in-progress, and decentralized decision making.

Uploaded by

lipor
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
660 views11 pages

Safe & Scrum Master: PI Planning

The document outlines the responsibilities of a Scrum Master for pre-planning and planning sprint events in an agile project. It discusses facilitating feature breakdown, user story writing, dependencies mapping, and velocity planning. It also covers scheduling ceremonies, facilitating breakout sessions, risk analysis, and ensuring the team's capacity is not exceeded. A typical 2-day planning event schedule is provided along with an overview of key SAFE principles like continuous delivery, limiting work-in-progress, and decentralized decision making.

Uploaded by

lipor
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 11

SAFE & SCRUM MASTER

PI Planning
PRE- PI PLANNING
RESPONSIBILITIES
• Capacity planning/feature discussions with PO
• Look to historical data if none, calculate
• Set up capacities in Rally/PI Planning App
• Facilitating PI planning meetups- feature breakdown, BLR etc
• Planning poker when estimating stories
• Bring in SME/dependencies for discussions if needed
• Coordinating team dependencies to breakout sessions.
• Teams KT sessions/training set up get schedules
• DSU’s if rework.
• Team building
• Problem Solving Workshop (tech the RTE is supposed to facilitate this ceremony)
• Present during I&A

• Team breakout schedule (this is something I do to facilitate less contact switching)


• Discuss with team- scheduling times of ceremonies, then schedule in outlook.
INNOVATION & PLANNING SPRINT
PI PLANNING EVENT
RESPONSIBILITIES
• Facilitate team breakouts
• Feature breakdown
• User Story writing/Estimation
• Discuss dependencies/risks
• ROAM risks with team
• Facilitate dependencies for breakouts
• PI Planning Program Board(some of this can be done prior to event)
• team velocities added
• Features tagged and placed on program board
• Dependencies mapped
• Milestones added and tied to features
• (Technically the team board is the responsibility of the entire team.)
• Velocities in Rally (if not done prior)
• Ensure team keeps to the 80% capacity for sprints
• SOS check-ins
• Risk ROAMing presentation in main event.
• Facilitate team Business Objective writing and completion for DPR and FPR
• Sprint planning for first iteration
PI PLANNING EVENT
2 DAY- TYPICAL SCHEDULE
BUSINESS OBJECTIVES SHOULD
BE
ROAMING RISKS
• Take an economic view
SAFE PRINCIPLES
• Reduce costs when we are creating
• Apply systems thinking
• Be aware of other teams and the entire train system.
• Assume variability; preserve options
• Want to have many options multiple final solutions and test as fast as we can so that we preserve our options. (They do hackathons to come up with the best way to do something)
• Build incrementally with fast, integrated learning cycles
• Agile/Scrum
• Base milestones on objective evaluation of working systems
• Metrics on working system so system is working faster. Adding features for features sake can slow a system down.
• Visualize and limit WIP, reduce batch sizes and manage queue lengths
• We don’t want to wait two weeks to deploy we want to deploy all the time
• Deployment is also part of DOD so they cannot say its done if it’s not deployed.
• Apply cadence, synchronize with cross-domain planning
• Unlock the intrinsic motivation of knowledge workers
• It’s not about the money its about making the work interesting.
• Motivators: hackathons, new tools, fun retros, pair programming
• Decentralize decision-making
• You trust that the dev will make the right choice on tools and they’ll get together and make the right tool
• Organize around value
• The more you have automated testing you are saving the company millions and millions of dollars
• Take systems view on value delivery
• 2 ways to reduce delivery time is by removing steps and reduce cycle time.
• Design with options in mind
REDUCE TIME TO MARKET

• Something will be delivered but


features are variable
• Product should be released at end of
sprints
SAFE THINGS
• Avg ART size 50-125
• Two types of teams: feature and component
• RTE best for removing systemic impediments
• System team: provides processes and tools to integrate and evaluate
• They improve the whole system
ANTI-PATTERNS
• Can be structural or behavioral
• 2 POs is structural
• Partially completed stories being carried over from iteration is behavioral
• Internal or external
• Devs don’t work collaboratively on stories- internal
• Lack of coordination with other teams leading to excessive WIP- external
• Many anti-patterns can be traced back to PO
• Underperforming of a PO can lead to a dysfunctional team- internal
• Po should: facilitate BLR, prepare for and participate in SP, elaborate stories and enablers in just
in time fashion, address team questions/be the voice of the customer, accept stories, participate in
SR and Retro, coordinate with other POs to manage dependencies

You might also like