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

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

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]

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.

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

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

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

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.

1. Project Backlog Define Project Requirements

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.

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)

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

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.

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

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

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

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

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?

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

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

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.

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