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

2. Purpose Release Planning
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

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
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.
Release 2
Sign-Off
Process WS
& Sol.Archit. 4 5 1 8 2 7 3 6
Checkpoint
Accelerators
Enablement
Organization readiness
Project Backlog
Priority
[d]

4. Release Planning Management Summary
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.

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

6. 1. Demo Evaluation Workshops
Demo of standard processes
Assess fit of SAP Standard Configuration
Iterative Requirements Gathering
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
Project Backlog

7. 1. Define Project Backlog Responsible: Process Owner
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.
Document the backlog items from business perspective.
Project Backlog
Configuration
Enhancements
Reports
Interfaces
Conversions

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.
Template:
As a <role>
I want to <what>
so that I can <goal>.
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
“How to demo” section must define the acceptance criteria for each requirement.

9. 1. Project Backlog Define Project Requirements

10. 2. Prioritize the Project Backlog Responsible: Process Owner
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.
Use columns “Priority Category” and “Priority Rank” in the Project Backlog to prioritize and sequence the requirements.

11. 2. Ways to Establish Priorities
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)

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

13. 3. Technical Prerequisites and Dependencies
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.

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, s, 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. 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

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

17. 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
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. 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?

19. Average Velocity = Sum of N Previous Sprint Velocities / N
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 is their current velocity.
Average Velocity = Sum of N Previous Sprint Velocities / N

20. 6. Calculating the Initial Velocity
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.
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.
See Tab Release Planning & Burndown in Backlog template

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

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