Agile Methodology

1. Agile Implementation Methodology
Release Planning
Name, SAP
January 18, 2024
Add partner
logo and alt text

2. 2
 Purpose of this unit is to explain steps that are
necessary to plan a release based on Agile
implementation approach
 The unit also discusses estimation and planning
techniques that are applied at the end of the Explore
phase to complete the project backlog
Purpose
Release Planning

3. 3
Agile Release Planning
Prepare Realize
Explore Deploy Run
Realize Release 2
Data Management
RUN SAP
Organizational Change Management
Baseline Build
Working
Software
Release 1
Sprint
Sprint
Sprint
Business
Priority
Time
Iterations / Demos
Evaluate
Define
&
Analyze
Scope
Demo
SAP
Standard
Setting
the
scene
Must
Should
Could
16
15
14
13
12
11
10
09
08
07
06
05
04
03
02
01
Would
Demo
Support
Evaluation &
Release Planning
Tests
Final
Prep.
Prep. Sprint
Sprint
Release 2
Sign-Off
Process WS
& Sol.Archit.
4
5
1
8
2
7
3
4
2
2
4
3
3
6
4
5
Checkpoint
Checkpoint
Checkpoint
Accelerators
Enablement
Organization
readiness
Project Backlog
Priority [d]

4. 4
 Before planning a release it is necessary to know approximately when the customer team would like to
release working software to the business (frequency and approximate dates).
 The team also needs to know the relative priorities of the project backlog items that is based on input from
process owner.
 Backlog items must be sequenced by relative priority (e.g. order 1st, 2nd, 3rd …) and unique IDs per line
item need to be established rather.
 Backlog items are prioritized and sequenced by the customer with the input from the implementation team.
 Effort estimates in “ideal person days” are converted into calendar time using known or estimated velocity.
Velocity indicates amount of work effort the team can complete per day, per work week or per sprint.
 It is often necessary to estimate a team’s initial velocity. We recommend to be conservative for first few
sprints and calibrate the estimate over the course of first 1-3 sprints.
Release Planning Management Summary

5. 5
Release Planning Roles and Responsibilities
2. Prioritize Project
Backlog
5. What would you like in the
release?
6. Estimate Initial Velocity,
Finalize Sprint and Release
Plan
3. Analysis of Technical
Dependencies
Business
Responsibility
IT
Responsibility
Process
Owners
Implementation
Team
High-Level
Release
Plan
4. Estimate Project
Backlog
1. Define Project Backlog

6. 6
1. Demo Evaluation Workshops
Does the standard
process satisfy the
requirement?
No
What are the gaps?
Why not use standard?
What is necessary to
modify for the process
to meet requirement?
Yes
Implement as standard
functionality
Assess fit of SAP Standard Configuration
Demo of
standard
processes
Iterative Requirements Gathering

7. 7
 Project Backlog represents list of requirements that have not been
built during the Baseline Build but need to be delivered to the
business.
 Process Owner will prioritize the list once it is completed. It is
important to capture all requirements before focusing on
prioritization.
 Fill in: “How to demo” which represents acceptance criteria for the
requirement and will be used during the sprints.
 The Process Owner owns the Project Backlog and defines the
priorities either during the workshop of later.
1. Define Project Backlog
Responsible: Process Owner
Configuration Enhancements Reports Interfaces Conversions
Document the
backlog items from
business
perspective.

8. 8
1. User Requirements
In Scrum Projects are Expressed in Business Language
Example:
• As a buyer
• I want to save my shopping cart
• so that I can continue shopping later.
How to demo:
• Enter store
• Put a book in the shopping cart
• Press “Save Cart
• Leave store, enter it again
• Check that the book is in my cart
Template:
• As a <role>
• I want to <what>
• so that I can <goal>.
• “How to demo” section must define the
acceptance criteria for each requirement.

9. 9
1. Project Backlog
Define Project Requirements

10. 10
How to establish clear priorities:
 In Agile projects the Process Owner must prioritize and force rank list of all requirements in project backlog.
 No two items can end up being ‘equal’ on the list (e.g. have the same priority and ranking).
 Main reason for this is to prevent that everything is rated as a “Must Have.”
 The MSCW prioritization (Must-Have, Should-Have, Could-Have, Would-Have) is used for an initial grouping
of requirements.
 Secondary step is to rank items within the same priority group.
2. Prioritize the Project Backlog
Responsible: Process Owner
Use columns “Priority Category” and “Priority Rank”
in the Project Backlog to prioritize and sequence
the requirements.

11. 11
Prioritization techniques (exemplary):
 Compare importance of selected requirement to others – comparative assessment
 Consider business value of each requirement (as assessed in business case or value case)
 Distribute set number of points per person in prioritization / ranking exercise
 How many dots from pool of 1000 points does this requirement get?
Dimensions to consider during prioritization:
 Dependencies and Integration – assess impact of the requirement on other requirements (technical risk,
dependencies, integration points)
 Scale – the desirability of the feature to a broad base of users (business impact, acceptance)
 Importance – the desirability of the requirement to a small number of important users or customers
(influencing key stakeholders, business value)
2. Ways to Establish Priorities

12. 12
3. Analysis of Technical Dependencies
Responsible: Implementation Team
Business
Requirements
IT
Requirements
Cross-Functional
Requirements
Process Owner Team
Product Backlog
I want to have
requirement #3 as
Must have Priority!
OK, but in order to
realize that you need to
set-up your Org Model
first.

13. 13
 Analyze the business requirement and add related
technical prerequisites into the backlog.
 All technical prerequisites for process/requirement
receive automatically a Must-Have priority and must be
taken into consideration for the release and sprint
planning.
3. Technical Prerequisites and Dependencies

14. 14
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

15. 15
 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
4. Agile Estimation Tips and Tricks

16. 16
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)
4. Estimation with Planning Poker
Maintain the effort estimate results in the Project Backlog

17. 17
 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.
4. Estimates Must Cover All Activities to a Point of Completion of Sprint and
Release
Definition of Done for Sprint
 Solution built and configured in DEV
 Solution is unit tested in DEV
 Functionality tested by Process Owner and Testers
 Functionality documented
 Bugs Fixed
 Sprint Demo Completed
 Training material completed
 Functionality transported to QAS and ready for
acceptance test
Definition of Done for Release
 User Acceptance tested
 Integration tested
 User documentation completed
 Training material completed
 No technical debt – e.g. no unfinished work or
compromises (“we will get to this later”)
 Functionality ready for release to business

18. 18
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?
5. What Will We Ship in the Release?
Responsible: Process Owner

19. 19
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).
6. Calculate Initial Velocity & Expected Duration Per Backlog Item
(Responsible SCRUM Master/IT Team)
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

20. 20
Initial velocity is always an estimate. Especially
for newly formed teams this figure will be fine
tuned over next few sprints. Planning should
take this into account.
6. Calculating the Initial Velocity
See Tab Release Planning &
Burndown in Backlog template
Example:
Step 1 – Determine Calendar Days per Sprint
We have 4 team members working 5 days/week
* Sprint Length is 4 weeks
= 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
functionality has been completed) and for 3rd sprint use average velocity of previous
sprints.

21. 21
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.
6. Finalize the Schedule for a Release and Sprints

22. Contact information:
© 2024 SAP SE or an SAP affiliate company. All rights reserved. See Legal Notice on www.sap.com/legal-notice for use terms, disclaimers, disclosures, or restrictions related to this material.
Thank you.
Name
Email