Agile Projects using SCRUM @Activate Methodology

TIMELINE - Project GENESIS [A GREENFIELD IMPLEMENTATION]

SCOPE - SECTORS @ P.1-W.1 – PROJECTS RELATED
WAVE 01
DIESEL & MOTOR DIMO (PVT) DIMO LIFELINE DIMO COASTLINE
# Cluster LoB
ENGINEERING PLC LIMITED (PVT) LTD (PVT) LIMITED
Mobility - Mainstream Offshore Business Yes
02 [TATA] + General Engineering & Marine Sales Yes
[General Engineering] General Engineering & Marine Service Yes

Infrastructure Engineering Storage & Material Handling Solutions Yes

03
[CMD] Water & Fluid Management (DL) Yes Yes

Civil Construction Yes Yes

Lighting Solutions Yes
Engineering Projects Building Technologies (DM/DL) Yes Yes
04 [DIMO LTD - Related Elevator & Escalator solutions Yes Yes
business] LV & panel building Yes Yes
Power transmission & distribution (DM/DL) Yes Yes
Power generation (DM/DL) Yes Yes

Health Care Solutions Medical equipment & services Yes

05
[DIMO LTD - Medical] In plants & consumables (DLL) Yes

08 DIMO Digital Sales & Projects Yes

10 Foreign Operations Uganda Operation Yes

SCOPE - SECTOR @ P.2-W.2 - AGRICULTURE

WAVE 02
DIESEL & MOTOR DIMO AGRIBUSINESSES PLANTCHEM PLANTSEEDS
# Cluster LoB
ENGINEERING PLC (PVT) LTD (PVT) LIMITED (PVT) LIMITED

Agri Machinery Sales Yes Yes

Agri Machinery Parts Yes Yes
Agri Machinery Service Yes Yes
Crop Protection & Seeds Yes Yes Yes Yes
07 Agriculture Business Crop Enhancement (Fertilizer) Yes Yes
Agro Services & Technologies Yes Yes
Agri Foods Yes Yes
Urban Agri Yes Yes
Overseas Operations Yes Yes
SCOPE - SECTORS @ P.2-W.2 – VEHICLE SALES & AFTER SALES

WAVE 02
DIESEL & MOTOR DIMO LANKA UNITED DIMO LANKA DIMO BANGLADESH
# Cluster LoB
ENGINEERING PLC COMPANY LTD COMPANY LTD [NAME TBC]*
MB/ JEEP Sales Yes
Other Premier Brand Sales Yes
Mobility - Premium
01 MB Passenger/Commercial & JEEP After Sales Yes
[MB/JEEP]
MB/ Jeep/Other Parts Yes
Premier Other After Sales Yes

TATA Sales Yes

Mobility - Mainstream
TATA Parts Yes
02 [TATA] +
TATA Service Yes
[General Engineering]
Offshore Business Yes Yes

Construction Machinery Sales Yes YES

Infrastructure Engineering
03 Construction Machinery & Material Handling
[CMD] Yes YES
After Sales Services
SCOPE - SECTOR @ P.2-W.2 – RETAIL

WAVE 02
DIESEL & MOTOR
# Cluster LoB
ENGINEERING PLC
Retail Services Yes
Powered Tools & Equipment Yes
Consumer Lighting Yes
Building Solutions Yes
06 Retail Automotive After Market Yes
Tyres Yes
Emerging Channels Yes
Distributive Trade Yes
Industrial and Institution Channel Yes
SCOPE - SECTORS @ P.2-W.2 – OTHER
 Why Agile?

Key Benefits
– Optimize Time to Value – deliver fast, packaged,
low TCI offerings
– Improve Quality and Value to Customer –
holistic, quality products and implementation
– Customer Focus and Proof Points – customers
want to see early and frequent confirmation on the
delivery of benefits that address pain points

Enhanced visibility and measurable results

Manifesto for Agile Software Development

2001 in Snowbird, Utah

“We are uncovering better ways of developing software by doing it and helping others do it.
Through that 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

That is, while there is value in the items on the right, we value the items on the left more."
Manifesto for Agile SW Development – what it means

Individuals and interactions over processes and tools

People (customer & internal) and communication
Minimum amount of process and tools (empirism)
Working software over comprehensive documentation
Customer value
Demonstrate progress, create trust
Customer collaboration over contract negotiation
Co-operation leads to competitive advantage
Flexible contracts, customer controls
Responding to change over following a plan
Planning vs. Plan
Transparency
Continuous improvement
12 Agile Principles

We follow these principles:

1. Our highest priority is to satisfy the customer through early

and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development.

Agile processes harness change for the customer's
competitive advantage.

3. Deliver working software frequently, from a couple of weeks to

a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily

throughout the project.
12 Agile Principles

5. Build projects around motivated individuals. Give them the

environment and support they need, and trust them to get the
job done.

6. The most efficient and effective method of conveying

information to and within a development team is face-to-face
conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The

sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
12 Agile Principles

9. Continuous attention to technical excellence and good design

enhances agility.

10. Simplicity - the art of maximizing the amount of work not done - is
essential.

11. The best architectures, requirements, and designs emerge from self-
organizing teams.

12. At regular intervals, the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly.
The Basics of Agile Methods

ITERATIVE PEOPLE CENTRIC FOCUS

Frequent Inspection & Adoption Trust, Self-organizing teams Team focuses on one thing at a
and individuals time until it’s done

CROSS-FUNCTIONAL CONSTANT LEARNING ADAPATIVE PLANNING

TEAMS

Better fail early to learn fast, To hit a moving target

Face to face communication and improve
/ no silos
SAPACTIVATE Methodology for SAP S/4HANA
Next generation agile methodology that drives customer success

 ONE simple, modular and agile methodology supporting

all S/4HANA transition scenarios
 Full support for initial deployment and continuous
business innovation
 Harmonized implementation approach for cloud, on-
premise and hybrid deployments
 Broad coverage of SAP solutions starting with
SAP S/4HANA
 Enables co-innovation with customers and is accessible
for partners
 Successor of the ASAP and SAP Launch methodology
 SAPACTIVATE Methodology Benefits

• Enables consistent project delivery, reduces complexity and increases quality by providing common
framework and language for all SAP projects
• Broad product coverage, including support for all transition scenarios to SAP S/4HANA
• Scalable, supports all sizes of projects, from small fast cloud deployments to comprehensive global
deployments in on-premise or hybrid environment
• Prescriptive and comprehensive – provides guided work procedures for project team members,
deliverables for project managers and accelerators like how-to documents or templates for all users
• Accelerates project delivery through use of SAP Best Practices, fit/gap analysis, agile project
management, application visualization and use of cloud technology.
• Methodology foundation fully aligned with proven project management practices of Project
Management Institute, like formal Quality, Risk and Issues Management.
SAPACTIVATE Methodology accelerates your journey to SAP
S/4HANA with these principles

Based on over 40 years of implementation experience.

CLOUD READY
START WITH BEST PRACTICES
Leverage the flexibility and speed
Use ready-to run business processes
of the cloud

VALIDATE SOLUTION PREMIUM ENGAGEMENT READY

Validate to best practices with fit-gap Build and Run fully supported
workshops, capture delta via SAP control centers

MODULAR, SCALABLE AND AGILE QUALITY BUILT-IN

Structure project to deliver the solution Identify risk early with total quality
incrementally approach
IMPLEMENTATION METHODOLOGY – AGILE ACTIVATE [SCRUM]
Agile SAP Project Delivery Is About…

… MAKING OUR CUSTOMER’S … COLLABORATION WITH

CUSTOMERS HAPPY BY CUSTOMER, BUIDLING UP
DELIVERING VALUE. RELATIONSHIP AND TRUST.

TO DELIVER PROJECTS ON
VALUE, ON TIME AND ON
BUDGET.*

AGILE IS NOT TO BE
*

UNDERSTOOD AS A PROJECT
COST REDUCATION GUARANTEE
… BUILDING THE SOLUTION
… JUMP STARTING THE PROJECT
CUSTOMERS WANT IN
WITH BEST PRACTICES.
SUSTAINABLE, INCREMENTAL
LEVERAGING STANDARD.
WAY.
What does it take to run SAP project successfully with Agile

 Dedicated cross-functional stable teams Establish focus and avoid multi-tasking. Co-
. located teams preferred.
 Discipline …… Agile requires disciplined approach driven by the
…….. team with support from SCRUM Master.
 Motivated individuals Project team needs to be committed to Agile
approach. Mindset is key.

 Business people assigned to IT project Available, dedicated and knowledgeable Product

Owner(s) is key for success.
…
Customer needs to understand the “Agile rules of
 Buy-In from customer the game“, be committed to the Agile approach.
Scrum
Scrum Framework
AGILE SCRUM
Scrum values:
OPENNESS
COURAGE
RESPECT
FOCUS
TEAM Scm =
Scrum
PO = Product
Owner COMMITMENT
master

DAILY
Standup Backlog refinement

Product SprinT Sprint Sprint

Backlog Planning Backlog REView INCREMENT SPRINT Retrospective

SPRINT
Scrum Roles, Events and Artifacts

Development Scrum Product

TEAM master Owner

Sprint DAILY
Planning Standup
Product Sprint INCREMENT
Backlog Backlog

Sprint SPRINT Retrospective

Review
Scrum Framework

Empowered and self-organized

cross-functional team

TEAM Scm = PO = Product

Scrum Owner
master

DAILY
Standup Backlog refinement

Product SprinT Sprint Sprint

Backlog Planning Backlog REView INCREMENT SPRINT Retrospective

SPRINT
Scrum Framework

Making sure a Scrum team lives

by the values and practices of
Scrum.
Protects team from external
TEAM ScM PO
disturbance.

DAILY
Standup Backlog refinement

Product SprinT Sprint Sprint

Backlog Planning Backlog REView INCREMENT SPRINT Retrospective

SPRINT
Scrum Framework

Has a vision of the product, conveys

that vision to the scrum team (= WHY).
Prioritizes the work in
the Product Backlog (= WHAT).
TEAM ScM PO

DAILY
Standup Backlog refinement

Product SprinT Sprint Sprint

Backlog Planning Backlog REView INCREMENT SPRINT Retrospective

SPRINT
Scrum Framework

Defines all of the work to be done on

the product in priority order.

TEAM ScM PO

DAILY
Standup Backlog refinement

Product SprinT Sprint Sprint

Backlog Planning Backlog REView INCREMENT SPRINT Retrospective

SPRINT
Scrum Framework

2 parts:
1. For which items do we commit
in the next sprint? What is our
Sprint Goal?
ScM PO
2. Pulling items from the product
TEAM
backlog and splitting them into
tasks.
DAILY
Standup Backlog refinement

Product SprinT Sprint Sprint

Backlog Planning Backlog REView INCREMENT SPRINT Retrospective

SPRINT
Scrum Framework

Prioritized task list for the sprint.

TEAM ScM PO

DAILY
Standup Backlog refinement

Product SprinT Sprint Sprint

Backlog Planning Backlog REView DEliverablE SPRINT Retrospective

SPRINT
Scrum Framework

Timebox (1-4 weeks) to produce

potentially deliverable product.

TEAM ScM PO

DAILY
Standup Backlog refinement

Product SprinT Sprint Sprint

Backlog Planning Backlog REView DEliverablE SPRINT Retrospective

SPRINT
Scrum Framework

Checking current situation

compared to the sprint commitment
daily.
- What has been done?
TEAM ScM PO - What will be done next?
- Blocking issues?
DAILY
Standup Backlog refinement

Product SprinT Sprint Sprint

Backlog Planning Backlog REView DEliverablE Retrospective

SPRINT
Scrum Framework

Refining the backlog items:

• Adding new items
• Splitting items
• Estimating effort
TEAM ScM PO

DAILY
Standup Backlog refinement

Product SprinT Sprint Sprint

Backlog Planning Backlog REView DEliverablE Retrospective

SPRINT
Scrum Framework

Mapping the sprint achievements to the

sprint commitment.
Show the achievements to the
stakeholders/customers/users (demo).
Together decide the direction of the
TEAM ScM PO
product.

DAILY
Standup Backlog refinement

Product SprinT Sprint Sprint

Backlog Planning Backlog REView INCREMENT Retrospective

SPRINT
Scrum Framework

Potentially deliverable product

TEAM ScM PO

DAILY
Standup Backlog refinement

Product SprinT Sprint Sprint

Backlog Planning Backlog REView INCREMENT SPRINT Retrospective

SPRINT
Scrum Framework

Learning from the previous sprint:

• What went well?
• What could we do differently to
improve?
TEAM ScM PO

DAILY
Standup Backlog refinement

Product SprinT Sprint Sprint

Backlog Planning Backlog REView INCREMENT SPRINT Retrospective

SPRINT
Agile in Application Lifecycle Management
Delivery of Requirements via Release
Bite Size Scope Implement Release in Integration
Deploy
Pieces Validation Sprints Test

Business
Iterative
Decision: Requirements to Scope

Needs Integration Build

Baseline
Test Release
Build

Q-Gate: Scope to Build

Q-Gate: Test to Deploy

Deployment

Q-Gate: Build to Test

Model
Validation / 2-to-4 wks User
Execute
Roadmap Gap iteration cycle Acceptance
Deployment
Identification Test
Baseline
Scope
Non
Prioritized
Functional
Release Backlog Build, Document, Review, Test
Planning Unit / String Test
 With complete E-2-E
 EXECUTIVE SPONSOR
Agile Project Delivery with SAP Activate @DIMO Wave1 Go-Live  PRODUCT OWNER

W1-RELEASE 1

W1-RELEASE 2
Wave#1 PROJECT SECTOR COMPANIES

Developments

Developments
 SCRUM MASTER
 PROJECT MANAGERS CUM
Backlog LEAD BPOs

Without
Demo
Demo

Demo
Priority [d]  PROCESS BPOs / SMEs
Deployment 16 4
Release 2  SUPER USERS

Would
Roadmap 15 5
14 1

BLACKOUT
13 8
Checkpoint

Checkpoint

Checkpoint
2

Scripts
12

UAT
Could
11 7 Sprint
10 3
09 4

Demo
Release 1 08 2 Plan Sprint
Business Priority

Should
07 2

Demo
FIORI & STD. 06 4 All UATs
REPS
05 3 completed Org. & Run / Support / Operate

Demo
PROCESS
GAPS
04 3 on QAS Tech
Solution Architecture

03 6 SP#...

Must
ORG.STR
WRICEFs Readin
02 4
Baseline Build with BPs tested on ess
Initiate Project

01 5 SP#2 QAS

CUTOVER
Work-arounds for
SBX/DEV

Release and SP#1

Analysis
Fit/Gap

OCM
WS on

Sprint Plan as
UTs of all WRICEFs
per PRODUCT Iterative Build @PRODUCT
DEMO on DEV with
BACKLOG BACKLOG (BBP) on DEV
CORE Integration
Time
COMMON
COMMON Explore Realize1 Deploy1 HYPERCARE / HELPDESK
Prepare
NINE PROCESSES: Procure-To-Pay/Order-To-Cash/Idea-To-Offer/Service-To-Report/Record-To-Report/Projects/Plan-To-Produce/Hire-To-Retire/Maintenance
Workstreams: ANA-Analytics/ADC-Application Design and Configuration/INT-Integration
Workstreams: EXT-Extensibility/DAM-Data Management/TAI-Technical Architecture & Infrastructure
Workstreams: OAS-Operations and Support/TES-Testing/SOA-Solution Adoption/PRM-Project Management
GO-LIVE WAR ROOM => CUT OVER ACTIVITIES & HELPDESK SETUP
Agile Project Delivery with SAP Activate @DIMO Wave2 Go-Live
Wave#2 ALL SECTOR COMPANIES
Agile Roles & Responsibilities

The Project core team consists of:

 Process Owner => DIMO representative of the business

 Project Manager/SCRUM Master

 Implementation Team (SAP Rep/RIG & IT DIMO / Subject Matter Experts)

Agile Roles & Responsibilities

The Project core team consists of:

 Process Owner => DIMO representative of the business

 Project Manager/SCRUM Master

 Implementation Team (SAP Rep/RIG & IT DIMO / Subject Matter Experts)

Role Summary

NEOVATIC PROJECT
DIMO Business

DELIVERY
What? Process How?
Team
Priority? Owner Effort?

PCBs/SCRUM Master
Process Owner
(Lead BPOs [Company Heads] & BPOs [Process Heads of Companies])

 A Process Owner represents the Business.

 A Process Owner is responsible for the success of the SAP implementation from the business perspective.
Therefore, he has the right to make all relevant decisions on content and priorities for the SAP
implementations.
 He owns the end-to-end business process.
 He decides on the “What has to be implemented” and on the Priority, the team answers “How this can be
implemented” and how long this will take.
Super User

Role of SAP Super User

 The SAP super user is mainly responsible for:
 Gathering process documentation
 Taking notes from the end users and communicating them to the implementation team
 Explaining and documenting AS IS processes
 Understanding TO BE processes
 Identifying integration points between modules and contacting other departments as necessary
 Testing all business processes in SAP test environments
 Capturing defects which appear during testing
 Training the end users
 Supporting the end users
 Continuous process improvement
 Monitoring end user performance
 Determining ongoing training needs
 Maintaining documentation
Project Manager (Also acts as SCRUM Master)

Responsibilities:
 The Project Manager is responsible for the overall management of standard implementation and industry solution projects throughout its
lifecycle

Tasks:
 Participate in the project planning activities and manage the execution of projects according to plan
 Manage relationship with project stakeholders, including internal and external clients, keeping stakeholders informed of progress and
issues in order to manage expectations on all project requirements and deliverables.
 Manage and communicate a clear vision of the project’s objectives, and motivate the project team to achieve them; create a project
environment that enables peak performance by team members.
 Proactively identify changes in work scope and ensure appropriate planning measures are taken with internal and external stakeholders to
reassess and amend the scope of work requirements, budget and timeline.
 Manage the financial aspects of the project: budgeting and estimate to actual variance.
 Analyze risk, establish contingency plans and identify trigger events and responsibilities for initiating mitigating action.
 Determine what constitutes successful closure for all parties. Gain acceptance and sign-off by all parties when closure is attained.
 Proactively manage project stakeholder satisfaction to position and secure DIMO reference and success story.
 Ensure proper use of project management methodology, standards, tools, processes and procedures
 Coach to clarify assignments and deliverables to project team; review quality of work and manage integration of team members’ work;
provide performance input to project team members’ functional management.
 Maintain work-life balance for the team - ensure breaks at defined milestones for leave, training etc.
 Performance appraisal of the team members
Project Management Office (PMO)

Responsibilities:
 The Program/Project Office is responsible for the professional operation of the program-/project office regarding to the following tasks.

Tasks:
 Arrange meetings for project team including co-ordination of project team meetings and external events.
 Co-ordinate travel arrangements for the team.
 Book meeting rooms/venues for the team.
 Deal with general telephone and e-mail queries for the project team with the assistance of the team.
 Monitor the status of the project and distribute information accordingly to respective team members.
 Project controlling tasks including reporting/statistics.
 Communication with DIMOs in the name of the project team.
 Content-related tasks such as presentation preparation for team or DIMO meetings.
 Act as a Financial Project Analyst is the focal point to capture and report financial and other metrics of engagement(s) and/or project(s).

Special Knowledge:
 Knowledge in project management methodology
 Business Knowledge

Reporting to:
 Program Manager, Project Manager
corresponding DIMO Role:
 DIMO project office assistant
DIMO Executive Sponsor

Responsibilities:
 DIMO Project Sponsor acts as a vocal and visible champion, legitimizes the project’s goals and objectives, keeps abreast of major project
activities, and is a decision-maker for the project, generally chairs the steering committee on large projects.

Tasks:
 Helping to provide resources, helping resolve difficult issues, dealing with organizational politics, etc.
 Approving strategies, implementation plan, project scope and milestones.
 Driving and managing change through the organization.
 Prioritizing project goals with other ongoing projects.
 Communicating with other key organizational representatives
 Participation in and/or lead project preparation/initiation; the development of the Project Charter.
 Taking appropriate decisions and final decision that are within the scope of the project
 Participation in project planning (high level) and the development of the Project Preparation (Initiation Plan).
 Delegating any of the above responsibilities to other personnel either on or outside the Project Team
 Providing support for the Project Manager; assists with major issues, problems, and policy conflicts; is active in planning the scope;
approves scope changes; signs off on major deliverables

Reporting to:
 Steering committee
DIMO Steering Committee

Responsibilities:
 Depending on how the project is organized, the steering committee can be involved in providing resources, assist in securing funding, act
as liaisons to executive groups, and fill other roles as defined by the project
 DIMO Steering Committee generally includes management representatives from the key departments of organization involved in the
project oversight and control
 This group will provide executive level leadership and have the larger institutional vision perspective. The Steering Committee will make
institutional policy decisions as necessary to ensure the success of the project

Tasks:
 Meet regularly to review project plan impact on their departments
 generally they approve project deliverables
 provide resolve issues and policy decisions
 Steering the project to completion in an orderly and progressive manner
 Assist in testing, training and implementation planning and support
 Review and approve scope changes, and provide direction and guidance to the project

Participants:
 Project Sponsor (Chair)
 Program/Project Manager
STEERING COMMITTEE MEETINGS

 There shall be 12 Steering Committee Meetings:

At the end of :
1. PREPARE PHASE
2. EXPLORE PHASE
3. REALIZE PHASE
4. DEPLOY PHASE
5. For assessing Go-Live readiness/preparedness before Go-Live.
DIMO SAP Implementation - Project Governance structure
Agile Project Governance

Scrum Master (s)

responsible for consistent
Work Stream/
Scrum Team 1 scrum execution and Executive Steering
e.g. Finance standards, Committee
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,
54
guiding principles
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 Repre

s ent Te
am Memb
er
Coach

responsibility to debrief their PM Review

(Daily)

respective teams on the results Scrum Master Scrum Master

Project
Manager

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

55
Scrum of Scrum Backlog Development

• Feature A • Feature A • Feature F

• Feature B • Feature E • Feature H
• •

Priorities
Product Owners • Feature F Feature I

Priorities
Feature C

Priorities
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)
Agile Implementation Methodology
Release Planning
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
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
Responsibility

Process Owners
1. Define Project Backlog
Business

2. Prioritize Project

High-Level Release Plan

Backlog
5. What would you like in the
release?

3. Analysis of Technical
Responsibility
Implementation

Dependencies
Team
IT

4. Estimate Project 6. Estimate Initial Velocity,

Backlog Finalize Sprint and Release
Plan
Demo Evaluation Workshops

Assess fit of SAP Standard Configuration

Demo of
standard
processes
Iterative Requirements Gathering

What are the gaps?

Why not use
standard?
No
What is necessary to
modify for the
Does the standard process to meet Project
process satisfy the requirement?
requirement?
Backlog

Implement as
Yes
standard functionality
Define Project Backlog
Responsible: Process Owner

 Project Backlog represents list of requirements that have not been

Document the
built during the Baseline Build but need to be delivered to the
backlog items from
business.
business
 Process Owner will prioritize the list once it is completed. It is
perspective.
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 Project Backlog
priorities either during the workshop of later.

Configuration Enhancements Reports Interfaces Conversions

User Requirements
In Scrum Projects are Expressed in Business Language

Example: Template:
• As a buyer • As a <role>
• I want to save my shopping cart • I want to <what>
• so that I can continue shopping later. • so that I can <goal>.

How to demo:
• Enter store
• Put a book in the shopping cart • “How to demo” section must define the
• Press “Save Cart acceptance criteria for each requirement.
• Leave store, enter it again
• Check that the book is in my cart
Project Backlog
Define Project Requirements
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.
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)
Analysis of Technical Dependencies
Responsible: Implementation Team

Product Backlog

OK, but in order to

I want to have realize that you need to
requirement #3 as Must set-up your Org Model
have Priority! first.

Business IT
Requirements Requirements
Cross-Functional
Process Owner Team Requirements
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.
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?
Agile
Retrospective Meeting
Purpose

Provide insights about

when and how to organize a
Retrospective meeting in
Agile SCRUM Projects
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?
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

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
Tips and Tricks for Sprint 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)
Scrum Meetings
Guidelines
Objective of this Guideline

This guideline provides the characteristics of:

A. Daily Stand-Up Meetings
B. Scrum of Scrum Meetings
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)
Daily Stand-Up Meeting Questions PRIN
T-OU
T an
d pin
to t a
sk bo
Each participant answers four questions: ard
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?
Meeting Rules PRIN
For Daily Stand-Up/Daily Scrum Team T-OU
T an
d pin
to t a
 Arrive on time or early sk bo
ard
 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)
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.

Agile Definition of Ready & Done
Concept & Guidelines
Objective

This guideline explains the Agile concept of:

 Definition of Ready
 Definition of Done
 Provides a proposal for Global IT Scrum projects

– Note: please finetune the definitions to your project specific situation

Agile Concept Overview

Prepare Explore Realize

READY
Sprint backlog/
Revised prioritizes
product backlog

Determine initial Prioritized product

high level scope backlog with user Sprint Sprint
Retrospective Planning
and Plan stories in Ready
State
2-to-4 wks.
cycle
Sprint
Sprint Review Realization &
Daily Scrums
Work product Work product
Release DONE
increment

Run Deploy

“Don't let anything that's not READY into your Sprint, and let nothing escape that's not DONE.”
(Serge Beaumont about definition of ready)
Definition of Ready

The team will only take work into a sprint when the following criteria are satisfied:

Note: Definition of “ready” prevents sprint thrashing

Negotiate

Definition of Ready
 Why? Business value  Team decides if OK

Ready
 What? Outcome vision  Describes the backlog before
 How? Implementation sprint
strategy and cost
 Enough for 1, 5-2 sprints?
 Quality checklist
 Granularity OK?

Definition of Ready
 The backlog items have been understood.
 It is described for each backlog item individually.
 Is (mostly) static over the time.
 It is negotiated between the customer and Service & Support Team.
Example: Definition of Ready

The team will only take work into a Sprint when the following criteria are satisfied:
 The epic/story is on the Corporate Backlog
 The Team understands the problem
 The Team understands why this is important
 This story has been estimated by the Team
 The Team knows how to demo this story to the Product Owner
 The Team has insight in the context of the story
 Acceptance criteria for the Product Owner are clear and agreed upon
 Acceptance criteria for operations are clear and agreed upon
The Definition of “Done”
Ensures a Real Working Product

Negotiate

Definition of Done
 Acceptance tested  Product Owner decides is OK

Done
 Unite tested  Describes the product at the end of the sprint
 No increased technical debt
 Documentation in order
 Quality checklist
 Conform standard X  Static constraints and requirements
 Can vary over time
Definition of “Done”

The team will only deliver products that satisfy the following criteria:
 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
 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
 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
Example Definition of “Done”

The team will only deliver products that satisfy the following criteria:
 The software has been developed
 The software works technically correct
 The software works functionally correct
 The software has been documented appropriately
 The software is deployed on the ‘X’ environment
 The agreed acceptance criteria from operations (see DoR) are review ready
 The team dashboard is up to date
A Product Backlog Has Flow Regions

In Sprint

Ready

Preparing

New
How to Get User Stories Ready?
Two Options

1. Backlog Refinement Sessions (Grooming)

 Product Backlog items for coming sprints are reviewed and revised by
product owner and team (e.g. twice per week)
 Adding detail and estimates to the coming items of the product backlog
 Usually consumes no more than 10% of the capacity of the team
Ready User

Ready
Story

New
2. “Ready” User Stories (Spikes)
 Determine User Stories which need to be made “ready”
 Incorporate those into the sprint planning meeting

Ready

Done
 “Ready” and “Real” user stories are worked on in parallel
 Tasks are defined to make user story “ready” (“Real”) User
Story

Rule of Thumb:
 Have enough user stories ready for 2-3 sprints
Thank you.
Contact information:
Arun Obilisetty
Sr.Vice President
Neovatic technologies Pvt Ltd
Plot No 78, Kavuri Hills Rd, Kavuri Hills, Phase -1,
Madhapur , Hyderabad, Telangana – 500081
Phone numbers:
+91 40 298 888 65
+91 40 298 888 64