This document outlines an Agile project management approach called Scrum Pulse. It begins with introductions and then:
- Defines the standard Scrum meetings like daily stand-ups, sprint planning and retrospectives.
- Describes the activities involved in a Scrum Pulse, including planning, development, testing and release preparation meetings.
- Provides examples of Scrum Pulse schedules for a development and production sprint.
- Discusses how Scrum Pulse can be used to calculate team capacity and balance workloads.
The Scrum Pulse approach aims to establish clear and repeatable processes to effectively manage Agile projects through regular synchronization meetings and planning activities.
Using IESVE for Room Loads Analysis - Australia & New Zealand
Scrum Pulse
1. SCRUM Pulse
Anna Obukhova, Project Manager
Anna.Obukhova@exigenservices.com
September 23, 2014 www.ExigenServices.com
2. 2 www.ExigenServices.com
Great to meet you!
My name is Anna Obukhova
More than 10 years in Software development, in Agile from 2004,
Agile Project Manager from 2005.
Managed Agile projects from 7 to 40 members, several projects
simultaneously, consulting PM in the 60 project Agile program.
Participating as SME in в Agile Center of Excellence in Exigen
Services.
My previous webinar – Distributed Agile Nov 2010
3. 3 www.ExigenServices.com
Agenda
Best Practices approach
Standard practices and meetings in SCRUM
What is Scrum Pulse
Basic Scrum Pulse activities
Additional activities
Example of Scrum Pulse
Different types of Pulse
Using Pulse for capacity calculation
How else we can use it
7. Sprint Pulse Generic Description
Activity Type Thursday Friday Sat Sun Monday Tuesday Wednesday Thursday Friday
Sprint Development. Progress in development should be sent daily by Scrum Master to BinkPM
as a Burn-Down Chart. Tracking of tasks status is done in TFS.
Daily Scrum meeting in the morning 15 minutes(time TBD) should uodate on the progress, next
tasks and impediments. PO, PM, SM, Technical and Test lead should attend.
Product Owner review. Done on Stage env, so ongoing development should not affect this
release functionality. Found issues or CRs aded to the backlog.
7 www.ExigenServices.com
Sprint X
Planning and Development
Pre-Planning meeting, PO with PPO
review the proposed scope, PPO asks
questions. PO modifies or clarifyes
backlog after the meeting.
Final review of the Sprint X backlog by PO.
Sprint planning. Planning is PO stories
introduction, then team does the more
detailed estimation and commits for the
sprint scope. After planning e-mail that
TFS is updated and note sent by Dev
team to PM and PO. If proposed scope of
the project larger thansprint capacity
PO should agree on the scope cut based
on his understanding of priorities.
Demo and PO Review
Sprint Demo. Held by PPO. Should have Demo
from Dev environment with presentation of
new functionality and bug fixes. Demo is
done by Dev team, Bink PM and PO should be
invited at least. PO says - Go or NOGO thisis
Sprint General acceptance. After Go branch is
uloaded ti Stage for PO detailed review.
Infrastructure updates Stage. After
update, Release manager sends note of
completion to Dev (start Reg) Usually
takes 2 hours for Minor update.
Good Practices
Sprint Retrospection meeting. About 30
minutes. Investigate what issues were
done, what was good, what are process
goals for next sprint (Called by SM,
inlude PM and PO)
Management Meetings
Dependency review.
Check the dependency
matrix, update status,
ensure activities
planned for this sprint
are alighed with
dependency handling.
Called by Bink PM, PO
and SM attending
Project Steering Group,
Report Bink about the
Progress. Billing, rick,
task information
should be gathered
and presented. Done
by Bink PM, SM and PO
attending
8. 8 www.ExigenServices.com
Sprint Pulse example
Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10
Demo Acc test Acc test Proj steer grp Risk meet Pre plan Code freeze Bugs
Retro Release prep Release Refactor
Sprintplan Spikes
Meeting When Owner Purpose Documentation
Program Steering Group Monday 9-12, project invited PGM New and existing project approvals Meeting minutes
Project Steering Group Day 4 and upon request PM Status review, imediments and escalations Project highligh report
Dev. Daily Scrum Daily morning (team dep) SM Daily standup status update. TFS update
Demo See pulse SM Show what was built and get feedback Agenda
Sprint planning See pulse SM Plan sprint Sprint backlog
Scrum of Scrums Daily 2 PM Sthlm time PM Impediments removal, risks, dependencies SoS minutes
Risk meeting See pulse PM Mitigate risks. Go through the whole log. Risk log
Celebrations After demo PM Teambuilding Photos
Dev. Retrospective See pulse SM Inpect, adjust and adapt Retro minutes
Pre planning See pulse SM Backlog is ready, core dep. Sprint backlog
Release meet See pulse PM Plan for release Release notes
9. 9 www.ExigenServices.com
Production Sprint example
Mon
Thu Fri Tue Wed Thu Fri Mon Tue Wed Thu Fri
Sprint 6 Development
Sprint 6 Code Freeze Code Freeze
Sprint 6 Release to Stage Stage
Stage Update
Sprint 6 Regression Test
Regression
Sprint 6 PO acceptance test
PO Acceptance
Sprint 6 Security Test Security
Sprint 6 Performance Test Performance
Sprint 6 Release to Production Prep Production
Sprint 6: bugfix
Planning
Bugfixing
Sprint 7 development
Next Sprint
Sprint 7 code freeze Code Freeze
11. 11 www.ExigenServices.com
Capacity calculation
Scrum Master 0 1 1 1 1 1 1 1 1 1
Dev Lead 0 0.5 0.25 0.5 0.5 0.5 0.5 0.5 0.5 0
Dev 1 0 0.5 0.5 0.25 0.5 1 1 1 1 0
Dev 2 0 0.25 0.5 0.5 0.25 1 1 1 1 0
Test1 0 1 1 1 1 1 1 1 1 1
Test 2 0 1 1 1 1 0 0 0 0 0
0 1.25 1.25 1.25 1.25 2.5 2.5 2.5 2.5 0
15
Sprint 8
Sum dev
capacity
Sum dev capacity per sprint (story points)
12. 12 www.ExigenServices.com
Why it is useful
Clear communication of process with the customer
Agreed meeting time with defined output and input
Ability to prepare for the meetings
Planning of additional activities
Different types of pulse depending on project stage
Capacity calculation in advance (vacations, new members,
customer visits all included)
Calculation of communication load for specific role (PO, SM, dev,
testers).
Established routines
Ability to manage flow between several responsible teams
Ability to balance the load of the non-coding activities for best
effectiveness.