IT SAP MFG CI - Agile Guidelines

Version Management

Who When Which topic changed

CI Leads 16 Apr 2018 Overall Review

2
Contents
1 Creating an EPIC (EPPM project) in Rally................................................................................................... 5
2 Creating a MMF in Rally ............................................................................................................................... 5
2.1 Steps to create a MMF in Rally:............................................................................................................ 6
3 Requesting to create the features (feasibility analysis) ........................................................................... 7
3.1 Feature creation follow-up ................................................................................................................... 8
4 Creating features .......................................................................................................................................... 8
4.1 Steps to create the feature in Rally: .................................................................................................... 8
4.2 Important Information: ........................................................................................................................ 10
5 Assign features to an Agile Team and BA ............................................................................................... 12
5.1 Steps to assign a feature to an Agile team and BA in Rally .......................................................... 12
6 Creating User Stories ................................................................................................................................... 13
6.1 Steps to create a User story in Rally................................................................................................... 13
6.2 User Story types .................................................................................................................................... 14
6.2.1 SPIKE................................................................................................................................................ 14
6.2.2 CONF .............................................................................................................................................. 15
6.2.3 DEVL................................................................................................................................................ 15
6.2.4 ITEST ................................................................................................................................................. 16
6.2.5 BTEST ............................................................................................................................................... 16
6.2.6 KT ..................................................................................................................................................... 16
6.2.7 SEC .................................................................................................................................................. 16
7 Agile Rituals .................................................................................................................................................. 16
7.1 Grooming Process................................................................................................................................ 16
7.2 PSI Planning Process ............................................................................................................................ 18
7.3 Sprint Planning Process........................................................................................................................ 20
7.4 Sprint DEMO .......................................................................................................................................... 20
7.4.1 Demo Agenda template: ........................................................................................................... 21
7.5 Daily Stand Up Meeting ...................................................................................................................... 22
7.6 Retrospective ....................................................................................................................................... 22
8 Special Procedures ..................................................................................................................................... 23

3
 8.1 Process to handle Cancelled Items (MMF, Feature, User Story) ................................................... 23
8.2 Missing Say Do Ratio - Features "Notes" field updates .................................................................... 23
8.3 Knowledge Transfer to TIER 2 and Implementation Teams: ............. Error! Bookmark not defined.
8.4 How Manage the AD issues identified during the IT or Business Tests. .......................................... 24
8.5 Supporting Resource Maintenance - TAGS Field ............................................................................ 24
9 Roles of Delivery Team ............................................................................................................................... 25
9.1 Product Owner ..................................................................................................................................... 25
9.2 Scrum Master ........................................................................................................................................ 25
9.3 Delivery Team ....................................................................................................................................... 26

4
1 Creating an EPIC (EPPM project) in Rally

Who: CI Managers

When: When a new EPPM project will require Enhancements and start the Epic name with the
EPPM project number.

Define the “Preliminary Estimate” field in the EPIC when creating:

EPIC Preliminary Estimate

EPIC XS

EPIC S

EPIC M

EPIC L

EPIC XL

2 Creating a MMF in Rally

Charter Coordinator

Charter 1 day MMF Created

Submitted in Rally

Who: Charter Coordinator.

When: One day after a charter is submitted.

5
Steps to create a MMF in Rally:

1. Click on Portfolio  Portfolio Items  MMF;

2. Click on “Add with details“ button;

3. Enter with the information “highlighted”:

 MMF Name:
Charter Number – Tittle Charter
Example: 2901 - PNF Brazil Freight

 State (Mandatory)
Status „Discovering“ until all the features are created.

6
  Color (Mandatory)
Color related to each functional area.

Functional Area Color

PP Dark Blue
SD Green
LES Orange
MM Yellow
PM/QM Grey

Tier 2 additional Colors

Functional Area Color

Finance Purple
GTS Pink
Warranty Lt. Blue
PDM Dark Orange or Reddish

 Description (Mandatory)
As given per charter.

 Attach Charter in MMF

 Rank, if available

3 Requesting to create the features (Business Analyst assignment)

Charter Coordinator Charter Coordinator

Charter 1 day MMF Created 3 days MMF

Submitted in Rally Assigned to a
BA

Who: Charter coordinator.

When: Three working days after the MMF is created.

How:

1. Send email to the CI module PDL, requesting volunteer. If not getting an answer, use
the responsibility matrix in order to define the BA that can create the features;
2. Assign the BA name in the MMF;
3. Send an email to inform the BA about the MMF number and the dead line to create the
features.

7
3.1 Feature creation follow-up
Charter coordinator is responsible to ensure BAs are creating the features in a timely
manner.

A new Tableau report (use is optional) was created to support The Charter coordinators to
track the features creation.

https://tableau.deere.com/#/views/AgileManagementTools_0/FeatureCreationTracking?:ii
d=1

4 Creating features
Charter Coordinator Charter Coordinator BA

Charter 1 day MMF Created 3 days MMF 15 days Features

Submitted in Rally Assigned to a Created
BA

Who: Business analyst

When: Up to fifteen workdays after MMF is assigned.

What is a Feature: A feature is a deliverable (distinct element of functionality that can provide
capabilities/value to the business) and it is sized or split as necessary to be delivered within a
single PSI.

When a Feature is applied: Whenever you have CI charters/implementation charters or

enhancements, etc.

When to break a feature: When you have more than one viable product for a single project.
Exceptions must have IT Manager approval.

4.1 Steps to create the feature in Rally:

1. Click on Portfolio  Portfolio Items  MMF;
2. Find the corresponding MMF and click on the MMF number;
3. Select the tab “Children”;
4. Click in “Add with details”;
5. Enter with the information highlighted (mandatory fields):

8
  Feature Name:
Charter Number – Tittle Charter
Example: 2901 - PNF Brazil Freight Invoice

 State
Discovering: when the features creation are in process;
Developing: When all features for a MMF are created and ready to start.

 Preliminary estimate
Size of the feature according the table below.

Size
XS
S
M
L
XL

9
  Color (Mandatory)
Color related to each functional area.

Functional Area Color

PP Dark Blue
SD Green
LES Orange
MM Yellow
PM/QM Grey

 Owner:
This field should contain the name of the BA who is creating the feature. Once the
feature is created this field should be changed to “blank”.

 Project:
Keep the feature assigned to “SAP CI team” during the feature creation process.

 Description:
Use the description template that is automatic provided by rally.

The overall content of the feature, in the description, is the replacement of the feasibility
analysis (FAD) and conceptual design document (CDD).

 Primary Functional Area (Mandatory)

From this dropdown list respective feature area (SAP Module) must be selected.

 Stakeholder (Mandatory)
As stakeholder the BPI given in the charter must be populated.

 Notes (Optional)
This field is for additional information.

 Rank
Copy the rank information from SharePoint (BPM Rank field).

4.2 Important Information:

Once all the features are created for a given MMF, the BA should be able to define a
Preliminary Estimate for the MMF and for the Features. This estimate should be set in the MMF and
Features in Rally as below:

10
MMF Preliminary Estimate:

MMF XS

MMF S

MMF M

MMF L

MMF XL

Assign the Preliminary Estimate to the MMF

Assign the Preliminary Estimate to the Features

The sizing of the MMF, Features and user stories is based on the
knowledge and experience within each agile team, which can be
different.

11
5 Assign features to an Agile Team and BA
Charter Coordinator Charter Coordinator BA Product Owner

Charter 1 day MMF Created 3 days

MMF 15 days Features Feature
Submitted in Rally Assigned to a Created Assigned to
BA Team and BA

Who: Product Owner

When: During the Product Owners meeting. For the Features with status developing.

In the meeting between product owners, align and coordinate which team will get the features
from CI Backlog (twice a week – 1h meeting).

Also, review assigned work and priorities – features assigned to PSIs and which teams is
assigned. Goal is to ensure we are focused on the top priorities.

Assign features from CI Backlog to a specific delivery team and PSI.

5.1 Steps to assign a feature to an Agile team and BA in Rally

1. Change Feature project field in rally to the agile team

2. Assign owner to the assigned BA
3. Assign feature to a future PSI
4. Contact the BA

12
6 Creating User Stories

A small unit of estimated, prioritized work, with some demonstrable business value, that can be
delivered in at most a single Iteration

Charter Coordinator BA Product Owner BA

MMF 15 days Features Feature User Stories

Assigned to a Created Assigned to Created for a
BA Team and BA Feature

Who: Business analyst

When: after the Feature is assigned to the BA

When do not create US: for activities that are not CI related (Support, Admin Time…).

6.1 Steps to create a User story in Rally

6. Click on Portfolio  Portfolio Items  Features;

7. Find the corresponding feature and click on the feature number;
8. Select the tab “User Stories”;
9. Click in “Add with details”;
10. Enter with the information highlighted:

13
  User Story Name:
User story type + Charter Number + User Story Description
Example: CONF:2872 - Configure Brazil Free Trade Zone

 Project
Select BA’s team.

 Parent (Feature)
Ensure the user story is assigned to the corresponding feature.

 Schedule State (Mandatory)

B (Backlog) – All new created US should have status Backlog

 Color (Mandatory)
Color related to each functional area.

Functional Area Color

PP Dark Blue
SD Green
LES Orange
MM Yellow
PM/QM Grey

 Description
Describe the user story according to the given template.

 Owner
Select correct owner (BA or developer) for the User story.

 Rank Field: Is optional to maintain

6.2 User Story types

6.2.1 SPIKE

Definitions:

• Definition of Done: Clarification of the design question.

• Activities related to a task aimed at answering a question or gathering information.

• Spikes are time-boxed investigations that address unknowns and risks (which prevent confident
estimation).

• Used to remove technical unknowns

• Spikes may result in more user stories

• Spikes are NOT used to DEFINE requirements

Name: SPIKE: Charter # – User story description

14
 Cases where a SPIKE should be created:

• The BA understand the requirements but there are more than one possible
solutions and need to go deeper to decide what direction to take;

• The BA understand the requirements but is not aware if the solution is

available/viable (in case this was not investigated during FAD creation);

• The BA understand the requirements, the solution is clear but there is a risk
to affect other processes and this should be investigated;

Examples:

• Design Solution because the FAD does not have enough details

• Perform analysis to implement new technology into the current

solution from the FAD

• To get alignment with outside teams on the current solution

Cases where a SPIKE shouldn’t be created:

• The requirements are in high level and a further discussion with business is
required to understand the details;

• The requirements are not clear

• The requirements are clear and BA need some time to translate it to

functional specification.

6.2.2 CONF

Definition: Activities related to System Configurations.

Name: CONF: Charter # – User story description

• Definition of Done: Configuration is complete in CAG/CA2 and initial tests are complete.

6.2.3 DEVL

Definition: Activities related to Developments/Changes.

Name: DEVL: Charter # – User story description

• Definition of Done: Development is complete in CAG/CA2 and initial tests are complete.

15
6.2.4 ITEST
Definition: Activities related to test a new functionality developed/configured.

Name: ITEST: Charter # – User story description

• Definition of Done: IT test is complete.

o Optional to the CI manager to have evidences in Rally about the test completion.

6.2.5 BTEST
Definition: Activities related to support business during the test.

Name: BTEST: Charter # – User story description

• Definition of Done: BPI test is complete.

o Required to have the BPI signoff, through email, attached in Rally.

6.2.6 KT
Definition: Activities related to create/update documentation and Transfer the knowledge IT
Implementation and Tier 2 teams. Process code should be in the meeting invitation to the teams.

Name: KT: Charter # – User story description

• Definition of Done: knowledge transfer is finished within the PSI. It means the meeting to share
the solution with T2, implementation, SolDel and other teams is complete prior to finish the PSI;
the documentation is complete, test scripts updated and created.

6.2.7 SEC
Definition: Activities related to getting security setup for a new or changed functionality.

Name: SEC: Charter # – User story description

• Definition of Done: Security defined before the BTEST, to allow BPI to test the new role.

7 Agile Rituals
7.1 Grooming Process

• Who writes the user stories – BA or PO. Can be decided by Regional team.

• Planning Poker – Fibonacci method is used.

• Spikes – Not used for requirements gathering. Can be used to identify which option to use.

• Dependencies identification (EDI, PDM, FICO, PI, BW and others)– PO’s meeting with outside
teams to coordinate PSI target in advance.

• What should be covered in the grooming meeting – Backlog items based on rank.

• Who is invited – Scrum Team

16
• Who is the facilitator of the meeting – The Product Owner

• An User Story Scoring should not change unless a significant issue was identified.

• Once a User Story is committed, the scoring will not change.

Once the user story is presented, discussed and voted during the grooming session, the following
fields should be updated in Rally:

1. Change Schedule State from “B” (Backlog) to “D” (Defined)

2. When all stories for a feature are scored set “Ready” flag for feature

What is Fibonacci ?

Fibonacci scale consists of a sequence of numbers used for estimating the relative size of user
stories in points

Why Fibonacci ?

 Encourages Stories to be estimated relatively;

 A story looks to be 2X the effort than one already scored as a 2, so it’s probably a 5
 Emphasizes the larger the story, the more uncertain the estimate
 Main benefit: Enough separation exists between numbers to prevent team squabbling
over slight differences.
 i.e. For a scale 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, team members might debate over a 7 or 8
 Agreement is easier for team member to reach if the scale jumps from 5 to 8

Scales Used

 Fibonacci: 1, 2, 3, 5, 8, 13
 Linear: 0, 1, 2, 3, 4, 5….
 T-Shirt: XS, SM , M, L, XL
17
 This tool can be used to assist the grooming execution in a virtual session:

http://www.planitpoker.com/

7.2 PSI Planning Process

PSI Objectives:

Why: Commitment of work to be completed on the upcoming PSI.

What: User Stories and Features

Expectation:

– Features must have a Rank to be included on the PSI.

– Business Tests discussed and planned with the BPIs prior to the PSI commitments.

– Status of User Stories and Features must be Ready, in Rally.

Objectives

• Who provides the priorities – BPIs and leadership (Rank determination). PO’s
collaboratively assign features to PSI’s in a meeting held 2 times a week.

• What should be covered in the meeting – What we can commit for the next PSI.

• Who is invited – PO’s, Scrum Master, Team Lead and Scrum Team.

• How to plan for 8 weeks – Business priority (Rank)

• Planning for dependencies for 8 weeks – External dependencies – PO’s are managing
during the meetings they lead with those teams. Internal dependencies – BA,
Developer and BPI availability.
•
18
 • Scrum Master Sponsor – Schedule and host the PSI Commitments Meeting.

• What tools to use – Agile Central

• Velocity estimation – should not be compared to other teams and should take into
consideration capacity (vacations, admin time, support, etc)

• After Team PSI Planning, PO’s will perform a review of the entire backlog and ensure all
READY features are assigned to a PSI.

• If something needs to be reprioritized and moved to another PSI, the rank MUST be
updated unless you have an IT leadership directive.

Considerations:

• CRB Calendar

• Time zone Management

• Portfolio Projects – CI People Support

• T3 Production Support

• Administration Time

• Vacations

• Outages: Non-Prod:
http://share.deere.com/teams/SAPInfraShared/Lists/WCN/CalNonProdOutages.aspx

• Others:
http://share.deere.com/teams/SAPInfraShared/Lists/WCN/Outage%20List%20Public%20Vie
w.aspx

Who: Scrum Master/Product Owner/CI Team Lead/BAs

When: Once the Features and Users Stories are ready to be assigned to a PSI.

19
7.3 Sprint Planning Process

• Team will commit to what can be delivered in next Sprint by the end of each Sprint

• Team creates a plan for how they will deliver

• Team considers capacity, to make sure the commitment is reasonable

• Everyone on the team takes part, regardless of role and experience-level

Who: Product Owner

When: After the Users Stories are ready to assign to a Sprint.

Vacation/Appointments – considered for capacity when identifying velocity.

Planning for dependencies for the sprint - PO’s meeting with outside teams to coordinate PSI
target in advance. PO’s who are experiencing issues gaining commitment from other teams
should reach out to the other CI PO’s to work together to gain commitments.

What should be covered in the meeting – review next sprint commitments and any commitments
in current sprint not completed.

Who is invited – scrum team

Sprint objectives – ranking done by BPI’s are taken in consideration for sprint objectives.

Grooming is a continuous process outside of velocity calculation

Outside projects entered into Agile Central consume velocity. Outside projects which are not
entered into Agile Central need to have velocity updated.

7.4 Sprint DEMO

• Performed at the end of each Sprint

• All Stakeholders come together and see a demo of what the team has produced

20
 • Product Owner gathers feedback from everyone on the ways to improve what has been built

• Feedback is incorporated into the Product Backlog.

1- User Story must be accepted before the meeting. Agenda is pulled in from Tableau report of
commitments.

2- The BAs will use the best format for the scenario and make sure they are prepared.

3- Who should attend? – Team members per module, module BPI’s

4- The facilitators are the Scrum Masters assigned to lead the meetings for specific modules.

The Demos are divided by Functional Area and the Scrum Master is responsible to for:

Schedule the demos sessions in the calendar and include all involved for each area

Send the Demo Agenda 1 week prior to each demo session

Use this link to extract the demo agenda features from tableau:
https://tableau.deere.com/#/views/AgileDashboardV2/SprintDemoPlanning?:iid=1

7.4.1 Demo Agenda template:

For next Demo Session (Sprint ??-?) upcoming on Wednesday 29 Aug the
following features are included for presenting:

Snapshot from Tableau

Following BPI’s and BAs are requested to participate:

BPI BA
Fernando
Eli Shimp
Batista
21
 Flavia Souza
Dinesh Korade
Vijay Jay
Neha Shukla
Mathias Kalyan Kalisetti
Schacht John Penry
Mariana
Mark Meloy
Lasarte
Rafael Cruz Kalyan Kalisetti

Thanks
Scrum Master Name

7.5 Daily Stand Up Meeting

A short meeting daily to share progress and surface impediments

Strictly time-boxed to 20 minutes or less

3 questions: Optional

• what was done yesterday / since last meeting

• what will be done by tomorrow / next meeting
• and any issues/impediments

How & Who to solve/escalate the roadblocks – scrum master responsible and will escalate to
team lead. Scrum master to use PDL to collaborate with other scrum masters.

Email the team when not available – attendance preferred, not required. Email if not attending.

Update the status of the user stories prior meeting – adding notes to update status every other
day is optional by team.

What happens when I am done with my work planned for the sprint – ask for work within scrum
team and/or pull work ahead.

We should cover in the meeting only CI Charter work.

7.6 Retrospective

• Critical for continuous improvement of team effectiveness

• Method for identifying and addressing critical problems & working on innovative ideas

• Cover 3 questions:

1. What worked well?

2. What we learned?

22
 3. What we can do better?

• Participants: Team, Product Owner, and Scrum Master

• How to make the retro effective: Allow the team members to populating spreadsheet at any
time. Make sure team knows retro is for anything with regards to agile and delivery process,
not just limited to a single sprint or PSI. Scrum master makes themselves available outside of
meeting in the case team members are not comfortable sharing within the meeting.

• What should be covered in the meeting: Anything related to Agile process.

• Who is invited – Scrum Team with Team Leads being optional.

8 Special Procedures
8.1 Process to handle Cancelled Items (MMF, Feature, User Story)

Business decided NOT to go ahead with the Charter, in this case the following steps should be
considered:

If the work has not started:

 Delete the MMF, Features and User Stories

 Send a note to Business and to the IT Charter Project Manager (Angela Kelley) to make
sure SharePoint will be updated as well as cancelled.

If we already started to execute the Items (already running in PSI):

 Include the cancel comments in the Notes field in the user stories, features and MMF.
 Change the User Story Status to “Accepted” (only for the US that had some work
executed)
 Delete the User Stories not started yet
 Change the feature state to Canceled
 Change the MMF State to “Done”
 Send a note to Business and to the IT Charter Project Manager (Angela Kelley) to make
sure SharePoint will be updated as well as cancelled.

8.2 Missing Say Do Ratio - Features "Notes" field updates

Following format should be used in the feature notes when we miss the say-do:

Say Do Missed Reason:

Say Do Missed Action Plan:

Deploy Planned Date/Notes:

Category:<category name>:

The categories will be included by the Leads. Examples are: Scope Change, Communication,
Planning, Prioritization IT, Prioritization Business, Quality, Business Hold.
23
 Any additional note can be added after the ones above.

It means:

IF the feature is DONE, no standard notes required.

IF the feature is READY TO DEPLOY, the “Deploy Planned Date/Notes” is required.

IF the feature was Missed on the Say Do, the notes “Say Do Reason and Say Do Action Plan” are
required.

Note: The Say/Do report does have a 24 hour ‘grace time’ period, if a feature is moved to
another PSI it won’t count as part of the current PSI.

Example: If a Feature is included in a current PSI and stays there more than 24h, it means it is a
commitment on the current PSI.

8.3 How Manage the AD issues identified during the IT or Business Tests.

We need to Create Defects (DE….DEVL………) in the “ITEST” or “BTEST” USs and assign to the
Developer to solve.

We do not assign points to defects.

Benefits:

 Have/track all information’s in the same User Story.

 Review the Defects in the Daily Standup meetings.
 Don’t need to create new User Story.

8.4 Supporting Resource Maintenance - TAGS Field

Use in the MMF and Feature the “TAGS” functionality in Rally to track the Supporting Resource
(Other Functional Areas that the Functional Areas that needs to align/involve in the Charter
execution, like - PDM, PI, COMAR, FICO).

Follow the screen where the “TAGS” field/functionality is located.

24
  MMF Creation Process
o CI Coordinator should Maintain Supporting Resources in the “TAGS” of the MMF, if
applicable.
 This should match Charter SharePoint and Angela Kelley’s email.

 Feature Creation
o BA should maintain Supporting Resources for each feature created, if applicable.
 This can be maintained on all features or just the features where the Supporting
Resource is needed.

 User Stories
o This is OPTIONAL per Business Analyst working on the User Story.

9 Roles of Delivery Team

9.1 Product Owner

– Voice of the Customer

– Accountable for priority

– Within the same Region of the Delivery team

– Works closely with the BPIs

9.2 Scrum Master

Servant leader; Team protector; Impediment Remover; Scrum guide

– Ensures adherence to process framework

– Coaching the delivery team

– Removes impediments

– Facilitates Scrum Meetings

– Communicate if team is over or under allocated

25
 – Monitor & control the health of sprint using Metrics

– Identify & Track action items for every sprint

– Escalate to the appropriate stakeholders in case there is any deviation in the

process

– Participate in CoP (community of practice) with all scrum masters in CI to ensure the
alignment across the CI delivery teams

9.3 Delivery Team

26