Sprinting

Agile

CMT Mexico
 60mins

Sprinting – Sprint Cycles

Objective: Describe the process, concepts and

techniques for sprinting and what must be
considered during Sprint Cycles

© 2019. For information, contact Deloitte Touche Tohmatsu 2

Sprinting – Sprint Cycles
What we will cover in this module
Sprint cycles

Iteratively and incrementally develop potentially deployable product increments, increasing efficiency and quality through frequent feedback and improvement loops

Conduct SPRINT PLANNING Define and refine PROGRAM INCREMENT

Deliver user stories

Deliver working software Deliver security and controls Perform functional & regression testing
► Configure system ► Build and test Identity and Access Management Solution ► Develop test cases
► Develop code & review ► Implement Privacy Roadmap ► Identify test data & populate environment
► Produce software build ► Build and test Role-Based Security and Security ► Develop and test automation scripts
► Conduct unit test Vulnerability ► Conduct test
► Develop essential documentation & detailed business ► Confirm Implementation of Business Process, General IT,
processes as required Interface and Data Conversion Controls
User stories accepted by PO as delivered
Accelerate future skillsets Personalize the change campaign Activate business networks
► Engage business advocate networks
► Develop learning curriculum ► Execute the change campaign ► Develop and launch super user program
► Develop learning courseware and simulations
► Transfer knowledge to solution owners

Refine backlog (PBR) and roadmap Conduct agile ceremonies/events Close sprint
► Manage product & SPRINT BACKLOG ► Conduct DAILY STAND-UP ► Perform SPRINT RETROSPECTIVE
► (Continue to) Define/Refine user stories ► Perform SPRINT REVIEW
► Perform SCRUM OF SCRUMS
► Refine roadmap ► Calculate actual velocity

Non-sprinted activities
Deliver data conversion Prepare for release testing (system integration/ ► Manage Integrated Work Plan
► Develop specifications
► Develop code integration, mock conversion, parallel, regression,
► Conduct technical unit and functional object tests performance and stress, infrastructure)
► Develop test approaches, cases & plan ► Track Value Realization
► Identify test data

Prepare for production deployment Plan hyper care Plan service delivery
► Define release go/no-go criteria ► Develop to-be service delivery approach ► Perform service delivery framework assessment
► Develop deployment plan ► Develop service delivery transition plan ► Develop to-be service delivery approach
► Define batch jobs
► Develop batch job schedule ► Document service delivery requirements
► Develop service delivery recommendations & resource estimate
3
 Sample ceremony and meeting cadence
Sun Mon Tues Wed Thurs Fri Sat
Sprint day 1 Sprint day 2 Sprint day 3
Sprint Planning Daily standup Daily standup
Post Daily Standup Post Daily Standup
Product Backlog
Refinement

Sprint day 4 Sprint day 5 Sprint day 6 Sprint day 7 Sprint day 8
Daily standup Daily standup Daily standup Daily standup Daily standup
Post Daily Standup Post Daily Standup Post Daily Standup Post Daily Standup Post Daily Standup
Scrum of Scrums Product Backlog Scrum of Scrums Product Backlog
Refinement Refinement
Prep for Sprint
Review

Sprint day 9 Sprint day 10

Daily standup Sprint Review* * The Sprint Review should not be the first
time the Product Owner sees the completed Standard agile ceremonies
Post Daily Standup Sprint Retro
user story. The Sprint Review is not an Additional meetings
Product Backlog Acceptance meeting.
Refinement
© 2018. For information, contact Deloitte Touche Tohmatsu
The agile team is continuously collaborating throughout the sprint.
4
 Agile
technique
What is Capacity?

Total number of hours each development

Capacity team member is available to work on
backlog items during the upcoming sprint

• Initially calculated during Discovery and revisited in Sprint Planning

• Calculated in hours
• Considers holidays, PTO, training, conferences, etc.
• New scrum teams struggle to understand how much work they can commit to in each sprint

Total FTE days

Ideal Hours Capacity
in the sprint
Agile guideline is ~6
hours/day to allow time
for meetings, overhead,
non sprint work
© 2019. For information, contact Deloitte Touche Tohmatsu 5
 Agile
technique
What is Velocity?

• Velocity is the estimated total number of story points a development team can be expected
to complete in a sprint.
• Velocity is calculated as the rolling average of the velocity from the previous 3 sprints.

Release 1
70

59 60
60

50
44
42
40

30

20
15
Sprint 6 estimated velocity:
10
(42 + 59 + 60) / 3 = 53.6
0
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6

© 2019. For information, contact Deloitte Touche Tohmatsu 6

 Estimating Capacity/Velocity
How to forecast the development team’s sprint 1 velocity with limited historical data?
Sample
Capacity
Tracker

Forecast Sprint 1 Velocity

Identify and estimate high-priority user stories in the product backlog using points (planning poker)

• Make sure these user stories are small enough to be completed within the sprint

• Avoid partially committing to user stories, as that will lead to technical debt

Calculate the development team’s capacity using the capacity tracker or other preferred method or tool

• It is advisable to assume no more than six hours of productivity per day

• Development team capacity should account for holidays, meetings, team member availability to support the team, or other
special events that will limit a team member’s availability to work during the sprint

Select the highest-priority user story and decompose it into tasks

• Estimate (in hours) the amount of time required to complete each task

• Make sure tasks are small enough to be completed within a day (8 ideal hours)

Add up the task estimates for the selected user story and check whether the team has the capacity to complete the wok during the sprint

Repeat this exercise for the high priority user stories in the backlog until the team runs out of available capacity for the sprint

Use the user story task breakdown and estimated hours to balance sprint scope against capacity until you have
© 2018. For information, contact Deloitte Touche Tohmatsu 7

sufficient story point velocity data from completed sprints.

Estimating Capacity/Velocity
How to forecast future sprint’s velocity with limited historical data (for new teams)?

Consider using a range for new development teams since the team’s performance is unknown. Below are some suggested
multipliers.
Assuming the team’s capacity remains constant for the next 2-3 sprints, a forecast of the team’s velocity can be derived by
multiplying sprint 1 velocity with the low and high multipliers (see table below) and then taking the average of these
results.

Sprints
Completed
Low Multiplier High Multiplier Example
1 0.6 1.60 If a team achieved a velocity of 30 points in
2 0.8 1.25 sprint 1, then the forecasted velocity for
3 0.85 1.15 sprint 2 is:
4 or more 0.9 1.10
a. Velocity * Low Multiplier
Source: Agile Estimation and Planning (Mike Cohn)
30 * 0.6 = 18
b. Velocity * High Multiplier
30 * 1.60 = 48
c. Forecast for sprint 2
(18 + 48) / 2 = 33 story
points
© 2018. For information, contact Deloitte Touche Tohmatsu 8
Estimating Capacity/Velocity
How to forecast future sprint’s velocity with limited historical data (for an existing
development team)?

With an existing development team, the team’s performance is known, therefore multipliers are not needed.
Assuming the team has worked together in the past and is very familiar with the work to be performed or the team is about
to start a similar work stream within the same project (same type of work), then calculate the team’s focus factor after
sprint 1 and use it to forecast future sprint story points.

Example
If the team achieved a velocity of 30 points in sprint 1 and a capacity of 600 hrs, a forecast
of the team’s velocity can be derived by multiplying sprint 1 velocity with the team’s focus
factor.

1. Calculate the team’s points/hour for sprint 1

30 / 600 = 0.05pts/hr
2. Calculate the team’s capacity for sprint 2 by using the capacity tracker or other
preferred method or tool
Sprint 2 team capacity = 650hrs
3. Calculate the team’s forecast velocity for sprint 2
(Forecast Velocity = points/hour * team capacity)
Forecast Velocity = 0.05 * 650 = 33 points
© 2018. For information, contact Deloitte Touche Tohmatsu 9
Sprint Planning
On Day 1 of each sprint

Prepare for Sprint Planning

• Sprint Planning is an scrum team-
• Ensure Product Backlog Refinement level working meeting to plan the
ceremonies are being conducted on an
ongoing basis What is Sprint activities of a Sprint
• Opportunity for the scrum team to Planning? • The Scrum Master is accountable and
“preview” the top of the Product responsible for ensuring this meeting
Backlog takes place and facilitating
• Provide an opportunity to ask
questions prior to Sprint Planning
• Sprint Planning is attended by the
• Identify stories that are too large Who attends
entire scrum team including the
and need to be broken into smaller Sprint Planning? Product Owner
stories
• Calculate the historical velocity and
update capacity for pending Sprint • Held on Day 1 of each sprint, typically
• Set the right expectations for the How long is 2-4 hours for a 2 week sprint and
upcoming sprint Sprint Planning? scaled depending on sprint duration
• Determine who will be on PTO, and level of preparation
holidays, etc.
© 2019. For information, contact Deloitte Touche Tohmatsu 10
 Sprint Planning
Based on: priority, dependencies, specialized resources, coordination between scrum
teams

The what – 1st half The How – 2nd half

• Product Owner and the development team work • Scrum team decomposes User Stories into tasks.
together to establish sprint goals.
• Scrum team estimates the effort to complete each
• Scrum Master will confirm development team’s task in hours.
capacity and present the velocity to be used for
this sprint. • Review total estimated hours against development
team capacity.
• Product Owner and the development team select
User Stories from Product Backlog based on • Scrum team confirms that all stories can be
priority and sprint goals. Only “Ready” stories are completed as a part of the sprint.
considered (meet the scrum team’s DoR).

• Product Owner provides clarification on selected

User Stories.

There should be a commitment by the scrum team – the scrum team estimates and prioritizes
© 2019. For information, contact Deloitte Touche Tohmatsu 11

– and should be committed to completing the work.

 Agile
technique
Managing the sprint
Kanban boards

Past Velocity
Sprint 16 Velocity = 34 Capacity = 540
High Development Test Sprint Velocity
Sprint PO
Backlog IP Done IP Completed accepted 15 40

14 35

13 37
1 5 3 2 2

5 3 3 Sprint Burndown
3
Priority

Low

DoR DoD
Impediment List
Team Improvements
IP Done

User Stories Blocker

Defect

© 2019. For information, contact Deloitte Touche Tohmatsu 12

 Agile
technique
Managing the sprint
Burndown Charts – a graphical representation of estimated Figure 1: Remaining Hours
work that remains in the sprint

• Shows daily sprint or release status in a visual format that is

based on user stories
• Reflects work remaining in hours or story points on the Y axis
and time in X axis
• Internal progress report to manage current iteration updated Figure 2: Points Remaining
daily to reflect most up-to-date work remaining (hours or story Capacity Remaining Points

points) by sprint and/or release

50

45

• An “ideal” work line (the straight line from max hours down to 40

completion date) depicts the teams’ average rate of production 35

30

• When the remaining work line is above the ideal line, the team is 25

behind schedule 20

15

10

0
Day1 Day2 Day3 Day4 Day5 Day6 Day7 Day8 Day9 Day10
© 2019. For information, contact Deloitte Touche Tohmatsu 13
 Agile
technique
Managing the sprint
What story do Burndown Charts tell?

Great team. The team had Too Late. Team over- Too Early. Team under- Team not updating
a late start and was able to estimated capacity or estimated capacity or over remaining hours, refusing
get back on track. underestimated user stories estimated user stories and process, or not actively
and did not complete work. finished early. managing/tracking work.

© 2019. For information, contact Deloitte Touche Tohmatsu 14

 Agile
technique
Daily Stand-up
Ceremony

• The Daily Stand-up is a ceremony that occurs every day of the Sprint,
What is the except for the first and last days of the Sprint
Daily Stand-up?
• It is used to synchronize agile team members and their work

• The Daily Stand-up is attended by all team members

Who attends the
• Others may attend the Daily Stand-up, but only the team members
Daily Stand-up?
may speak

• Guideline is 15 minutes
• Experienced co-located agile teams may take less time, distributed
How long is the
teams may need more
Daily Stand-up?
• The Daily Stand-up occurs at the same place and time everyday for
consistency

© 2018. For information, contact Deloitte Touche Tohmatsu 15

 Agile
technique
Scrum of Scrums (SoS)
Managing cross scrum team dependencies Ceremony

• Meeting for selected representatives of scrum teams to discuss cross scrum

team integrations and dependencies
What is a Scrum of • Also consider process and tool enhancement opportunities, especially during
Scrums? earlier sprints
• Used as a technique to scale scrum for large project teams
• Conduct an SoS Retrospective to gather feedback across the scrum teams

• Attended by Scrum Masters, Product Owners, and selected development team

Who attends the members (tech lead, tester, analyst, etc.)
Scrum of Scrums? • Participants in the Scrum of Scrums meetings are included if/when they are
directly involved in an integration topic

• Early in a project, the SoS can be 30-60 minutes, twice a week – don’t try to
solve all issues, but have some conversation, determine action items, and
How long is a move on
Scrum of Scrums?
• Monitor and adjust the SoS schedule as needed depending upon process,
integration, and alignment variances
© 2019. For information, contact Deloitte Touche Tohmatsu 16
Typical hybrid agile project team structure

Agile Team 1 Executive Steering

Finance Scrum Master (s) Committee
responsible for consistent scrum Strategically directs
execution and standards project

Agile Team 2
Core Team
Sales and
Distribution Focus on program leadership,
backlog management, planning
and decision making, guiding
principles

Agile Team 3 Scrum of

Manufacturing Scrum
Scrums of
1-n Core Team
Scrums 2
Project Manager,
Chief Product Owner,
Chief Architect,
Agile Coach
Agile Team 4
Focus on integration topics and
Procurement cohesive solution build,
Consists of the Scrum Masters
from the individual scrum teams
17
 Agile
technique
Product Backlog Refinement
Ceremony

• Also known as “PBR” or refining

What is Product
Backlog Refinement? • Ensures the Product Backlog is always being refined ahead of the agile
teams who will pull work from it

• Attendance may vary, but before Sprint Planning, during the PBR, the
entire agile team should have previewed the User Stories and estimated
them
Who attends a PBR?
• SMEs may spend a significant amount of time outside the PBR working on
developing Features and User Stories, and use the PBR as a review with
the agile team

• Planned on a fixed schedule throughout the Sprint

• The amount of time invested in PBR will be greater when creating a new
How long is a PBR? product than when making enhancements to an existing product
• For a two week Sprint, plan for a minimum of 4 hours

Never allow the Product Owner to go into the

© 2018. For information, contact Deloitte Touche Tohmatsu 18

Sprint Planning meeting with an inadequate Product Backlog.

 Agile
technique
Sprint Review
Ceremony

• Sprint Review is a meeting to share the outcomes of the Sprint with

What is Sprint Review? the Product Owner, business owners, and stakeholders

• Sprint Review is attended by the entire agile team including the

Product Owner
Who attends a Sprint • The meeting is open to anyone who is interested in the outcomes of
Review? the Sprint (i.e., Stakeholders)
• Managers and executives are frequent attendees

How long is a Sprint

• Sprint Review meetings are normally between 1 and 2 hours in length
Review?

Formal slide decks not required, this is not a sales show!

© 2018. For information, contact Deloitte Touche Tohmatsu 19

The Sprint Review should NOT be the first time the Product Owner sees the done User Stories
 Agile
technique
Sprint Retrospective
Ceremony

• The Sprint Retrospective is a closed agile team meeting to identify

What is Sprint continuous improvement activities
Retrospective? • A joint Sprint Retrospective involves two or more agile teams in a
collaborative retrospective activity

• The agile team members are the only participants

Who attends a Sprint
• This is the only Scrum ceremony that is closed to individuals outside
Retrospective?
the team

How long is a Sprint

• Sprint Retrospective meetings are typically 1 hour in length
Retrospective?

© 2018. For information, contact Deloitte Touche Tohmatsu 20

 Agile
technique
Sprint Retrospective – The 4L approach
Ceremony

Like Learn
Things that you Things you have
have enjoyed learned that the
agile team should
be aware of

Lack Long For

Things you have Something you
seen the agile desire or hope for
team doing, but from either an
consider that agile team or
could be done personal/role
better perspective

The objective of a retrospective is to gather data about what happened since the last retrospective,
© 2018. For information, contact Deloitte Touche Tohmatsu 21

generate insights from that data, and generate improvement initiatives.

Sprint cycles success factors
Do not sprint user
stories that are not
ready (the scrum
team, using the DoR,
decides which user
stories are ready)

These items allow your

scrum team to be successful Leave the
The development team
development team
and to maximize the estimates the user
alone while they are
benefits agile techniques stories
sprinting
provide.

Conduct the
Apply capacity when
ceremonies, as
planning and
scheduled, with full
managing your
scrum team
roadmap and your
participation, and per
sprint backlogs
guidelines
© 2019. For information, contact Deloitte Touche Tohmatsu 22
 30mins

Release – Test, Deploy, Stabilize,

Operate & Optimize/Innovate

Objective: Describe the Release activities

© 2019. For information, contact Deloitte Touche Tohmatsu 23

Release – Test, Deploy, Stabilize, Operate & Optimize/Innovate
What we will cover in this module
Release
Test, Deploy, Stabilize, Operate & Optimize/Innovate
Deploy minimum viable product (MVP) sets, provide subsequent support, inspect and adapt
Test
Execute release testing (system integration/ integration, mock conversion, parallel, regression, performance and stress, infrastructure, user-
acceptance)
► Conduct test

Deploy
Accelerate future skillsets Deploy production solution
► Deploy & evaluate ► Deliver data integration & conversion solution ► Conduct Production Deployment Go/No-Go
learning ► Produce software build ► Execute production deployment
► Execute dress rehearsal ► Perform Legacy System Decommissioning

Stabilize & Operate

Perform hypercare Transition service delivery
► Perform service desk function ► Implement continuous service improvement program
► Conduct service delivery transition ► Conduct service delivery training
► Transition solution documentation to support organization
► Maintain and operate infrastructure
Close project

24
Testing guidelines
Apply the agile mindset

Agile guiding principles

Continuous attention to The best architectures, Business people and
Working software is the
technical excellence and requirements, and designs developers must work
primary measure of
good design enhances emerge from self- together daily throughout
progress.
agility. organizing teams. the project.

Leading to Deloitte’s testing guidelines

Agile
Mature agile
Multi- supports Ask quality
Embed projects apply Automate to
functional aspects of and test-
quality in to Continuous Apply code DevOps increase
team Test Driven focused
the process testing – review principles agility...Be
members are Development questions in
from the testing in concepts to that enable strategic in
all through PBR and
start small batches documentation earlier automation
responsible acceptance Sprint
integration approach
for quality criteria in user Planning
testing
stories

© 2019. For information, contact Deloitte Touche Tohmatsu

Test early, test often 25
Testing minimum expectations

Together the
Have dedicated
Start test Development Team
testing post
preparations early; and Product Owner
sprinting/pre-release
think about strategy nail down acceptance
AND do early system
and automation criteria when writing
and integration
approach during user stories to
testing in parallel to
Discovery leverage for testing
sprinting
purposes

Technical/functional
Ensure testing unit test with Product
expectations are Owner acceptance is
documented in DoD completed during
sprints

© 2019. For information, contact Deloitte Touche Tohmatsu 26

Applying agile techniques our way – Testing

Release
Vision, Plan & Discovery Sprint 0 Sprint cycles Test, Deploy, Stabilize, Operate & Optimize/Innovate

• Product Backlog Refinement

• Develop Master • Define and prioritize • Integration • End user
Plan • Test StrategyEpics and Features & additional training
Regression
including the Sprint Sprint Sprint Sprint Sprint
• Develop Project • Establish solution Cycle Cycle Cycle Cycle Cycle Test Cycles • User
test automation Acceptance
Management
approach architecture
Test
Plan
• Build out Product • Sprints include config, development, tech &
func unit test, user story acceptance by PO • Deployment
• Develop integrated Backlog (develop
Work Plan user stories)
Early pre-integration test • Pre-integration testing lays a solid
• Create • Develop Roadmap
Deliverables Log execution & SIT/UAT prep foundation for Integration Testing
• Execute pre-integration & • Validate the done user stories work
• Install and regression test together through iterative test
Configure Tools • Prepare for systems integration executions
and user acceptance test, • Allocate capacity for the development
• Train Project Staff including test approach, team to support pre-integration
scenarios, cases testing – e.g. defect triage/ fixing.
Data Integration (data cleansing, mock conversions) & Migration/Conversion
Project & Quality Management
Technology/Infrastructure
Release testing preparation and execution (integration, UAT)
Deployment planning and execution

Complete your strategy early and don't wait to prep forlines.

the Test phase.
© 2018. For information, contact Deloitte Touche Tohmatsu 27

Phase names and terminology may differ between methods and service
Activity: Class discussion – Preparing for release

As we close out our sprints and move into release what changes should we
prepare for?

- Maintain the agile mindset - Not doing agile ceremonies, cadences changing –
replacement for scrum of scrums?
- Changing roles (e.g., no more Scrum Master;
Product Owner might have different - Migration from scrum teams to more traditional
expectations) organization (functional, technical, change,
testing, etc.)
- Project Management activities will need to shift
- Processes to ensure continued stakeholder
- Will manage solely to a schedule and a plan engagement
for the remaining phases
- Being ready to conduct System Integration Test
- Traditional change control (SIT)
- Scope is locked down
- Defect management

28
 60mins

Additional topics

© 2019. For information, contact Deloitte Touche Tohmatsu 29

Leveraging a break and hardening sprint

© 2019. For information, contact Deloitte Touche Tohmatsu 30

Leveraging a break and hardening sprint
Considerations for building a master plan

Break Hardening/Stabilization
A planned break between sprints An additional sprint run at the completion of a set of
sprints; focuses on integration testing (ideally with
real data), defect resolution, and reducing technical
debt
Use: Use:

To take a break from sprinting to catch up – typically on Used to ensure overall solution quality prior to a
design work and/or PBR and planning release and provides an opportunity to optimize the
technical solution as the solution and design evolves

Recommendation: Recommendation:

• Consider a 1 week “break” mid-way through your planned • Closely manage expectations – many agile
sprints. Focus on eliminating open design issues, practitioners disagree about use of hardening
confirming adequate user stories are ready, and validating sprints – some see this as saying “I didn’t do it
MVP and effort estimates for ready stories. right the first time, so now I can fix it”
• Output should include refined backlog for remaining • Manage Pre-integration test cycles and System
sprints. Integration Test in IWP

© 2019. For information, contact Deloitte Touche Tohmatsu 31

Organizational Change Management (OCM)

© 2019. For information, contact Deloitte Touche Tohmatsu 32

 OCM guiding principles
Agile outside of software development – agile mindset still applies and there are OCM-
specific considerations about applying agile

An agile approach can be used for HC practitioners can be aligned with

many types of HC projects the scrum teams and/or be a separate
scrum team(s) that coordinates with
others via Scrum of Scrums (SoS)

OCM deliverables can be executed OCM approaches, strategies and

in an agile way, but are often planning deliverables are built upfront,
dependent on what features are executed during sprints and deployed
being developed/ released in releases

Find additional information on this topic in the Change agile playbook and in podcasts from The Leadership Lounge.
33
Applying agile techniques our way for OCM
This is a sample of OCM activities and deliverables

Release
Vision, Plan & Discovery Sprint 0 Sprint cycles Test, Deploy, Stabilize, Operate & Optimize/Innovate

• Initial Change Impact Sprint Sprint Sprint Sprint Sprint • Execute the Change Campaign
Cycle Cycle Cycle Cycle Cycle
Assessment • Deploy and Evaluate Learning
• Leadership Engagement
Approach • Develop communication materials and
• Organizational Change Execute Change Campaign
Management Strategy • Refine Change Impacts Assessment
• Business Advocate Network • Develop Learning Curriculum/
Approach Outlines/ Content Dev. Plan/
• Learning Approach Storyboard/ Courseware/ Simulations
OCM learning development is dependent upon working
solution components being available; development of
OCM learning deliverables may lag one sprint behind.

Basic OCM activities don’t change – but HOW you approach them and WHEN you complete them is different.
• Identify impacts for each sprint cycle and focus OCM effort only on those (e.g. assess only those stakeholders impacted in
the sprint cycle)
• Certain activities may be delayed until closer to the project’s end
• OCM activities must be prioritized and focused – there is less time to move from awareness to buy-in prior to each release
• ©Consider how OCM team members will integrate and ramped up on the project team – will they participate in sprint
2019. For information, contact Deloitte Touche Tohmatsu 34

reviews? Will they form their own scrum team?

Selected Roles and Responsibilities

© 2019. For information, contact Deloitte Touche Tohmatsu 35

 Roles and responsibilities
Balancing PMO & scrum team empowerment
Master and Release plans

The ceremonies to be Exact timing of ceremonies and

leveraged and framework for specific content discussed in each
each ceremony (guidelines, ceremony (time of day for most,
Scrum
instructions, etc.) PMO timing and duration for PBR)
team
Project-level artifacts like Manages Content of user stories and
DoD, DoR, computation of decides whether or not DoR and
burndown DoD are met for individual
user stories
Processes and supporting tool • Solution – stories, supporting
settings including: documentation, acceptance
• Product backlog columns and values criteria, MVP, tasks for each user
• User story refinement process story (tailored based upon
• Status reporting content and process standard)
• Standard sprint tasks • Effort estimates, capacity, velocity
• Data hygiene guidelines and reports • Status
• MVP and scope management processes

A scrum master is a servant leader. A functional lead tends to be a command and control role.
© 2019. For information, contact Deloitte Touche Tohmatsu 36

What training and procedures should be considered when the functional leads are the scrum masters?
Roles and responsibilities, continued
Balancing PMO & scrum team empowerment

Scrum
PMO
team

• In the beginning, the Scrum of Scrums focus on processes; as the project

progresses, they focus on cross team integrations
• Hold retrospective on ceremonies in Scrum of Scrums after each sprint to get
overall process and tool feedback
• Gather feedback on key artifacts (and possibly adjust) in Scrum of Scrums
retrospective
• The PMO has to do process development, deployment, training, and monitoring
© 2019. For information, contact Deloitte Touche Tohmatsu 37
Decomposing user stories

© 2019. For information, contact Deloitte Touche Tohmatsu 38

Splitting User Stories

• Understand and plan your epic/ feature/ user • It’s possible that a feature can be implemented in
story structure appropriately a single user story (example: minor change to
pre-configured/transfer solution process to
− Think of features as “big user stories”
maintain some master data field)
− Many projects will decompose epics and
• If a user story is too big:
features by business processes - projects that
use IndustryPrint might have L2 process (Epic) − Configuration story – decompose process into
and L3 process (Feature) sub-processes or groups of sub-processes to
allow guideline to be met
• The majority of the work done in sprints is focused
on developing working software – which means − Development story – decompose development
either configuration (if applicable) or coding object into portions of the required
(FWRICE objects, custom development, etc.) and functionality – might be required for very
testing of the developed working software complex objects
o Proof of Concept / shell
o + some functionality
o + remaining functionality

A user story should be small enough to be completed in half a sprint or less

© 2019. For information, contact Deloitte Touche Tohmatsu 39
 Agile
technique
Techniques for decomposing user stories (recap)
User stories need to be able to be completed in ½ a sprint

Most user stories require decomposition as business processes are explored and
new scenarios arise. Use these techniques to decompose user stories.
Find additional
information on this
topic in your method,
under the Define
Workflow Steps System Qualities
User Stories task, or
reference the User
Story Writing
Business Rule Variations Operations Guidelines
Development Aid.

Variations in Data Sub-process tasks Have a good sample

that others would
find useful?
Submit it here!
© 2019. For information, contact Deloitte Touche Tohmatsu 40
Examples of how to decompose user stories to the correct level

Split by Business Rule Variations

Instead of this… …try this.

As a utility manager  ... sort by zip code

I want to sort customers

 ... sort by home demographics

So that I can get different

demographics details  ... sort by energy consumption

Split by type of operation: Create Read Update Delete (CRUD)

Instead of this… …try this. … and further decomposition may be

needed
As a Starbucks
 … I can sign up  … manage  … reset my
Card user for an account security settings password

I want to manage  … I can edit my  … manage user  … update my

my account credits account settings settings profile info

So that I can buy  … I can cancel  … manage  … update my

coffee
© 2019. For information, contact Deloitte Touche Tohmatsu
my account notifications preferences 41
Status Reporting and Metrics

© 2019. For information, contact Deloitte Touche Tohmatsu 42

Status Reporting
Leverage metrics from both traditional and agile approaches

• Overall schedule status (monitor critical path and progress against baseline)
• Deliverables (monitor each contractual deliverable through agreed upon
process)
Traditional • Project Controls (monitor issues, risks, changes, decisions, and senior action
items)
• Testing and defect management

• Burndown
Agile • Cumulative Flow
• Impediment List

• Roadmap capacity vs work (for all sprint cycles)

Internal • Data hygiene (monitor adherence to processes and accuracy of data in
tools)

© 2019. For information, contact Deloitte Touche Tohmatsu 43

 Status report sample
Overall Status: Status of Stories Under Refinement (PBR)
and In Build & Test

Completed in Past
Total Under Refinement Approved Backlog In Current Sprint
Teams Owner Sprints
# Δ  # Δ  % # Δ  % # Δ  % # Δ %
<SM & PO
Team A 65 -1 13 24 -1 13 37% 4 0 0 6% 18 0 0 28% 19 0 29%
names>
<SM & PO
Team B 81 0 4 0 0 0 0% 10 0 4 12% 10 0 0 12% 61 0 75%
names>
<SM & PO
Team C 226 1 6 12 0 5 5% 31 2 1 14% 35 -1 0 15% 148 0 65%
names>
<SM & PO
Team D 228 -1 17 59 -2 17 26% 7 2 0 3% 39 -1 0 17% 123 0 54%
names>
<SM & PO
Team E 216 2 18 49 2 15 23% 19 0 3 9% 42 0 0 19% 106 0 49%
names>
<SM & PO
Team F 191 0 0 1 0 0 1% 53 3 0 28% 31 -3 0 16% 106 0 55%
names>
<SM & PO
Team G 81 0 22 25 0 3 31% 11 0 0 14% 41 0 19 51% 4 0 5%
names>
<SM & PO
Team H 53 0 1 52 0 1 98% 0 0 0 0% 1 0 0 2% 0 0 0%
names>
Workstream-I Build Stories
1141 1 81 222 -1 54 19% 135 7 8 12% 217 -5 19 19% 567 0 50%
Sub-total:
Team X <SM & PO names> 147 0 10 11 0 8 7% 9 0 0 6% 15 0 2 10% 112 0 76%
Team Y <SM & PO names> 200 0 14 7 0 2 4% 6 0 6 3% 33 0 6 17% 154 0 77%
Team Z <SM & PO names> 343 0 45 97 0 39 28% 16 0 2 5% 78 0 4 23% 152 0 44%
Workstream-II Build Stories
690 0 69 115 0 49 17% 31 0 8 4% 126 0 12 18% 418 0 61%
Sub-total:
Build Stories Total: 1831 1 150 337 -1 103 18% 166 7 16 9% 343 -5 31 19% 985 0 54%

© 2019. For information, contact Deloitte Touche Tohmatsu # Count of stories Δ Delta change from previous report  Blocked stories % Percentage of total 44
 Status report sample, continued
Under Refinement status: Status of Stories in future sprints
that are pending Definition of Ready (DOR)

Under Refinement
Total New In Progress Ready for Tech Review Ready for Sign-off Rework
Sprint Team # Δ  # Δ  % # Δ  % # Δ  % # Δ  % # Δ  %
Team A 24 -1 13 0 -1 0 0% 16 -2 9 67% 8 2 4 33% 0 0 0 0% 0 0 0 0%
Team B 0 0 0 0 0 0 0% 0 0 0 0% 0 0 0 0% 0 0 0 0% 0 0 0 0%
Team C 12 0 5 1 0 1 8% 0 0 0 0% 9 0 4 75% 2 0 0 17% 0 0 0 0%
Team D 59 -2 17 2 0 0 3% 41 1 7 69% 11 -6 10 19% 5 3 0 8% 0 0 0 0%
Team E 49 2 15 1 0 0 2% 12 0 4 24% 19 -1 11 39% 17 3 0 35% 0 0 0 0%
Team F 1 0 0 0 0 0 0% 1 0 0 100% 0 0 0 0% 0 0 0 0% 0 0 0 0%
Team G 25 0 3 1 0 0 4% 20 0 2 80% 2 0 1 8% 2 0 0 8% 0 0 0 0%
Team H 52 0 1 51 0 0 98% 1 0 1 2% 0 0 0 0% 0 0 0 0% 0 0 0 0%
Workstream-I Build Stories Sub-
222 -1 54 56 -1 1 25% 91 -1 23 41% 49 -5 30 22% 26 6 0 12% 0 0 0 0%
total:
Team X 11 0 8 1 0 0 9% 0 0 0 0% 10 0 8 91% 0 0 0 0% 0 0 0 0%
Team Y 7 0 2 1 0 0 14% 2 0 1 29% 2 -1 0 29% 2 1 1 29% 0 0 0 0%
Team Z 97 0 39 3 -2 1 3% 31 -1 21 32% 54 -1 17 56% 9 4 0 9% 0 0 0 0%
Workstream-II Build Stories Sub-
115 0 49 5 -2 1 4% 33 -1 22 29% 66 -2 25 57% 11 5 1 10% 0 0 0 0%
total:
Build Stories Total: 337 -1 103 61 -3 2 18% 124 -2 45 37% 115 -7 55 34% 37 11 1 11% 0 0 0 0%

© 2019. For information, contact Deloitte Touche Tohmatsu # Count of stories Δ Delta change from previous report  Blocked stories % Percentage of total 45
 Status report sample, continued
Current Sprint summary status: Days remaining until end
of sprint: <count of remaining days>

Build & Test Progress

Test Cases
Total Under Refinement Not Started In Development In FUT In BAT Approved
Developed
Sprint Team # Δ  # Δ % # Δ  % # Δ  % # Δ  % # Δ  % # Δ  % # Δ %
Team A 18 0 0 18 0 100% 0 0 0 0% 0 -1 0 0% 0 0 0 0% 0 0 0 0% 0 -3 0 0% 18 4 100%
Team B 10 0 0 10 0 100% 0 0 0 0% 0 0 0 0% 0 0 0 0% 1 -1 0 10% 1 0 0 10% 8 1 80%
Team C 35 -1 0 35 -1 100% 0 0 0 0% 0 0 0 0% 0 0 0 0% 0 -4 0 0% 0 -7 0 0% 35 10 100%
Team D 39 -1 0 39 1 100% 0 0 0 0% 0 0 0 0% 0 0 0 0% 1 -3 0 3% 0 -2 0 0% 38 4 97%
Team E 42 0 0 42 0 100% 0 0 0 0% 0 0 0 0% 0 0 0 0% 0 -1 0 0% 0 -2 0 0% 42 3 100%
Team F 31 -3 0 31 3 100% 0 0 0 0% 0 -6 0 0% 0 0 0 0% 0 0 0 0% 0 -4 0 0% 31 7 100%
Team G 41 0 19 5 1 12% 0 0 0 0% 30 1 17 73% 2 -3 2 5% 0 -3 0 0% 0 0 0 0% 9 5 22%
Team H 1 0 0 0 0 0% 1 0 0 100% 0 0 0 0% 0 0 0 0% 0 0 0 0% 0 0 0 0% 0 0 0%
Workstream-I Build Stories
217 -5 19 180 4 83% 1 0 0 0% 30 -6 17 14% 2 -3 2 1% 2 -12 0 1% 1 -18 0 0% 181 34 83%
Sub-total:
Team X 15 0 2 13 0 87% 0 0 0 0% 1 0 1 7% 1 0 1 7% 0 0 0 0% 0 0 0 0% 13 0 87%
Team Y 33 0 6 29 1 88% 3 0 3 9% 0 0 0 0% 1 -2 1 3% 2 -4 0 6% 4 -6 2 12% 23 12 70%
Team Z 78 0 4 76 0 97% 0 0 0 0% 0 0 0 0% 1 0 1 1% 3 0 3 4% 4 -1 0 5% 70 1 90%
Workstream-II Build Stories
126 0 12 118 1 94% 3 0 3 2% 1 0 1 1% 3 -2 3 2% 5 -4 3 4% 8 -7 2 6% 106 13 84%
Sub-total:
Build Stories Total: 343 -5 31 298 5 87% 4 0 3 1% 31 -6 18 9% 5 -5 5 1% 7 -16 3 2% 9 -25 2 3% 287 47 84%

© 2019. For information, contact Deloitte Touche Tohmatsu # Count of stories Δ Delta change from previous report  Blocked stories % Percentage of total 46
 Status report sample, continued
Scrum team Build & Test status

User
Stories:
ID Story Title
Under
Refineme
Not
In Dev In FUT In BAT Approved Blocked Reason
Started
nt
81663Tax exemption Certs 
81672Tax exemption categories 
81673Tax indirect--contracting entity 
81678indirect taxes--Exemption before invoices 
81665Indirect tax--searching exempt certificates 
81686Run and analyze intercompany reconciliation report 
81664AR Reconciliation to Product Revenue 
81706Revenue by Location 
81709Indirect tax—intercompany 
81675indirect tax--date of certificate 
70691indirect tax--tax register   Unsuccessful Test Demo – push to next sprint
70080Ability to report VAT by VAT group   Reporting for VAT group needs additional fields
70075Bad debts 
66814Transfer pricing Invoice Tax Calculation 
66815Journal Entry Approval Workflow 
66812Month End Labor Accrual 
Open Defects:
AgM
ALM ID Defect Title
ID
11649 276 Missing Fields and headers incorrect.

© 2019. For information, contact Deloitte Touche Tohmatsu 47

 Effort vs Capacity for Sprint 4 through Sprint 7
Status report sample, continued (hours)
Effort vs. Capacity Team H
Team G
Team E
Team C
Team A
Team Z
Team Y
Team X

0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000

Original Estimate Capacity

Column
Labels
Sprint 4 Sprint 5 Sprint 6 Sprint 7 Total Total Total
Count: Original Capacity:
Estimate:
Row Labels Count: Original Capacity: Count: Original Capacity: Count: Original Capacity: Count: Original Capacity:
Estimate: Estimate: Estimate: Estimate:
Worksteam I
Team X 29 323 408 5 189 389 22 267 384 1 10 391 57 789 1,572
Team Y 52 609 556 34 365 437 1 1 449 8 75 461 95 1,050 1,903
Team Z 69 678 851 84 757 785 81 862 956 32 364 715 266 2,661 3,307
Worksteam
II
Team A 46 387 364 34 297 280 32 300 294 18 169 266 130 1,153 1,204
Team B 9 130 0 40 176 0 6 118 0 2 0 0 57 424 0
Team C 39 625 555 53 647 616 55 708 672 19 265 616 166 2,245 2,459
Team D 23 106 225 17 149 225 11 86 225 1 7 225 52 348 900
Team E 38 530 535 48 570 637 51 650 679 13 315 693 150 2,065 2,544
Team G 19 189 180 23 296 238 23 284 266 0 0 210 65 769 894
Team H 36 372 390 51 388 350 36 305 322 0 0 350 123 1,065 1,412
Grand Total 360 3,949 4,064 389 3,834 3,957 318 3,581 4,247 94 1,205 3,927 1,161 12,569 16,195
© 2019. For information, contact Deloitte Touche Tohmatsu 48
Scaled Agile Framework (SAFe)

© 2019. For information, contact Deloitte Touche Tohmatsu 49

Scaled Agile Framework (SAFe) 5.0
We have experience and
training available

SAFe® is an online freely

revealed knowledge base of
proven, integrated patterns for
implementing Lean-Agile
development. It provides
comprehensive guidance for
work at the Portfolio, Program,
and Team Levels.

Don’t experiment with SAFe if you’re not an expert in agile.

For more information on SAFe training, contact ServiceDeliveryExcellence@deloitte.com
© 2019. For information, contact Deloitte Touche Tohmatsu 50
DevOps

© 2019. For information, contact Deloitte Touche Tohmatsu 51

 What is DevOps?
DevOps is

…the streamlining of the activities surrounding IT

solution development (dev) and IT operations
(ops).
… an effort to bring Dev and Ops together so
… Agile applied to that they deliver with quality and stability
Development and Operations
… the practice of operations and
development engineers participating
… a movement? A new
together in the entire service lifecycle,
process ? A technology? A
from design through the development
job title? No, it is just a
process to production support
way of thinking?
DevOps is the outcome of applying the
most trusted principles from the domain
of physical manufacturing and leadership
to the IT value stream. - Gene Kim

A way of thinking and acting that builds on Agile and Lean Thinking to bring
additional speed to deliver technology with greater stability, quality and
security.
52
Where do agile and DevOps fit in the software delivery lifecycle?
DevOps practices extend agile practices and accelerate later phases of a project.

Takes business ideas through to the

AGILE DEVELOPMENT
end of software development

Design & Build &

Ideation Develop Test Release Operate
Requirement Deploy

DEVOPS DEVELOPMENT-RELEASE PROCESS

Provisioning Shifts testing and release earlier Automated
dynamic in the process to create value through testing
environments delivery to the end user earlier

Continuous Continuous Continuous

integration testing monitoring

© 2019. For information, contact Deloitte Touche Tohmatsu 53

Summary
Agile and DevOps are ways of working, mindsets and cultures. The benefits of a
combined approach delivers increased agility to deliver valued technology in pace with
the business
Agile DevOps
“breaks down walls between Development & Business” “breaks down walls between Development & Operations”
Create value fast Deliver value fast with quality and stability

The benefits of agile thinking … The benefits of DevOps thinking …

Prioritization of features that drives the most + Optimizes end-to-end technology value
business value stream

Embrace change to keep pace with dynamic + Continuous validation of quality from the
business environments point of creation to operation

Creates software teams with deeper business + Software/infrastructure delivery automation

domain expertise, less time to get on target reduces manual rework, raises quality

Shared understanding/ownership of the user + Work in progress is more visible to better

experience, expected business outcome understand constraints, balance workloads

1+ 1 = 3 54
Good reads
External resources

Don’t Know What I Want, But Iterative and

I Know How to Get It – Jeff Incremental video
Patton

Turn the Ship

Around
(and YouTube
video) The Backwards Brain Bicycle (cognitive bias) –
Top 20 Agile Blogs
how challenging is it to rewire our brains, to
apply the Agile mindset vs. what we are used to
© 2019. For information, contact Deloitte Touche Tohmatsu 55
About Deloitte
Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee (“DTTL”), its network of member firms, and their related entities. DTTL and each of its member firms
are legally separate and independent entities. DTTL (also referred to as “Deloitte Global”) does not provide services to clients. In the United States, Deloitte refers to one or more of the US member firms of DTTL, their
related entities that operate using the “Deloitte” name in the United States and their respective affiliates. Certain services may not be available to attest clients under the rules and regulations of public accounting.
Please see www.deloitte.com/about to learn more about our global network of member firms.

Copyright © 2020 Deloitte Development LLC. All rights reserved.