Agile 101- Knowledge Sharing

Agenda
What and Why? How?
1. What is Agile? 1. Common language
2. Why Agile 2. Sprint Execution
3. Agile Principles
4. Adopting Agile
5. Scrum Introduction
6. Product Backlog

4 444 :
Documents Documents Unverified Code Software
Agile is…about delivering value

1. Agile is a group of methods in which requirements and solutions evolve through collaboration with self organizing,
cross-functional teams
2. There are dozens of methods.
3. There is one Agile spirit – It is fundamentally empirical & iterative
4. Feb. 2001 Agile Manifesto was created by 17 software development thought leaders in Snowbird Utah
5. In most Agile methods, like Agile Scrum the product progresses in highly iterative, predictable cadence - a series of
time-boxed “sprints,” which are part of a release plan
6. Requirements are captured as items in a list of “product backlog” and scheduled for work in priority order based on
greatest value
7. Embrace change/emergence as it is impossible to know all requirements in advance
Agile is…about delivering value

• Agile methods:
• Scrum
• Extreme Programming
• Adaptive Software Development (ASD)
• Dynamic System Development
Method (DSDM)
• …
• Agile Alliance
(www.agilealliance.org)
• A non-profit organization promotes
agile development
 Constraints Features Cost Schedule

+ Transform
Systems
of Innovation -
Exploratory

Governance
More
application of More application of Systems of
Grow
Change

Waterfall Agile Approach Differentiation

Approach

Traditional

- +
Systems of
Run
Record

Predictive/Defined Empirical “Bimodal IT: How to be Digitally Agile

The defined process control model Empirical predictions are Without Making a Mess”
requires that every piece of work derived from experiment and Maria Mesaglio and Simon Mingay,
be completely understood. observation rather than theory. Gartner
A paradigm shift in delivery thinking: Changing from a
plan to a value driven approach
• Traditionally features (scope) are defined in detail at the beginning of a project (RICEF, process, modules),
estimate will drive the cost and schedule estimates. Plan driven
• Agile has flipped the triangle; basing on a fix cost and schedule. Agile approach and tool will help clients
to define the most valuable solution to be delivered with that team, in that time. Value driven

Waterfall Agile
The plan creates cost/schedule The vision creates feature
estimates estimates

Constraints Features Cost Schedule

Value/
Vision
Driven
Plan Driven

Estimates Cost Schedule Features

Single, big-bang versus continuous flow delivery
• In order to deliver continuous SAP functionality we embrace the concept of Minimum Viable Product. The
goal of MVP is to identify the smallest increment of software that the Business would immediately adopt.
We use this to get the business hooked. The objective is to immediately start realizing the value from this
small “core”, and then expand.

Pitfalls of Traditional Waterfall: Agile Principles:

• Constant changes to the original budget • Continuous delivery of SAP functionality in small fast
• Overly complex, comprehensive solution increments
• Scope management (critical capabilities vs. nice to have) • Value driven plan over initial list of requirements
• Managing many deliverables • Early, iterative and frequent demonstration of results
• Lack of flexibility to change • Ongoing Collaboration between IT , business and
• Issues identified late in the process partners
• Delayed business adoption
Value

MVP

Value
MVP

MVP Risk of failure

MVP
Time Value Delivered Time
 Modern Engineering
Increased accountability
Increase Engineering Capacity

Combined
Engineering

Culture (All for one. One for all.)

One team. One backlog. Single
DevOps Break down remaining barriers
OneIT VSO Backlog
Leverage common tools (GIT, etc.)
Customer
Value and
Experience

Service Feature crew

Common Taxonomy
Maturity Agile Iterative releases
Common Benchmarking Model
Telemetry

LiveSite

Data Analytics
End-to-end experience
Fast feedback loops
Agile Benefits Apply to All that Adopt

Every Agile iteration enables teams to:

1. See & refine requirements based

on new knowledge:
✓ Better business alignment
✓ Easier to adjust to changing
priorities
2. Deliver incremental value sooner
✓ Faster time to market
✓ More innovative products
Agile ‘sprinting’ values Business Value
Sprint planned empirically High productivity and better results sprint over sprint
Hyper team focus Start early with just enough data
Inspect, adapt Better quality and opportunity for learning and innovation
Small product increment release more often for user input Reduced risks for integration and alignment with user needs
Why Agile?

Push to Agile Pull to Agile

from Traditional… We want…
• Locked scope and schedule leaves • Happy customers
no flexibility nor buffer • Value sooner
• Takes too long to get to market • Higher quality
• Misses key requirements • Reduced risk
• Find defects too late in the cycle • First in the market
• Over budget and behind schedule • Be the market innovator
• Quality issues • Deeper, trusted relationships
What Agile is NOT
1. The term Agile has become fatigued or over/misused
2. In some organizations it has negative connotations – synonymous with:
1. Developer-centric
2. No documentation
3. No written requirements
4. No rules nor structure
5. Build and release ‘at will’
3. The term “Agile” sometimes conjures up a nebulous end-state that
seems unachievable or unpractical
Agile Manifesto
We are uncovering better ways of developing software
by doing it and helping others do it

Through this work we have come to value

Individuals and Interactions over Processes and Tools

Working Software over Comprehensive Documentation
Customer Collaboration over Contract Negotiation
Responding to Change over Following a Plan

www.agilemanifesto.org
Agile Principles….
1. The most efficient and effective method of 7. At regular intervals, the team reflects on how to
conveying information to and within a development become more effective, then tunes and adjusts its
team is face-to-face conversation. behavior accordingly.
2. Working software is the primary measure of 8. Our highest priority is to satisfy the customer
progress. through early and continuous delivery of valuable
software.
3. Agile processes promote sustainable development.
9. Welcome changing requirements, even late in
The sponsors, developers, and users should be able development. Agile processes harness change for the
to maintain a constant pace indefinitely. customer's competitive advantage.
4. Continuous attention to technical excellence and 10. Deliver working software frequently, from a couple of
good design enhances agility. weeks to a couple of months, with a preference to the
shorter timescale.
5. Simplicity--the art of maximizing the amount of work
not done--is essential. 11. Business people and developers must work together
daily throughout the project.
6. The best architectures, requirements, and designs
emerge from self-organizing teams. 12. Build projects around motivated individuals. Give
them the environment and support they need, and
trust them to get the job done.
Agile : Get to Market & Make Money Sooner

Value
Value delivered

delivered
Value
delivered

Value
delivered

risk
Value
delivered

Time
Agile Methods
• "Agile Development" is an umbrella term for
several iterative and incremental software
development methodologies

• Each agile methods is lightweight and unique in

Practice, they all share a common vision and
core values (see the Agile Manifesto)

• They all fundamentally incorporate iteration and

the continuous feedback that it provides to
successively refine and deliver a software system

• They all focus on empowering people to

collaborate and make decisions together quickly
and effectively.
SCRUM Introduction
Scrum Introduction
Scrum is a process framework that has
Scrum which is an iterative project been used to manage complex product development since
management methodology that breaks the early 1990s. Scrum is not a process or a technique for
project work into time-boxed units of work building products; rather, it is a framework within which
you can employ various processes and techniques
known as “sprints.” Scrum focuses on
Scrum framework consists of Scrum Teams and their
frequent, direct communication, accountability associated roles, events, artifacts, and
and visibility to help project teams succeed. rules.

1. Why Agile Scrum?

Scrum Theory
2. Scrum Roles Scrum is founded on empirical process control theory, or
3. Team Spirit empiricism. Empiricism asserts that knowledge comes
from experience and making decisions based on what is
4. Core Activities and Artifacts known. Scrum employs an iterative, incremental
approach to optimize predictability and control risk.
5. Agile Scrum Cadence and
Ceremonies
Scrum Introduction

Three pillars uphold every implementation of empirical process control:

• Transparency
Aspects of the process must be visible to those responsible for the outcome.
• Inspection
• Adaptation
Aspects of a process deviate outside acceptable
limits
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective
Agile Scrum Key Concepts
Empirical approach…
• Deliver small,
testable increments
• Development team
inspects and adapts
daily
• “Customer” inspects
and adapts each
iteration

More concepts…
• Commitment focus
• Self managed teams
• Scrum doesn’t prescribe
• It depends on Common Sense!
Video
Chet Rong – Team Structure
Agile Scrum Roles

Product Owner Scrum Master

• Vision • Team Player & Communicator
• Responsible for managing the Product Backlog • Remove Impediments
• Prioritization & Negotiation • Facilitate empowerment of Scrum Team
• Respectful of Team’s ability • Improve engineering practice & tools
• Decision Making

Scrum Team
• 5 to 9 people
• Consists of a Product Owner, the Development Chickens and Pigs
Team, and a Scrum Master.
• Select Sprint backlog & Complete
• Self-organizing & managing
Agile Scrum Meetings
Sprint Planning
• At the beginning of each Sprint, the Product Owner and
team hold a Sprint Planning Meeting • Daily, same time and place, the Scrum Development
• Outcome is committed Product Backlog Items (PBIs) Team members spend a total of 15 minutes reporting
Sprint Planning Meeting and subordinate Sprint Tasks to each other. Each team member summarizes what he
• The team “pulls” work from the Product Backlog to the did the previous day, what he will do today, and what
Sprint Backlog. impediments he faces.
• Time-For 30-day Sprint is eight hours, reduced • Current Sprint Task List, a Sprint Burndown Chart, and
proportionally for a shorter Sprint. an Impediments List

Sprint Review
• After Sprint execution, the team holds a Sprint Review
• Each sprint ends with a retrospective. At this meeting,
Meeting to demonstrate a working product increment
the team reflects on its own process. They inspect
to the Product Owner and everyone else who is
their behaviour and take action to adapt it for future
interested. This is a four-hour time-boxed meeting for
Sprints. three-hour time-boxed meeting
one-month Sprints.The meeting should feature a live • Set the stage, gather data, generate insights, decide
demonstration, not a report. what to do, close the retrospective. The Art of Focused
• Product Owner reviews the commitments made at the Conversations, breaks the process into similar steps:
Sprint Planning Meeting and declares which items he Objective, reflective, interpretive, and decisional
now considers done. (ORID).
Agile Scrum Artifacts
Backlogs
Product Backlog
• All work that remains to be done
• Prioritized and Initially sized
• Includes both well-defined work and work requiring more definition
• Includes both feature and non-feature work
Sprint Backlog
• Detail work items estimated by team
• Remember to include “inspection” tasks to ensure quality
Agile Scrum Artifacts
Product Backlog
• An ordered list of everything that might be needed in • The Sprint Backlog is the set of Product Backlog items
the product and is the single source of requirements for selected for the Sprint, plus a plan for delivering the
any changes to be made to the product product Increment and realizing the Sprint Goal
• Lists all features, functions, requirements, enhancements,
and fixes that constitute the changes to be made to the
product in future releases. Product Backlog items have
the attributes of a description, order, estimate and value.

Sprint Task
• At any point in time, the total work remaining to reach
a goal can be summed. The Product Owner tracks this
total work remaining at least every Sprint Review.
Agile Scrum Artifacts
Scrum Artifacts include the –
1.Product Backlog, 2. Sprint Backlog 3. the Release Burndown, and 4. the Sprint Burndown.
Agile Team Spirit

Team Characteristic Description

Longevity Remain together through an iteration and ideally a release and beyond
Cross-functionally sufficient No ‘roles’ but all skills needed to tackle a meaningful slice of functionality
Self-organizing Team decides how to best meet sprint goals
Self-managing Every team member is responsible for managing the team
Right-sized Ideally 7 +/- 2 team members to communicate well & be cross-functional
Service to the Team Willingness to serve beyond their specialty to ‘get to done’
All-for-1; 1-for-All Start & finish together -> no one is done until the work is done
Focused Members dedicated full-time for the sprint laser-focused on sprint priorities and
delivering customer value
Rich collaboration Full communication needed to problem solve, innovate & develop true synergy
Introduction to Sizing User Stories
1. Humans struggle to size with
specifics such as how much a
St. Bernard dog weighs vs. a
Labrador vs. a Chihuahua?

2. Yet we can say relative to each

other their respective size

3. In Agile, one common sizing

method is to apply the same
relative sizing thinking to
User Stories
Guidance to Sizing User Stories
1. Keep estimates manageable
1. Try to keep the most important estimates within about one order of magnitude, such as from 1-10.
2. There are studies that have shown humans are pretty good across one order of magnitude, but beyond
that, we are pretty bad.

2. Estimate in relative terms.

1. Estimate in relative terms rather than absolute terms.
Instead of saying, "This will take five days," say, "This thing will take about as long as that thing."
2. Relative estimating is often more accurate, teams can do it more quickly.
3. With relative estimating, the team does not need to think of all of the sub-steps and estimate each and
then add them up. They only need to find something similar and use the same estimate.
4. The next step is to use velocity to determine how long each of those things actually takes. Using data
from at least 3-5 sprints helps get get a predictable range.

3. Bucket Backlog items by story size

1. This saves times in estimating meetings by removing the pressure to be perfect.
2. By removing pressure, it also helps get team members to engage in the process.
Agile IT Enterprise Organization in VSO
VSO Item Definition Agile
Work Item and Guidance Entity

•Overarching objectives at the CIO-level

Initiatives representing multi-year efforts.

Backlog
•Bold, broad goals whose efforts are
Epics > 6 months

•Incremental with clear business values

Features defined that span multiple Sprints

User •Effort deliverable within a Sprint

with clear definition of done and
Stories acceptance criteria

Sprint
Plan(s)
•Effort completed
Tasks less than a day
Video
Chet Rong – Specifications
User Story Format

Example Counter Example

As a student, I can find my grades online so Design an application for online grades
that I don’t have to wait until the next day to
know whether I passed

Acceptance Criteria
• Student grades are available online
• Online grades are posted within 12 hours
• Student can find only their grades
What Makes a Good User Story?

I 1. Independent
N 2. Negotiable
V 3. Valuable
E 4. Estimable
S 5. Sized appropriately
T 6. Testable
User Story Types

Feature Non-Functional Spike

(aka functional)

• Most common story type • Technical investments to • Can be technical

• Adding a product, support features investments (i.e. security
deliverable or service for • Refactoring audit, upgrades)
the end-user/ customer • Upgrades • Time-boxed research
• Ace Reviews
Defining a Sprint
Scrum Definition
• N days long (team defines iteration) with specific goal(s)
• Product owner and team collaborate to decide on targeted Product Backlog for the Sprint
• Scrum Team determines methods to meet goal
• New items cannot be added to the Sprint Backlog once plan is committed
• Ends with a demonstration of the software

An example
• Sprints align with calendar months – with the following rules:
• Sprints end with a demonstration on the last Thursday of the month
• Sprint planning also happens on the last Thursday of the month
• The next sprint starts immediately after the planning session
• All teams are on the same sprint schedule
VIDEO

Sprint Planning
Sprint Planning Meeting

Product Owner & Scrum

Business Team define goal & select
targeted PBIs
Priorities Sprint prioritization
• Select sprint goal & theme
• Review targeted PBIs Sprint goal
Customer
Feedback

Prioritized Sprint planning

Product • Decide how to achieve sprint goal
Backlog • Create sprint backlog tasks Sprint backlog
• Estimate tasks
• Team votes on Sprint Commitment Scrum Team works
Team together to define the
sprint backlog
Capacity
Video
• Chet Rong – Daily Stand-up
Sprint Burn Down and Daily
Stand Up
• A graph which shows progress for the sprint
• Reviewed at Daily Scrum meeting

Daily Scrum Standup– 3 questions

• What did you work on yesterday?
• What are you working on today?
• Is anything blocking your work? -> Impediment backlog

Example
• Scrum Team maintains detailed sprint burn down using Post-
It notes or TFS
• Scrum Team is responsible for keeping it up to date – daily!
• Overall Sprint Burn down reported on a daily basis
Product Burn down
Video
Chet Rong - Retrospectives
Sprint Review & Retrospective

Review & Demo Retrospective

• Team presents to customers and other Improves the process
interested parties (management) • Identify & order items that went well and
• Product Owner acceptance what needs improvement
• Focus on working software • Pick one item to improve & create plan
• Forms basis for planning of next Sprint • Start with the status of the previous item
for improvement
• Done with the team
Key Aspects of Successful Scrum Teams

Clear Roles & Responsibilities

• Single role per person especially for Product Owner and Scrum Master
• Single Scrum Team per person

Ranked Priorities
• Sprint plans clearly designate ranked priorities
• Items of greatest priority are of greatest value to the business and/or users

Predictable Cadence
• Set a standard schedule and stick to it
• Establish teams and give them time to figure things out and get a rhythm

Collaborative Planning
• The ENTIRE Scrum Team plans together
• The team takes the time needed to plan the full sprint commitment
• Team is planned to or UNDER capacity
Definition of Done

• Checklist of valuable activities required to deliver value

• Reporting mechanism for team members
• Informed by reality
• Auditable

Release
•All agreed Sprints done
• All Compliance items are complete &
Sprint signed off
• All agreed upon stories • Release notes documented
are done • Deployment scripts documented &
• Risks & Dependencies tested
reviewed & updated • Deployed in productions
Story • Review & Retrospective • Product Owner Sign-off
• Performance Testing complete held & documented
• Integration Testing complete
• All tasks are done
• No pri 1 or 2 defects
• Automated Acceptance tests
Task • If SOX Story, the sign-off is
complete
• Implemented
• Unit tested
• Automated tests
• Wiki notes updated
• CI server runs all tests
Credits & Sources
1. Guiding Principles of the Agile Manifesto
www.agilemanifesto.org
2. Guiding Principle of Lean Manufacturing
3. The Toyota Way (book)
4. IP and advice from the Scaled Agile Institute
www.scaledagileframework.org
5. IP and consultation from Net Objectives
www.netobjectives.com
ERP/SAP & Agile
 Agile for SAP
&
Bimodal Engineering
Common talks/perception about Agile in SAP
• Does Agile really work on SAP ? We can't expose our core processes to this kind of risk
How to balance system stability, Integrity with the need for agility and innovation.

• Stability and resilience are key Agile adds risk. SAP systems have been built on stability and resilience. How to
manage Pace Layering – System of records, System of differentiation, system on Innovation

• Compliance and Governance Documentation and approvals to support the SOX need for System of record platform

• Process Integration and dependencies SAP can’t be broken down into smaller chunks

• SAP projects are large projects /Greenfield Implementation Smaller chunks reduce the risk. Can
Integrated Business process be effectively managed in smaller chunks?

• Outsourced and off-shore teams Agile work better for co-located team

• A hybrid Waterfall + Agile approach is best

• SAP folks have an attachment to Waterfall development Change resistance

Application development vs. SAP( ERP)
• Feature vs. Process – Integration and dependency
• Coding vs. Configuration – SAP configuration is NOT
programming
• Not necessarily moving code/config to prod after every
sprint - When the code/config does ship, it is often
bundled with many other sprints, and if something doesn’t
work, it can be difficult to isolate
• Complexity of business requirement
• Integrated end-to-end business process that are difficult to
decompose
What Agile is NOT
• The term Agile has become fatigued or over/misused
• In some organizations it has negative connotations – synonymous
with:
• Developer-centric
• No documentation
• No written requirements
• No rules nor structure
• Build and release ‘at will’

• The term “Agile” sometimes conjures up a nebulous end-state that

seems unachievable or unpractical
Adopting Agile in SAP -Addressing the challenges
Individuals and Interactions over Processes and Tools
Working Software over Comprehensive Documentation
Customer Collaboration over Contract Negotiation
Responding to Change over Following a Plan

✓ Bi-Modal Approach Define criteria .Select the right project for Agile and demonstrate success
• Product backlog- Process Level vs Feature Level, Process level decomposition , Story Mapping and
Stories. Business vs SAP User Stories ? Who is the Product Owner?
✓ Test automation including automation of Compliance activities .
✓ Environment challenges . Continue integration and deployment ,testing in production like systems
✓ Elevated Governance and release management process to manage dependency and risk
✓ Release and production support – Agile enabled by “DevOps” best practices: Implementation
and Operations fully integrated for frequent release into production
✓ Non- Functional requirement – finds a way to include and manage technical debt. Include FMEA
in designing - User stories : Feature , Non-functional , Spikes
✓ Measure and Manage IT Debt- including security debt,
✓ Strictly enforced coding guidelines
Adopting Agile in SAP -Addressing the challenges
Project Characteristic - Bimodal Criteria ( Example)

Team and Org readiness Environment

Project details
resources and interfaces and system

•Requirement def and clarity

•Size and location
•Process integration •Training •Test validation and
•Skills- business and technical
•Dependencies -Interfacing •Stakeholders involvement automation
systems and buy-in •Dependency tracking and
•Compliance and security •End user impacts controls
needs •Version and release
•Build on existing capability or management
First time capability
/technology
Bimodal IT
Having two Modes of IT, each designed to develop and deliver information-and technology-intensive services in its own way.
• Mode 1 is traditional, emphasizing safety and accuracy.
• Mode 2 is exploratory, emphasizing agility and speed.

Constraints Features Cost Schedule

+ Transform
Systems
of Innovation -
Exploratory

Governance
More
application of More application of Systems of
Grow
Change

Waterfall Agile Approach Differentiation

Approach

Traditional

- +
Systems of
Run
Record

Predictive/Defined Empirical “Bimodal IT: How to be Digitally Agile

The defined process control model Empirical predictions are Without Making a Mess”
requires that every piece of work derived from experiment and Maria Mesaglio and Simon Mingay,
be completely understood. observation rather than theory. Gartner
Bimodal IT
• Mode 1 focuses on predictability and has a
goal of stability.
• It is best used where requirements are well-
understood in advance, and can be identified by a
process of analysis.
• It includes the necessary investment in renovating
and opening up the legacy environment.

• Mode 2 is exploratory.
• In this case, the requirements are not well-
understood in advance.
• Mode 2 is best-suited for areas where an
organization cannot make an accurate, detailed,
predefined plan because not enough is known about
the area. Mode 2 efforts don't presume to predict the
future, but allow the future to reveal itself in small
pieces.
• This work often begins with a hypothesis that is
proven, disproven or evolves during a process
typically involving short iterations/projects.
Why SAP environment is Bimodal

• Complexity • Governance
• 3rd party, integrated platform • SOX system of record
(NOT a system); customized • Heavy controls particularly in
• Release cadence with limited transactional systems
downtime windows • Audit target
• Lack of service isolation • Some heavy controls groups
• Platform maintenance & (Treasury, Payroll) want
health efforts Waterfall
 An IT View of Environment Shifts
LOB & IT 50%
New projects controlled by LOB
Digital Business and increasing

System of innovation

System of differentiation

System of record
IT-led 50%
projects Controlled by IT
“Keep the lights on” and decreasing

From Gartner
 Additional Slides
SAP Activate/Accelerators
SCRUM Master

▪ Ensures that the team is fully functional, productive and has focus.
▪ Enables close cooperation across all roles and functions and removes barriers.
▪ Shields the team from external interferences.
▪ Ensures that the process is followed. Invites to daily standup meeting, iteration review and planning
meetings.
▪ Ensures a successful Scrum process in a project.
▪ He is a pure process facilitator, motor and motivator of the team
▪ Plus generic project management tasks as to PMM

– Resource Allocation – Enhancement & modification standards

– Conduct Kick-off – Transport Management
– High-Level project – Project Charter
– Implementation – Organizational Change Management
– Level of documentation (which documentation is needed?)
– Issue & Escalation procedure
– Project tools

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 71

Critical Success Factor
Scrum Master

Scrum Master
• Each team has its own Scrum Master who ensures that the team adheres to Scrum
process, values and rules

• Facilitates team work and status by organizing daily scrum/stand-up meetings

• Prepares together with Product Owner and team the sprint & release planning

• Monitors progress of sprint & release backlog

• Protects the team by external interference & removes obstacles that prevent the team to
proceed at max pace

• Provides the team with watever the team needs to be more productive

• It is the SCRUM master that works for the team, not the other way round

• Co-located with the team

• SCRUM master is the “interface“ to project stakeholders not direclty working with the team

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 72

Agile Project Governance

Scrum Master (s)

responsible for consistent
Work Stream/
Scrum Team 1 scrum execution and Executive Steering
standards, Committee
e.g. Finance
1 for 3 scrum teams Strategically directs
project

Work Stream/
Scrum Team 2 Agile Coach
Sales and Distribution Guides through the
execution of the
overall Agile
program

Work Stream/
Scrum Team 3 Scrum of
Manufacturing Scrums 1-n
Scrum of Core Team,
Scrums 2 Project Manager,
Chief Product Owner,
Chief Architect,
Agile Coach Core Team

Work Stream/ Focus on integration topics and Focus on program

Scrum Team 4 cohesive solution build, leadership, backlog
Procurement Consists of the lead consultants management,
and product owners from the planning and
individual scrum teams decision making,
73
guiding principles

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 73

Working with Parallel Scrum Teams

▪ Regular cadence of meetings

between SCRUM Masters of all Scrum Master
Finance Chief Product Owner
SCRUM teams Scrum Master

▪ Goal is to coordinate and align Weekly or

Biweekly

work; highlight dependencies; Sales and

Product
Owner
Product Meeting
discuss cross-topics Product Distribution Owner
Owner
Agile

▪ SCRUM Masters have Coach

PM Review
responsibility to debrief their (Daily)
Scrum Master
respective teams on the results Scrum Master
Project
Manager

Manufacturing
Technical
Scrum of
Scrums
(Weekly or
Product biweekly) Solution
Owner Procurement Architect
Product
Owner

74

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 74

Example
SAP Agile Team- Who are the Chickens and Pigs?
Scrum Master
Technical
support
Business Product Owner
Process Operational support
Expert

Agile Coach
SAP Functional
Tester Expert

SCRUM Team Solution

Optimal Team Size: Architect

7 +/- 2 People
Authorization Scrum of
Technical
Expert Scrums
Expert

Training
Expert
Technical
Expert Project Manager

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 75

How to Start Scaling Agile Teams

Guiding Principles Global Agile Programs

▪ Start with a small core team to setup project structure and identify initial
product back log
▪ Onboard team members gradually over time and identify leads and
coaches as scrum teams are build out
▪ Stick to the agile principles but replicate them in “scrum of scrums”
▪ Identify a core team to focus on planning activities
▪ Identify a dedicated integration team to focus on integration aspects
including architecture, functions, technology and organizational change
management
▪ Leverage a hierarchical product backlog that has multiple product
owners and is decomposed into work stream backlogs
▪ As necessary start with a pilot project to demonstrate Agile success

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 76

Scrum of Scrum Backlog Development

• Feature A • Feature A • Feature F

• Feature B • Feature E • Feature H
• •

Priorities
•

Priorities
Product Owners Feature F Feature I

Priorities
Feature C
Product Backlogs • Feature D • Feature G • Feature J
• Feature E

• Feature A • Feature G
• Feature B • Feature I
• •

Priorities
Program Feature C Feature H
Product Backlog • Feature D • Feature J
• Feature E

Finance Sales and• Feature F Manufacturing Procurement

Work Stream • Feature A1 Distribution • Feature A3 • Feature A4
Product Backlogs (Org.) • Feature A2 • Feature F • Feature H
(Scrum teams) • Feature B • Feature D • Feature G • Feature I
• Feature C • Feature E • Feature J

• Sprint 0 (A) • Sprint 0 (A2) • Sprint 0 (A3) • Sprint 0 (A4)

Work Stream • Sprint 1 (B1) • Sprint 1 (D) • Sprint 1 (F) • Sprint 1 (H)
Sprint Backlogs • Sprint 2 (B2) • Sprint 2 (E1) • Sprint 2 (G1) • Sprint 2 (I)
(Scrum teams) • Sprint 3 (C) • Sprint 3 (E2) • Sprint 3 (G2) • Sprint 3 (J)

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 77

Scaling Agile
Product Ownership Complexities

Chief Product
Owner

Finance Sales Process Manufacturing Procurement

Process Owner Owner Owner Owner

 Product ownership can be complex in large

organizations.
Planning Assets
Experts Management  Establish product ownership hierarchy to involve
all key stakeholders in the right stages of the
project.
 Align the SCRUM teams with the product owners
for maximum impact.

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 78

Scrum Meetings
Guidelines
Speaker’s Name, SAP
Month 00, 2017

PUBLIC

Partner logo
Objective of this Guideline

This guideline provides the characteristics of:

A. Daily Stand-Up Meetings
B. Scrum of Scrum Meetings

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 80

Characteristics Daily Stand-Up Meeting

▪ Same time daily

▪ Same place (preferably at task board)
▪ Stand-up meeting: Everybody stands in front of the task board
▪ Entire duration: max. 15 min
▪ Not a problem-solving or design session, not a status meeting to anybody else than team
▪ Scrum master reports on obstacles. Update of impediment and obstacle backlog
▪ Update work remaining on tasks for burn-down. Sprint is fixed on backlog item level but flexible on task level
The team is allowed to add, change or remove tasks or to adapt estimations
▪ Non-team-member invited to listen and observe (PO, user, manager and other stakeholders)

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 81

Daily Stand-Up Meeting Questions

Each participant answers four questions:

1. What did I accomplish since the last meeting?
2. What will I accomplish today?
3. What obstacles are in my way?
4. What will you accomplish tomorrow?

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 82

Meeting Rules
For Daily Stand-Up/Daily Scrum Team

▪ Arrive on time or early

▪ Be ready to say what you did since the last meeting and what you plan to do today
▪ Keep your report specific, precise and short in order to help the meeting end within 15 minutes
▪ Listen to other team member's status in case it might relate to your tasks or impact you
▪ Don't interrupt people when they are talking
▪ Note the tasks or action items you volunteer for
▪ If you raise an issue or question that can't be resolved in a minute, ask to discuss with the parties involved
after the meeting
▪ For those calling in, be sure to start your report with "This is [your name]“
▪ Non-team-members invited to listen and observe but not to actively participate (product owner, user,
manager and other stakeholders)

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 83

Scrum of Scrum Meeting
To Coordinate Work Amongst Teams

▪ Scrum of Scrum meetings allow teams to discuss their work, focusing especially on areas of overlap and
integration
▪ Examples of possible subjects for SAP projects:
– Master Data, Interfaces, Security, Conversion, Reporting.
▪ Scrum of Scrum Meetings differ from daily Scrums:
– They do not need to be held daily (e.g. 2-3 times a week).
– They are problem-solving meetings.
– They do not need to be timeboxed to 15 minutes. Recommended length is between 30 and 60 minutes.
– The team will choose the best representative to participate in the Scrum of Scrums. (Can vary from
meeting to meeting)
Duration Agenda Item
Timeboxed to 15 minutes Each participant answers 3 questions:
• What has my team done since we last met that could affect other teams?
• What will my team do before we meet again that could effect other teams?
• What problems in my team having with whch it could use help from other teams

As needed Resove problems and discuss items on an issues Backlog.

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 84

Agile
Retrospective Meeting
Speaker’s Name, SAP
Month 00, 2018

INTERNAL

Partner logo
Purpose

Provide insights about

when and how to organize a
Retrospective meeting in
Agile SCRUM Projects

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 86

Agile Retrospective Objectives

Objectives:
What and how can we do better next sprint?
While the scrum review meeting focuses on the results or deliverables, the sprint retrospective
concentrates on the sprint process itself
We have to identify means which enable us to be more efficient, better, or just have more fun in the
next sprint (or in the future in general)

Retrospective is not an opportunity to place blame

We learn what went well so we can repeat it
We learn what didn’t go well so we can stop doing it

What are the current top priority problems and how can we solve them during the next
sprint?

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 87

Retrospective – When and How To

When:
After each sprint (preferably after sprint demo)
As and when required

Participants: SCRUM Team and Product Owner if needed

Location: Room with whiteboard (undisturbed)

Time: half an hour to full day, depending on project and team size and sprint duration

Moderator: Scrum Master or any team member or external moderator

Facilities: Post-its, magnets or similar for dot voting

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 88

Generate Insights: Dot Voting Technic

Good stuff Bad Stuff Ugly Stuff

If we could redo the same If we could redo the same If we could redo the same
sprint again, we would do sprint again, we would do sprint again, we would not
these things the same these things differently do this at all
way
Post-
Post-
it
Post- it Post-
Post- Post- it
it
it it
Post- Post-
it Post- Post- it
it it
Post-
it

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 89

Tips and Tricks for Spring Retrospectives

• Plan at least one hour of preparation time for a sprint retrospective.

• Optimal: large room without tables to allow for group work.

• Review and update your Team Charter during a retrospective.

• When deciding what to do, ask people what they feel most passionate about.

• Bring burndown charts, picture of whiteboard or other artifacts which help the team remember what happened.

• Do not “overdo” but focus on the most relevant aspects, focus on top impediments.

• A sprint retrospective could involve, if felt appropriate by the team, other relevant stakeholders (QA, RUN organization,
Architects, etc..)

• Put list of retrospective action items on the team board (to escape the “out of sight, out of mind” syndrome)

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 90

How to Keep Sprint Retrospectives Interesting

• First and foremost: make sure retrospective decisions are implemented.

• Vary the activities you use in a retrospective (e.g. try emotional seismograph to find out stress patterns during a sprint;
use activities so that everybody – even the introverts – gets heard during the course of the retrospective).

• Consider inviting stakeholders every now and then to bring in new perspectives.

• Consider inviting an external facilitator (i.e. not from within the team).

• Don‘t always use the „generic“ approach (what went well, what can be improved), but instead tackle specific problems in
a retrospective.

• Change the moderator (does not have to be the Scrum Master all the time; but don‘t force anybody to be a
retrospectives facilitator).

• Check whether decisions from former retrospectives have been put to action; if not, consider skipping a retrospective
and make sure old decisions are implemented first.

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 91

4. Agile Estimation Techniques
Responsible: Implementation Team

Ideal Person Days

Productive time of a developer or consultant per day without distraction like meetings, phones,
e-mails, clarifications etc.
Typically between 4-6 hours a day. Meaning that 1 ideal developer day corresponds to 1.5 to 2
calendar days

Story Points (Relative Size)

Relative measure of complexity (2 is half as hard as 4)
Variability averages out across many stories/requirements
Requires each organization to establish a scale to rate size

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 92

4. Agile Estimation Tips and Tricks

▪ Estimates are done by the experts in the team who are implementing the functionality and have experience
from similar projects
▪ More expert opinions lead to better the estimation results
▪ Everybody on the team participates in the estimation process
▪ Verbal communication is preferred over detailed written specs
▪ It is possible to use Planning Poker especially for estimates where experts disagree widely (see next slide)
▪ Clear the assumptions of estimates prior to estimating
▪ Avoid anchoring, it invalidates estimates – e.g. “I would say this is easy so it should be X ideal person days”
▪ Estimate in Ideal Person Days
▪ If consensus can not be reached defer the estimate of requirement to later time

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 93

4. Estimation with Planning Poker

Planning Poker is a consensus-based approach to agile estimating.

▪ To start an estimating session, the product owner or customer reads a user story or
requirement or describes a feature to the estimators, who should include everyone on the
team.
▪ Each estimator is holding a deck of cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100,
which is the sequence we recommend. The values represent the number of story points,
ideal days, or other unit in which the team estimates.
▪ The estimators discuss the feature, asking questions of the product owner as needed. When
the feature has been fully discussed, each estimator privately selects one card to represent
their estimate. All cards are then revealed at the same time.
▪ If all estimators selected the same value, that becomes the estimate. If not, the estimators
discuss their estimates. The high and low estimators should especially share their reasons.
After further discussion, each estimator reselects an estimate card and all cards are again
revealed at the same time.
▪ The process is repeated until consensus is achieved or until the estimators decide that
estimating of a particular item needs to be deferred until additional information can be
acquired.
(Source: Mountain Goat Software) Maintain the effort estimate results in the Project Backlog
© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 94
4. Estimates Must Cover All Activities to a Point of Completion of Sprint and
Release

▪ Define when you consider backlog item done. Definition must be clearly understood by all involved in the
project. See examples below for recommended definitions.
▪ Ensure that the estimates in the backlog include all activities required for completion of sprint and for
completion of release.

Definition of Done for Sprint Definition of Done for Release

▪ Solution built and configured in DEV ▪ User Acceptance tested
▪ Solution is unit tested in DEV ▪ Integration tested
▪ Functionality tested by Process Owner and Testers ▪ User documentation completed
▪ Functionality documented ▪ Training material completed
▪ Bugs Fixed ▪ No technical debt – e.g. no unfinished work or
▪ Sprint Demo Completed compromises (“we will get to this later”)
▪ Training material completed ▪ Functionality ready for release to business
▪ Functionality transported to QAS and ready for
acceptance test

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 95

5. What Will We Ship in the Release?
Responsible: Process Owner

The release can be functionality/scope or timeline/budget driven.

Functionality/Scope Driven

Questions for Product Owner

▪ Which requirements from the project backlog need to be realized so that
the business can gain business benefits in first release?
▪ What can be deferred to second release or later?

Timeline/Budget Driven

Question to Product Owner

▪ When does business expect the first release?
▪ Is there budget constraint that we need to deliver to?
▪ Which processes/requirements are expected by the business and by
when?
© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 96
6. Calculate Initial Velocity & Expected Duration Per Backlog Item
(Responsible SCRUM Master/IT Team)

Velocity definition:
▪ Velocity represents the way Agile teams use to measure team’s capacity to process
backlog items.
▪ Velocity is defined as sum of effort estimates of completed (and accepted) backlog
functionality that the team delivered in a given period of time (usually sprint).

Velocity is sum of estimates for backlog items completed during the last sprint
Example: Team estimated 90 ideal person days worth of backlog items, but completed only 85. 85 is their
current velocity.

Average Velocity = Sum of N Previous Sprint Velocities / N

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 97

6. Calculating the Initial Velocity

Initial velocity is always an estimate.

Example:
Especially for newly formed teams this
Step 1 – Determine Calendar Days per Sprint
figure will be fine tuned over next few We have 4 team members working 5 days/week
sprints. Planning should take this into * Sprint Length is 4 weeks
account. = 80 Person Calendar Days per Sprint

Step 2 – Adjust calendar days into Ideal Person days

In this case ideal days are 50% of calendar days. This results in 40 Ideal Person Days
capacity per Sprint.

Step 3 – Adjust for team experience

If it is very first Sprint use 40% as a rule of thumb to reflect team’s learning curve and to
calibrate the velocity. This results in a capacity of 24 ideal person days for the first
sprint

For 2nd sprint increase the actual velocity of 1st sprint by 20 % (e.g. 32 if all
See Tab Release Planning & functionality has been completed) and for 3rd sprint use average velocity of previous
Burndown in Backlog template sprints.
© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 98
6. Finalize the Schedule for a Release and Sprints

Example
▪ The sum of ideal person days for release #1 is 180 (result from project backlog).
▪ Taking changed estimates and new requirements into consideration it will take 6 sprints to complete the
project back log for release #1.
▪ Full release schedule the plan needs to also include Integration Test, User Acceptance Testing, End user
documentation and execution of the Final Preparation phase steps. This is the basis for estimation of the
cutover date for the release.

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 99

Sprint Burndown
and Task Board Example
Speaker’s Name, SAP
Month 00, 2017

PUBLIC

Partner logo
Objective of this Accelerator

The intention of this accelerator is to explain how an

Agile Task Board and how Burn-down charts look like.

Preference is to use a physical whiteboard(s) in a team

room for the task board and to draw/attach the
burndown charts to it.

The SAP Activate Agile Accelerator “Product Backlog”

(Tab Sprint Backlog) can be used to create a digital
version of the sprint burndown chart.

If a physical whiteboard is not possible as to e.g. co-

location reasons, tools such as Jira can be used as a
second option.

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 101
Example Task Board
Day 0

Ready for As to the

Definition of
Stories To Do In Progress Acceptance Done Done agreed by
the team
Test

78 1 Task 1 Task 2
2 6
Extra status in
sales transaction Task 3 Task 4
To be completed by
3 1 Task 4 the QA resource in
The estimated ideal
hours per task side the Scrum
team
102 8 Task 1 Task 2
2 5
CRM Interface
Task 3 Task 4
3 3 Task 4

113 5 Task 1 Task 2

1 1 Blocked User
Opportunity Total story points remaining for this
Won/Lost Report Task 3 Task 4
Stories/Tasks sprint: 1+8+5=14
2 1 Task 4 The total amount of ideal hours of all
tasks is 111.
The story number
from the product
If impediments are Assumption: 1 Story Point = 1 Ideal Day
blocking the team = 8 Ideal hours
backlog
to realize a user
story the story or
This figures are used as input for the
The story points estimated sprint burndown chart (see next slide)
for the story during the tasks are posted
planning session here..

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 102
Example Sprint Burndown Ideal Hours
Day 1

On day 0, there are no

tasks and stories burnt
down. 14 Story Points
and 111 Ideal hours of
tasks remaining.

Different task
categories (Build,
Documentation,
Testing, Master Data,
Security/Authorization)

See SAP Product Backlog Accelerator template

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 103
Example Task Board
Day 4

Ready for As to the

Definition of
Stories To Do In Progress Acceptance Done Done agreed by
the team
Test

78 1
Task 1 Task 2
2 6
Extra status in
sales transaction
Task 3 Task 4
3 1 Task 4

102 8 Task 5 Task 6 Task 1 Task 2

2 5 2 5
CRM Interface
Task 7 Task 4 Task 3
3 3 Task 4 3

113 5 Task 5 Task 2 Task 1

1 1 1 Blocked User
Opportunity Total story points remaining for this
Won/Lost Report Stories/Tasks
Task 3 Task 4 sprint: 1+8+5=14
2 1 The total amount of ideal hours of all
tasks is 111.
The story number
from the product
If impediments are This figures are used as input for the
blocking the team sprint burndown charts
backlog
to realize a user
The story points estimated story the story or
for the story during the tasks are posted
planning session here..

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 104
Example Sprint Burndown Ideal Hours
Day 4

Total remaining amount

of tasks in ideal hours is
85 = 10,6 Ideal Days

See SAP Product Backlog Accelerator

© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 105
 Agile Methodology for SAP
Sprint 1
Backlog User Story
Grooming grooming Design DEV SIT UAT

Product
Backlog Sprint 2
Backlog User Story
Grooming Grooming Design DEV SIT UAT

Product • It’s a User Story with priority – it should be tagged to feature(s). User story will have a FD • PO
• It should not span across sprints, it should be covered in single sprint • PO
Backlog • Define acceptance criteria. Ex. Working demo, all required documents – TD, all Code performance and static checks • PO
• Prioritize and pick backlogs for the sprint
Sprint • PO, ST
• Handshake between PO and Scrum Team - Understand User story and estimate story points based on complexity and effort – Use Fibonacci series
• PO, ST
Planning/Design • OneITVSO should have been updated with relevant backlogs
• PO
• Design (HDD) to be made ready by the sprint start time
• SM
Scrum Team • It should happen on the first day of the sprint.
• Backlog HDD should be ready by the first day of sprint– prepared by Scrum Architect(SA) and Scrum Master (SM) • ST
Planning • Split user story into tasks and task estimation. Ex. TD creation, code for the object, Quality checks(VF, CI checks etc), Peer review and test
• Meeting should happen on the first day 4th week of the sprint
Sprint Review • Scrum Team demo the backlog deliverable to PO. • PO,ST
• Product Owner(PO) to provide his acceptance based on the acceptance criteria. If accepted backlog set to closed.
• Check daily progress: What we did yesterday and what’s today task – Update the Task status
Daily Scrum • Discuss dependencies, issue and risks • ST

• Change in Sprint (product) backlog(User Story) is evaluated by scrum team. If the change is additional scope, It will be put into new backlog or if the change in current backlog
then it will be terminated
• Partially met backlogs would be kept open and will be worked in the next sprint
PO – Product Owner; SM – Scrum Master; SA – Scrum Architect; ST – Scrum Team