PowerSession-SAFe SAP SolMan and A4SFundementals

POWERSESSIONS
Agile /4 SAP
SAP BUSINESS AGILITY

POWERED BY SAP DELIVERY EXCELLENCE
NOT JUST A PROCESS OR METHODOLOGY,

IT'S A MINDSET. 1
SAP BUSINESS AGILITY Coaching
Agile /4 SAP Advisory
AGENDA Assessment
Training
60
min
10
min 1. Agile /4 SAP
40
min 2. SAFe SAP Solman
10
min 3. QA
Copyright © 2019 Accenture. All rights reserved. NOT JUST A PROCESS OR METHODOLOGY, IT'S A MINDSET. 2
• SAP BUSINESS AGILITY
Agile /4 SAP – The Competitive Advantage

SBG AGILE CAPABILITY
Lead: Malte Kumlehn
Contact: MarketMaker_A4S@accenture.com
ASG Agile Practice Offerings Track record (relevant projects)

Organization Project Scope Benefits
Advisory
Allianz* • SAFe 4.6 Portfolio Configuration with ✓ Program predictability
Create a living business with SAFe SAP Business Agility
250+ people is above 90%
and our organizational adaptability guidance
• Fast growing competitive business, ✓ Gathering business
SAP Scaling & Implementation technology and regulatory requirements requirements
such as Solvency II, IFRS 17 and local from 31 departments
• Portfolio Management
Scaled Agile Framework (SAFe), from portfolio planning GAAP with a SAP HANA Native ✓ Replacing more than 7
to execution greenfield implementation currently running
• The client Launched second Agile systems
• Product Management
Release Train to deploy changes to ✓ More than 600
Use SAFe for providing lean and agile product
legacy ERP BW and multiple more standard reports
management
systems. affected by the new
• Software Craftsmanship & Engineering • Scaled agile accredited SAFe SAP system
Agile QA, Engineering, test automation and SAFe SAP Lighthouse program- Accenture SAP
700+ professionals trained in Agile SAP DevOps Leadership Council 2019 Credential
in ASG Coaching Boeing** • 1000+ people working in a SAFe ✓ Industry-Best-Practice
0 Hands-on, pragmatic guidance from strategy to Solution Configuration with 60 Scrum Processes
1 execution. This includes: Coaching and Mentoring for Teams based on S/4 ERP
Team, Program, Portfolio and Executive Level • S/4 HANA Implementation & harmonized steering
12 model
Trainings
13+ agile projects currently ongoing Agile Fundamentals, Scrum, Kanban, SAFe and Lanxess*** • Greenfield SAP S/4 HANA migrated. ✓ Industry-Best-Practice
in ASG Accredited Agile /4 SAP Fundamentals Training Global Template build and localization. Processes
• Highly customized SAFe approach. based on S/4 ERP
Deep knowledge and experience Assessment & harmonized steering
• 3.800 Agile professionals Team preparation and facilitation for quantitative model
• Established Agile Trainingsprogram with over AgilityHealth measurement. Build actionable growth
20 role-based courses plans for improvement and impediment removal
• Global Leading SAP Agile Academy with 9
weeks results driven intensive executive
training Please reach out to the following contacts before sharing the above credentials:*Christian Uhl, **Curtis Palmer, ***Martin Hoesler
3
SAP BUSINESS AGILITY
Agile /4 SAP
INNOVATION & THOUGHT LEADERSHIP
ROADMAP
European & Global SAFe Summit Main Speaker Accredited AGILE /4 SAP Fundamentals
• May and October 2019 Next Public Training:
• Best in class participant feedback • November 2019
• 2000+ People attending • For registrations reach out to
Accelerate Benefits of ERP With First Steps in Applying Agile & Agile4SAPmax@accenture.com
Enterprise Agile DevOps to ERP Support
Published: 21 February 2019 Published: 18 February 2019
PROVEN SUCCESS PATTERN FOR ACCELERATED OUTCOMES Assessment
Training
Leadership decision to start the journey
3
1 2 SAFe Value Stream Discovery
and Workshop Preparations
4
Go
Executive Agile /4 SAP Leading Phase 1: SAFe Value Phase 2:
Workshop Fundamentals SAFe SAFe DevOps
SAFe Knowledge & Strategy Alignment Stream Workshop LAUNCH
SAP
Identify the value streams and Agree on an incremental plan to Establish guiding coalition for Execute
understand their flow through the develop organization and ensure change. The Lean-agile center of Implementation
organization PI planning readiness excellence Plan
PI 1 Phase 2: Train Team &

Planning LAUNCH Prepare Launch
Support with methods to

develop program and team
backlog as well as metrics
Launch Large
Coach executives, specialty
Solution or
PI 2 Phase 4: Portfolio
roles and stakeholders
Planning throughout the SAFe
ACCELERATE Configuration Essentials adoption
and second ART
PROVEN SUCCESS PATTERN FOR ACCELERATED OUTCOMES Assessment
Training
1
Agile /4
SAP
Fundamentals
SAFE® SAP SOLMAN Assessment
Training
INTRODUCTION
This document has been created to document our Point of View regarding working
SAP efforts using agility under the Scaled Agile Framework
Contents:
1. Feature Refinement and Elaboration Process
2. Mapping work structure between SAP and SAFe
3. Refinement > Build > Test process … using Solman and Focused Build
4. Documentation process
5. Roles and responsibilities
Copyright © 2019 Accenture All rights reserved. 8

FEATURE REFINEMENT
AND ELABORATION
PROCESS
9
FROM A COARSE DIAMOND
TO SMALLER DIAMONDS
Refinement
Integrated
Business
Process Refinement Best Practices
1. Product Managers facilitate Feature
refinement sessions
ERP 2. Capabilities are Process-Centric and

can be broken down into
Capability Functionality-Centric Features
3. Refinement is a continuous and
ongoing activity with Feature
ARTs Refinement 3x/week
WRICEF / a. Infrequent Long Meetings – Initial

breakdown of Capabilities or series
Config of Features (where brainstorming
flow is important)
Teams b. Frequent Short Meetings – Refine
existing specific Features; includes
targeted problem solving and
cross-functional participation
Breaking down diamonds to
too small pieces creates dust
(and that’s not valuable ☺)
FROM A ROUGH CUT DIAMOND
TO A POLISHED DIAMOND
Refinement
Elaboration

PROGRESSIVE ELABORATION CHART – TIMING
Elaboration
FEATURE Details and Activities PI + 2 Upcoming PI Current PI Sprints
Title and Description ✓ ✓ ✓

Benefit Hypothesis ✓ ✓ ✓
Key Decisions and first cut at Success Criteria ✓
Determine if work is via SAP (if so, shift to Solman for Build) ✓
High Level Design and User Story breakdown determined ✓
Refined Success Criteria and Estimate ✓
User Story build activities and Validation of Success Criteria ✓

PROGRESSIVE ELABORATION – PROCESS
1. Create High Level view of

all Features for a Capability Elaboration
(Fast brainstorming flow)
2. Capture all questions

(Do not answer them, yet… We’ll get there)
3. Prioritize and Sequence

(Determine MVP with additional Feature Sets)
4. Select Features to create more detail

(Description, benefit, success criteria)
5. Leverage prioritized Features to begin to articulate other related Features and

any dependencies
6. Use the Progressive Elaboration Chart to determine timing for next level of
detail
7. Refine estimates & Success Criteria as you get closer to PI Planning
MAPPING SAFE STRUCTURE
Refinement
Integrated Epic
Business Process
(L3’s) informs…
May be delivered
ERP Capability
via a WRICEF
or Config
ARTs Feature
Teams User Story User Story

MAPPING WORK
STRUCTURE BETWEEN
SAP AND SAFe
15
MAPPING SAP TO SAFe – Feature Refinement Effort
SAP-oriented Work Definition Business-focused Refinement Planning Horizon
“Workshops” Workshops organized

Epic (Integrated Business Full around L3’s drive
Process) Roadmap
requirements. These
L2,
L3’s
are used to determine
Features that are
Capability String PI+2 decomposed to User
Requirements Fits (mini-process) Roadmap Stories.
(Gaps)
Features are mapped
WRICEF Solman to Capabilities in TFS
Feature Feature PI Plan and grouped into
id Work Package
Epics.
Solman User Sprint

NC Work Item(s) Story(s) Plan
Phases Key:
Copyright © 2019 Accenture All rights reserved.
Workshops > Program Increments > 16
Iterations > Validation activities
WORKSHOPS > REQUIREMENTS > WORK PACKAGES
Workshops
L3: Standard Sales Order Processing

Target BPML > 02C – Offer to Cash > Sales > Manage Orders >
Standard Sales Order Processing
Gap
Requirements
Fulfill DLMS Gap

Gap Gap requisition by Identify DLMS
Other Other Fulfill DLMS Fulfill DLMS reporting status order types and Other
Gap X
Gap
requisition per
DLMS Advice
Code rules
requisitions per
DLMS NSN IS&G
rules
against Original
Document
Number and
store/display
associated DLMS
order details on
Fit
Gaps…
Suffix Code (SO screen

and Line)
Work Packages
511R
Create
DSO
Feature

EPIC > CAPABILITY STRING > FEATURE EXAMPLES
“Standard Sales Order Processing”
for Inventory Control Point (ICP DoD)
• Receive: IDOC DLMS (35 types – i.e. 511R) inbound > O2C Create Demand Sales Order > 02C ATP >
Epic
Delivery Object > IWM (goods issue) > STM (shipping) > DLMS (material receipt ack from customer)
• Cancel: (869C) …
• Status: …
• Reporting: …
• Modification: (511M) …
• Follow-up: (869A/869F) …
Other Capabilities TBD
Capability String
Receive Customer Request Receive Request Fulfilment 869C Receive Customer

IDOC DLMS (35 types – i.e. 511R) inbound > O2C Delivery Object > IWM (goods issue) > STM Cancellation Request
Create Demand Sales Order > 02C ATP (shipping) > DLMS (material receipt ack from IDOC DLMS (35 types – i.e. 511R, 869C) inbound
customer) > O2C Look for Demand Sales Order > Determine
DSO status (cancel DSO or manual intervention)
Feature
511R 511R 869C

511R 511R
511R 511R Create 511R Material Find DSO
Check / Delivery 511R 869C
Inbound Contract DSO Pick / Receipt / Check
Commit Object Shipping Inbound
IDOC Validation Pack Ack from status /
Feature Inventory Creation
customer Resolve

18
CAPABILITY STRING > FEATURE > STORY EXAMPLES
Capability String
Receive Customer Request

IDOC DLMS (35 types – i.e. 511R) inbound > O2C
Create Demand Sales Order > 02C ATP
511R 511R
Feature
511R 511R Create Check /

Inbound Contract DSO Commit
IDOC Validation
Feature Inventory
Store associated Fulfill DLMS Fulfill DLMS Fulfill DLMS Identify DLMS Identify DLMS Fulfill DLMS Fulfill DLMS
Contract Number requisition per requisitions per requisition by order types and order types and requisitions by requisitions by
User Story
on WBS element DLMS Advice DLMS NSN IS&G reporting status store/display store/display splitting customer updating ESD
Code rules rules against Original associated DLMS associated DLMS requested and Status Code
Document order details on order details on quantity based after availability
Number and screen screen on full/partial checks and
Suffix Code (SO inventory delivery creation
and Line) availability and
generating
unique Suffix
Code

19
MAPPING SAP TO SAFe – Feature Validation Effort
Business-focused Refinement Planning Horizon Testing Focus
SAFe suggests that we develop on cadence

and release on demand. Epic (Integrated Business Full
Process) Roadmap E2E / SIT
As WRICEFs are completed in the form of

Features during a Program Increment, we
validate and integrate short threads of larger Capability String PI+2 String
E2E strings. (mini-process) Roadmap Tests
Test
The capability strings are demonstrated at Package
PI boundaries to show success, but we
demonstrate them as well in System builds Feature Feature PI Plan FUT
in the week following each completed
iteration, as ready.
User Sprint Unit

Story(s) Plan Tests
Phases Key:
Workshops > Program Increments > 20
REFINEMENT > BUILD
> TEST PROCESS
21
SAFe REALIZES A
SET OF CONNECTED
KANBAN SYSTEMS Epic
Enabler Portfolio Kanban
VS Epic
Enabler
Capability
Solution Kanban
Enabler
Pr. Epic
Enabler
Feature
Program Kanban
Enabler
Story
Enabl.
Story
Team Kanban

SOLMAN – FOCUSED BUILD FLOW

Phases Key:
SAFe AND SOLMAN “FOCUSED BUILD”

Workshops > Program Increments >
Transitions Key:
= Manual
= Automated
Workshop A/B’s
COMPLETED DURING 12 WEEK PROGRAM INCREMENTS
FEATURE REFINEMENT FEATURE VALIDATION

Work Package
FEATURE
Requirements Work Package Scoping D Scope To Be In Development To Be Tested Successfully D Handed Over
Created O Finalized Developed (FUT/UAT) Tested O To Release
(Funnel) R (Backlog) (Backlog) (Done) D (Accepted)
WIP limit Sub-tasks related to FUT
NC Work Item
STORY
Work Item Analysis + Team D To Be In Development To Be Tested D Successfully

Created Refinement Refinement O Developed (Build/Test Planning) (Unit Test/Fix) O Tested
(Funnel) R (Backlog) D (Accepted)
WIP limit WIP limit Sub-tasks
DESIGN / REFINE BUILD / TEST / FIX

COMMITTED DURING 2 WEEK ITERATIONS
Sub-task states:
B IP D
Backlog → In Process → Done
DOR = Definition of Ready is entrance criteria to be prioritized in Backlog
DOD = Definition of Done is exit Criteria from Done to Accepted
FEATURE REFINEMENT
Create New Work Complete Scope
Define Scope
Package Analysis
D
Requirements Created Scoping O Scope Finalized To Be Developed In Development
R
Requirements in Draft form Area for Features that are Area for Features that are Area for Features that have Area for Features in which at Area for Features with
that are generated from based on one or more actively being defined and completed the Program level least one child User Story is at least one active
Workshop A’s and/or B’s enter Requirements generated from analyzed by the Product analysis, are in priority order, being prepared. child Work Items
the funnel. They are worked parent Capabilities. Manager. and are ready to be picked up (User Stories) in
for approval. for User Story decomposition. Required Fields: development
Description
Required Fields: Attach Application Design • TBD

Required Fields: Required Fields:
State
• Type (Scope Change / Work Document (ADD) or

• TBD Package) • TBD
Configuration Rationale
• Title
• Owner Document (CRD) in Draft
• Development Team status
Required Fields:
• TBD
• Requirements are Approved • PMO Project is identified • Description contains all • Wave (target PI) is defined • A subordinate Work Item
• Requirements are selected in • Requested Release Date is necessary details • An agile team has pulled the state is changed to In
a group to be assigned to a identified (D2/D3/etc. • Success Criteria identified Feature and assigned Development
new Work Package expected) including NFRs and Controls themselves as Development • All attached requirements
• TBD etc. • Product Manager has picked • High Level design is Team state(s) is/are changed to In
Criteria
• Work Package Owner is

Exit
up Feature for definition and determined Realization

has assigned themselves as • Impacted systems identified identified (SI Lead
the Feature owner • Any dependencies identified Responsible)
• Attached ADD/CRD • At least one child Work Item
document is in Ready to has been Created to hold the
Review status first User Story

FEATURE REFINEMENT
OWNERSHIP/RESPONSIBLE MATRIX
Product Product Functional Build Team Test Test Team Scrum
Activities RTE Build POC Comments
Manager Owner Analyst Member Manager Member Master
Work Package Created  ±

WP Scoping state change ✓ 
Create ADD/CRD and attach  ± ±
WP Success Criteria defined  ✓ ± ± ±
Functional Analyst confirms that
ADD/CRD in Ready to Review ✓  ADD/CRD is updated and reviews
with Product Manager
Determine that WP meets DOR  ± ± Product Manager engages others in

DOR but ultimately makes decision
WP Scope Finalized state change and

Wave assigned  ± ✓ Product Owner works with Product
Manager and RTE to slot work into PI
WP To Be Developed state change  ✓

ADD/CRD In Realization  ±
Legend:
Copyright © 2019 Accenture All rights reserved.  = Responsible and required ✓ = Required 26
± = Participates when necessary empty = not involved
USER STORY REFINEMENT
To Be Developed TD Ready to Review TD Released
D
Created Analysis & Refinement Team Refinement O To Be Developed In Development
R
Normal Change Work Items During this state, a limited During this state, the team These are Users Stories that User Stories that are
number of team members members who will build and are ready to be developed in a committed by the agile
Required Fields: (typically leads) review User test meet and review the User future Sprint. Only those team for Sprint and
• Development Team Stories with the Product Stories with the Product stories that are committed by have active work
• Developer
Owner. A New TD is created Owner. TD is put In Review the team should have a Sprint
Description
and updated. during peer review. assigned.

State
Required Fields: Required Fields: Required Fields:

• TBD • Size is updated to reflect Team • TBD
estimation
• TBD • Attached TD is Ready to • Attached TD is Released • Sprint is assigned to WI

Review • Parent WP’s state changed • Parent WP’s state changed
• User Story Description using to To Be Developed to In Development
the phrase "As a (user role) I • WI / User Story meets the
want (activity) so that Definition of Ready
Criteria
• Integrate any edits related to

Exit
(business value)"
• Acceptance Criteria using review including agreement
the phrase "Given upon Acceptance Criteria
(conditions) -When (actions) • Define sub-tasks
- Then (expected results)“ • Product Owner will
• Complete detailed design determine Priority (ranked
order for Backlog)

USER STORY REFINEMENT
Work Item created  ± ±

Update ADD/CRD and link as TD ✓ 
Work Item details updated  ± ± ± ±
WI User Story written and Acceptance
Criteria defined  ± ± ± ±
Complete detailed design, update
ADD/CRD, and TD is Ready for Review  ✓
TD in Review by team / update AC and
size WI  ± ✓ ✓ ✓ ±
Define sub-tasks as necessary   
WI priority (rank order) determined and
assigned to Sprint ±  ✓
Determine that WI meets DOR  ± ✓
Legend:
IN-SPRINT WORK
D
In Development To Be Tested O Successfully Tested
D
User Stories that are User Stories that have been User Stories that the Product
committed by the agile team developed, configured, etc. but Owner has ”Accepted”.
for Sprint and have active work have not been Unit Tested.
Required Fields:
Required Fields: Required Fields: • TBD
Description
• TBD • TBD
State
• XXX • User Stories that have been

completely developed and
Unit Tested. The team
believes that it has
successfully met the
Criteria
Exit
Acceptance Criteria.

FEATURE VALIDATION
D
Handed Over
In Development To Be Tested Successfully Tested O
R to Release
Area for Features with at least Feature that has all child Work Features that have been Features that the Product
one active child Work Items Items in a Ready for Release completely developed and Manager has ”Accepted”.
(User Stories) in development state and are ready to be FUT. FUT. The team believes that it
has successfully met the Required Fields:
Required Fields: Required Fields: Success Criteria. • TBD
Description
• TBD • TBD
Required Fields:
State
• TBD
• XXX • XXX • State of each requirement

attached to this WP is
changed to Realization
Completed
• TBD
Criteria
Exit

TOOL CLEANUP
Re-prioritizing WP’s that were not complete

in the previous PI’s  ± ✓ ±
Identify and Document WP dependencies  ✓ ± ± ±
WI - Update Effort Estimate ± ±  ± ±
WI – Update % Complete ± ± ±  ±
Identification of Scope Creep & add new
work items  ± ± ± ±
Move Work Items that were not complete
to new Sprint  ✓
Identify and Document WI dependencies  ✓ ± ±
Ensure Scrum board and Impediment Log
remain updated  ± ± ± ✓
Legend:
12-WEEK PROGRAM INCREMENT (PI)
Ongoing Feature Integration

4
Delivery 2
Delivery 3
Delivery Delivery Delivery IP
1 5 1
Iteration Iteration Iteration Iteration Iteration Sprint
PI Planning preparation
1 PI Planning 2 Sprint Planning 3 Story Demo 4 Feature Demo 5 Inspect & Adapt Workshop

TIMING OF SAFe STATES – ROLLING WAVES
Feature Refinement Design / Refine Build / Test / Fix Feature Validation
Iteration N-2 Iteration N-1 Iteration N Iteration N+1
FEATURE
Work Package
FEATURE
Work Package
D D Handed Over
Requirements Work Package Scoping Scope To Be In To Be
Requirements Tested
Work PackageSuccessfully
Scoping HandedScope
Over To Be In To Be Tested Successfully
Created O Finalized Developed Development (FUT/UAT)
Created Tested To Release
Finalized Developed Development (FUT/UAT) Tested O To Release
R D
Features
D D Successfully
STORY
Work Item
Work Item Analysis + Team To Be In Development To Be Tested Handed Over
Created Refinement Refinement O Developed O Tested To Release
R D
User Stories
Build > Test >
> Accept Feedback from Team “Show & Tell”

is fed back into future prioritization
and refinement
Build > Test > Accept

WRICEF
DECOMPOSITION
EXAMPLE ~ INTERFACE
34
FEATURE REFINEMENT
Delivery document creation to allow for order fulfillment in the warehouse

OTC.08.070 – Manage Delivery Document
Specify source and target systems

Determine integration technology
Define trigger and frequency
Define source and target structures

35
BREAKING DOWN INTO STORIES
Distribution Order
• Order Attributes • Focus on required fields to
•
•
Order/Delivery Type
Inventory Type get to “minimum viable
• Order Date
• Customer Details
product”
•
•
Customer Name/ID
Contact Name/Phone • Start with fields that are
• Double QC Flag
• Lot Tracking Flag defaulted or pass-through (no
• Special Instructions
• Transportation/Route
transformation needed)
•
•
Ship Via
Reference Shipment Number • Populate other required fields
•
•
Route ID/Stop Sequence
Consolidation Group
with placeholder value
•
•
Transportation Responsibility Code
Billing Method Code
(technical debt)
• Items to Fulfill
• Customer PO Reference
• Item Number
• Quantity/Unit of Measure
• Fulfillment Type
• DEA 222 Blank #

36
STORY 1
Distribution Order
• Order Attributes • The first story will focus on
• Order/Delivery Type
• Inventory Type building out key fields
• Order Date
(highlighted in green)
• While the transportation/route
• Customer Name/ID
• Contact Name/Phone
• Double QC Flag
• Lot Tracking Flag details are required on the
order, we can populate
•
•
Ship Via
Reference Shipment Number
default values for now
•
•
Consolidation Group
(technical debt, highlighted in
•
•
Billing Method Code
yellow)
• This would allow testing the
•
•
Item Number
Quantity/Unit of Measure
downstream system with real
•
•
Fulfillment Type
DEA 222 Blank #
deliveries passed in from the
source system
37
STORY 2
Distribution Order
• Order Attributes • This story addresses the
• Inventory Type technical debt incurred by
• Order Date
building the actual logic for
•
•
Customer Name/ID
Contact Name/Phone
passing the transportation
•
•
Double QC Flag
Lot Tracking Flag
and route data (instead of the
• Special Instructions default values)
•
•
Ship Via
Reference Shipment Number
• This story would be
•
•
Consolidation Group
dependent on the first story
•
•
Billing Method Code
and any work required in the
• Items to Fulfill source system to pass the
• Item Number route/stop data
• DEA 222 Blank #

38
STORY 3
Distribution Order
• Order Attributes • This story addresses the logic
• Inventory Type for the remaining fields in the
• Order Date
distribution order
• The story would be
• Customer Name/ID
• Contact Name/Phone
• Double QC Flag
• Lot Tracking Flag dependent on the Story 1, but
not necessarily the Story 2
• Ship Via
• Reference Shipment Number
• Route ID/Stop Sequence
• Consolidation Group
• Transportation Responsibility Code
• Billing Method Code
• Item Number
• DEA 222 Blank #

39
DOCUMENTATION
PROCESS
40
DESIGN PROCESS SPEC DOC
•1 Application Design Document (AD Document) or
Configuration Rationale Document (CRD) shell is
LIFECYCLE FOR ADD/CRD

attached in Draft state with background and
impacted system details.
•2 ADD or CRD is updated with high-level design
details, impacted systems, dependencies, and
acceptance criteria
1 2 3 8 9
•3 Feature Definition of Ready: High-level design* for
WRICEF object is formulated by Product Manager
Work Package
Requirements
To Be Tested
Development
Handed Over
Successfully
To Release
Developed
and Functional Analyst in collaboration with
Work Package
Finalized
FEATURE
Scoping
Created
D D
Tested
Scope
To Be
appropriate representatives. ADD or CRD may be
In
O O
updated with additional business scenario and
R D
compliance considerations as “New Version”.*
•4 Detailed design is executed by team through
analysis and refinement of stories. ADD or CRD
should be updated with all decisions and linked to
Work Item as a Technical Design document.
•5 Story Definition of Ready: Acceptance criteria
defined and supporting artifacts must be referenced
(not attached) to Work Item.
4 5 6 7 •6 Updates to the ADD or CRD may continue as the
detailed design is “baked”.
To Be Tested
Development
Successfully
•7 Story Definition of Done: ADD or CRD must be
Refinement
Refinement
Developed
Analysis +
Work Item
Created
D D
Tested
Work Item
To Be
STORY
updated with what was built (Process / Data Flow

Team
O In O Diagram and Functional Design Details sections)

R D before story can be called done.
•8 Test cases and conditions are added/referenced.
State is changed to Ready for Review.
•9 Feature Definition of Done: ADD or CRD state is
changed to Released.
DOR = Definition of Ready is entrance criteria to be prioritized in Backlog *Based on WRICEF type, the high-level design
DOD = Definition of Done is exit Criteria from Done to Accepted should incorporate relevant considerations.
ROLES AND
RESPONSIBILITIES
42
Permissions Key: Solman role
SOLMAN “FOCUSED BUILD” PERMISSIONS Program roles
MATCHED TO KANBAN STATE

Team roles
Feature Refinement Feature Validation

Release
Architect Functional Analyst
Manager
Functional Product Manager + Test + Product
Product Manager + Functional Analyst
Analyst Functional Analyst Manager
FEATURE
Package
D D
Requirements Work Package WP Scoping O WP Scope WP To Be WP In To Be Tested Successfully O Handed Over
Work
Created {Design/ADD} R Finalized Developed Development (FUT/UAT) Tested D To Release

(Funnel) (Backlog) (Done) (Accepted)
Repair (as
needed)
Work Item
STORY
Work Item Analysis + Team D WI To Be In Development To Be Tested D Successfully

Created Refinement Refinement O Developed (Build/Test Planning) (Unit Test/Fix) O Tested
(Funnel) R (Backlog) (Done) D (Accepted)
WIP limit WIP limit
Developer
PO + Developer + PO + PO + Dev/Test +
Product Owner
Functional Analyst Dev/Test Developer Functional Analyst
Design / Refine Build / Test / Fix

SAFe ROLES MAPPED TO FOCUSED BUILD ROLES
ART level: Team level:
1. Product Manager 5. Product Owner
Solution Architect, Business Functional Analyst, Business Functional Analyst and Developer
and Release Manager
6. Development Lead
2. Functional Analyst Developer, Test Manager, and Tester
Solution Architect, Business Functional Analyst,
Developer, and Tester 7. Developer
Developer, and Tester
3. Tester
Developer, Business Functional Analyst,
Test Manager, and Tester Systems Team:
8. Tool Lead
4. Test Manager
Test Manager and Tester Solution Manager Tool Lead
9. Project Manager / Scrum Master / RTE
Project Manager

SAFE® SAP SOLMAN Assessment
Training
Q&A
In ASGR, we have the globally leading SAP Lean-Agile coaching capability Assessment
to help you on your journey to unlock BUSINESS AGILITY.
Training
Allianz & Accenture SAP Global Scaled

Key Global Scaled
Accenture SAP Leadership Agile Program
Contributor Agile Program Globally
SAFe Summit Council 2019 Consultant
to Gartner’s Consultant Accredited
Speaking 2018 Credential Trainer (SPCT)
Research 2019 (SPC) 2018 2019
Candidate
2018
1st 1st 1st 1st 1st
Launching two 1st Co-Trainer IC Agile /4 SAP
Scaled Agile Minimum Viable
Programs with authorization in Essentials
recognized SAFe Business In the SAP
200+ People the SAP domain Training, taught
SAP Program in Process (MVBP) domain interationally
Financial Services Concept
Global Leading
SAP Agile
Academy 2018
700+ 1st
People Trained in Agile /4 SAP 9 weeks results
driven intensive
executive training

PowerSession-SAFe SAP SolMan and A4SFundementals

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PowerSession-SAFe SAP SolMan and A4SFundementals

Uploaded by

Copyright:

Available Formats

POWERSESSIONS

SAP BUSINESS AGILITY

NOT JUST A PROCESS OR METHODOLOGY,

Agile /4 SAP – The Competitive Advantage

ASG Agile Practice Offerings Track record (relevant projects)

PI 1 Phase 2: Train Team &

Support with methods to

Copyright © 2019 Accenture All rights reserved. 8

ERP 2. Capabilities are Process-Centric and

WRICEF / a. Infrequent Long Meetings – Initial

Copyright © 2019 Accenture All rights reserved. 11

FEATURE Details and Activities PI + 2 Upcoming PI Current PI Sprints

Title and Description ✓ ✓ ✓

Copyright © 2019 Accenture All rights reserved. 12

1. Create High Level view of

2. Capture all questions

3. Prioritize and Sequence

4. Select Features to create more detail

5. Leverage prioritized Features to begin to articulate other related Features and

Teams User Story User Story

Copyright © 2019 Accenture All rights reserved. 14

“Workshops” Workshops organized

Solman User Sprint

L3: Standard Sales Order Processing

Fulfill DLMS Gap

Suffix Code (SO screen

Copyright © 2019 Accenture All rights reserved. 17

Receive Customer Request Receive Request Fulfilment 869C Receive Customer

511R 511R 869C

Copyright © 2019 Accenture All rights reserved.

Receive Customer Request

511R 511R Create Check /

Copyright © 2019 Accenture All rights reserved.

SAFe suggests that we develop on cadence

As WRICEFs are completed in the form of

User Sprint Unit

Copyright © 2019 Accenture All rights reserved. 22

Copyright © 2019 Accenture All rights reserved. 23

SAFe AND SOLMAN “FOCUSED BUILD”

FEATURE REFINEMENT FEATURE VALIDATION

Work Item Analysis + Team D To Be In Development To Be Tested D Successfully

DESIGN / REFINE BUILD / TEST / FIX

Required Fields: Attach Application Design • TBD

• Type (Scope Change / Work Document (ADD) or

• Work Package Owner is

up Feature for definition and determined Realization

Copyright © 2019 Accenture All rights reserved. 25

Work Package Created  ±

Determine that WP meets DOR  ± ± Product Manager engages others in

WP Scope Finalized state change and

WP To Be Developed state change  ✓

and updated. during peer review. assigned.

Required Fields: Required Fields: Required Fields:

• TBD • Attached TD is Ready to • Attached TD is Released • Sprint is assigned to WI

• Integrate any edits related to

Copyright © 2019 Accenture All rights reserved. 27

Work Item created  ± ±

• XXX • User Stories that have been

Copyright © 2019 Accenture All rights reserved. 29

• XXX • XXX • State of each requirement

Copyright © 2019 Accenture All rights reserved. 30

Re-prioritizing WP’s that were not complete

Ongoing Feature Integration

Copyright © 2019 Accenture All rights reserved. 32