AG_17 Agile Implementation Methodology...

PUBLIC
Speaker’s Name, SAP
Month 00, 2017
Agile Implementation Methodology
Release Planning
Partner logo

2
PUBLIC
© 2017 SAP SE or an SAP affiliate company. All rights reserved. ǀ
 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
PUBLIC
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
PUBLIC
 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
PUBLIC
Release Planning Roles and Responsibilities
Business
Responsibility
IT
Responsibility
Process
Owners
Implementation
Team
High-Level
Release
Plan

6
PUBLIC
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
PUBLIC
 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
PUBLIC
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
PUBLIC
1. Project Backlog
Define Project Requirements

10
PUBLIC
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
Use columns “Priority Category” and “Priority Rank”
in the Project Backlog to prioritize and sequence
the requirements.

11
PUBLIC
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
PUBLIC
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
PUBLIC
 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
PUBLIC
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
PUBLIC
 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
PUBLIC
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
PUBLIC
 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
PUBLIC
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?

19
PUBLIC
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
PUBLIC
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
PUBLIC
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

Thank you.
Contact information:
F name L name
Title
Address
Phone number
Partner logo

AG_17 Agile Implementation Methodology...

Recommended

Recommended

More Related Content

Similar to AG_17 Agile Implementation Methodology...

Similar to AG_17 Agile Implementation Methodology... (20)

Recently uploaded

Recently uploaded (20)

AG_17 Agile Implementation Methodology...