introduction kanban with safe at scale

6.1© 2016 Scaled Agile, Inc. All Rights Reserved.

Introduction Kanban with SAFe at Scale


Brad Snyder – Enterprise Agile Coach

MethodologiesTools

Pragmatic Implementations


Agenda

Introduction The Market and Why SAFe

Team Level Level 1

Program / Product Level Level 2

Release Planning

Portfolio Level Level 3


How Agile is scaled – for Projects, Programs and Roadmaps like most enterprises have...


I. Agile Delivery Frameworks

1. Scrum

2. Iterative

3. Teams

4. Lean / Kanban

5. XP

6. Product Management

7. DevOps

8. Design

9. Testing

2012 Agile Alliance’s Subway Map to Agile Practices


I. Agile Delivery Frameworks1. Scrum2. Extreme Programming3. Lean4. Kaizan5. Kanban Method6. Agile Modeling

II. Agile Individual and Interactions7. Crystal8. Cynefin9. Mikado10. Theory of Constraints

III. Agile Development and Testing 13. DevOps14. Test Driven Development - TDD / ATDD / BDD / SBE15. Feature Driven Development (FDD)16. PRINCE / RUP

IV. Agile Scaling Frameworks18. Scaled Agile Framework (SAFe)19. Spotify / Squadification / Pods20. Disciplined Agile Delivery (DAD)21. Large Scale Scrum (LeSS)22. Daikibo23. Enterprise / Rational / Agile Unified Process24. DSDM

V. Leadership 25. Management 3.026. Beyond Budgeting27. Right Shifting

5 Years Later…..You have choices….


SAFe announced and took root in 2011/12

2012Field experience at enterprise scale

2016

Agile development | Lean product development | Systems thinking

1.0 2.03.0

LSE4.0


SAFe's Growth has been explosive

4154% growth since Sept. 2015

4570% growth since Sept. 2014

4Average 4,000 new members / month

80000+members

31102members

11901members


Kanbans in SAFe 4.0

Epic

Feature

Feature

Feature

Feature

Enabler

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Por

tfolio

Pro

gram

Team

Portf

olio

Ba

cklo

g

Enabler

Enabler

Feature

Feature

Feature

Feature

Capability

Valu

e S

tream

Capability

Capability

Enabler

Enabler

Enabler

Valu

e St

ream

Back

log

Prog

ram

Back

log

Story

Developers / Testers

Epics / Roadmap

Leadership / Execs

Dev Mgrs / Architect

Features

Dev / Test Leads


StrategyReview

RiskReview

Monthly

ServiceDeliveryReview

Bi-WeeklyQuarterly

KanbanMeeting

Daily

OperationsReview

Monthly

Replenishment/Commitment

Meeting

Weekly

DeliveryPlanningMeeting

Per delivery cadence

change change

changechange

change

change

change change

change

info

info

info

info

info

infoinfo

info

info

change info

The Kanban Method / Cadences work perfectly with SAFe


SAFe 4.0 recognizes a set of connected Kanban systems

Program Kanban


SAFe 4.0 – Activity during Sprints

Demonstrate the Story Functionality

In the Sprint

Monitor Progress and ensure Features &

Committed Business Processes are completed across Sprints

Progress towards the committed roadmap

across Sprints AND ReleasesModule

Leadership / Execs

Business ProcessDev / Test Leads

StoryDevelopers / Testers


The Reality at Scale

PMO Procurement Enterprise Architecture Audit Metrics

Governance

Production Funding Compliance

Data Network Infrastructure


Kanbans in SAFe – The “Big 5 RULES”

1. Operate on the same cadence

2. Participate in Program-level events for alignment and synchronization

Release Objectives - PI

Release Demo - System

Scrum of Scrums - Ceremonies

Retrospectives - Inspect and Adapt

3. Use normalized estimating with capacity included in the ART’s velocity

4. Meet fixed dates the commitments and manage dependencies with other teams so that the ART can meet its commitments

5. Integrate code with the rest of the ART, following the same code quality practices


Team Level SAFe

with Kanbans



Team Level Level 1


Release Planning


Agenda


Kanbans at the team level were introduced in SAFe 4.0

Epic

Feature

Feature

Feature

Feature

Enabler

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Por

tfolio

Pro

gram

Team

Portf

olio

Ba

cklo

g

Enabler

Enabler

Feature

Feature

Feature

Feature

Capability

Valu

e S

tream

Capability

Capability

Enabler

Enabler

Enabler

Valu

e St

ream

Back

log

Prog

ram

Back

log


Delivery Level 1 – Team Roll-out

Confidential and proprietary information

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Team

Enabler

Enabler


Stories

Product Owner


Sprint TeamsDemonstrate

Story FunctionalityIn Sprints

Product Owner and ScrumMaster


User Story

User Stories are the smallest increment of value, • User Stories typically are completed in less than a week. • User Stories are contained within the Sprint / Sprint. • User Stories are what Product Owners care about.


The Sprint-based Team Scrum Model - Core to it all is “The Story”

Level 1 - Team Level

StoryAuthor

SolutionArchitects

6.24© 2016 Scaled Agile, Inc. All Rights Reserved. Confidential and proprietary information

Level 1 Teams focus primarily on Task and Story Delivery

Story

Task

Story

1 Sprint

1 : M

Task

1 Sprint


The Core Engine of Companies' L1 Teams – Scrum-based Sprint process

Inputs from Portfolio Teams, Delivery L2 Teams, Managers, Execs

Product Owner

Product Backlog

Prioritized list of what is

required: Epics, Themes,

Defects to fix…

Team selects starting at the top as much as it

can commit to deliver by end of the sprint

Sprint Planning Meeting

The Team

Sprint Backlog

Scrum MasterDaily Stand-up

Meeting

Minimum Viable Product

Sprint Review Meeting

SprintRetrospective

Backlog Grooming

Task Breakout

2Weeks

24 Hours


Level 1Team Level

RolesProduct OwnerScrumMasterDevelopers

TestersSolution Architect

Shared Resources / Team-level assigned: UI/UX – Architects – Infrastructure. – Data – Reporting – Integration

Primary Roles at the Team Level


In SAFe 4.0, Kanban was announced as an Alternate Team Method

4 Scrum is optimized for cadence and greenfield development. Most SAFe teams apply Scrum.

4 However; the nature of the work for some teams leads them to Kanban, a method that pulls work based on capacity and WIP Limits

4 Kanban may be most effective when the work is activity based, highly variable, hard to plan, and driven by events outside of the team’s control

4 1 - Integration, 2 - DevOps, 3 - Shared Services, and 4 - Maintenance teams, often implement Kanban

KanbanScrum ?4 However, it is not an either/or choice, teams can apply a blend


Iteration Planning for Kanban Teams


Level 1 can also use Kanbans at the team level – for Stories or Tasks; or both

Story Backlog Task Backlog In Process Task Done

User Story

User Story

User Story

Task

Task Task

Task

Task Task

Task Task

3

2

1

Task

8

16 2

48

8 4

168

Task 8

Task16

Story Done

Delivery Level 1 – Scrum(ban) (Team use of Kanban for Stories & Tasks)


Team Rooms at the Task Level

TeamRoom™A Dedicated Environment forTeam-level Execution and Collaboration


Team Rooms at the Story and Task Levels


Team Level View – CA Agile Central


The L1 Team Model – “Break down Features / Requirements into Stories / Tasks

Sprints (2 Week)


StoryLevel

Validate and accept Stories and their functionality and products as they are integrated into parent

epics

TaskLevel

Story

Task

Elaborate Stories into Tasks, and execute Stories to

produce required functionality and products

Elaborate Stories into and then deliver Tasks to produce

required Story functionality and products

StoryStory

Story


Sprints(2 Week)

The L1 Team Model – “Delivering Stories using Definition of Done”

StoryStory

Story


Team Execution

Team events create a closed loop system to keep the train on the tracks.

Team events

IterationPlanning

DailyStand-up

BacklogRefinement

TeamDemo

IterationRetro


The Challenge - that Enterprise-based teams find

In large, scaled, agile programs,

Customers, Business Users & End Users

TypicallyDON’T CARE

about

Lower-level Functional and Technical User Stories


Kanbans ARE what manage anything above Teams!

Program Kanban


Program Level SAFe

with Kanbans



Team Level Level 1


Release Planning


Agenda


Kanbans in SAFe 4.0

Epic

Feature

Feature

Feature

Feature

Enabler

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Por

tfolio

Pro

gram

Team

Portf

olio

Ba

cklo

g

Enabler

Enabler

Feature

Feature

Feature

Feature

Capability

Valu

e S

tream

Capability

Capability

Enabler

Enabler

Enabler

Valu

e St

ream

Back

log

Prog

ram

Back

log


Program / Product Level 2

Delivery Level 2

(Program / Product)

Feature

Feature

Feature

Feature

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Pro

gram

Team

Enabler

Enabler

Feature

Feature

Feature

Feature

Enabler

Enabler

Prog

ram

Back

log


FeaturesProduct Manager

Stories

Product Owner

Sprint TeamsDemonstrate Story

FunctionalityIn Sprints

Product Management / Program Mgmt. (PMO)ensure progress is made towards

the committed featuresacross Sprints

Product Management and Program Management


Feature

User Story

User Stories are the smallest increment of value, • User Stories typically are completed in less than a week. • User Stories are contained within the Sprint• User Stories are what Product Owners care about

Features are larger than Stories• Features typically span 2-6 weeks in duration • Features are contained within releases• Ideally, Features are contained within a team• Features are what Product Managers care about

The Model above the Story; the Feature allows crossing Sprints

Level 2 - Program / Product Level

Chief Product Owner

ProgramManager

Shared ServicesDev Ops

ChiefScrum Master

LeadArchitect

Dev & Test LeadsPMO and OCM

Level 1 - Team Level

StoryAuthor

SolutionArchitects


Feature

Story

Task

Feature

Story

1 Sprint

1 : M

1 : M

Task

1 Sprint

1 Release

Program Teams primarily focus on Features


Level 1Team Level

Delivery L2Program Level




Roles

Product ManagerProgram Management Team / PMO

Enterprise ArchitectSystems Team

Development, Test, Architecture, Data, Reporting & Infrastructure LeadsEnd to End Testing, Automation, Performance Testing

Architecture Review Board

Additional Roles at the Program / Product L2 Level


Managing Features – Prioritizing Stories

Roadmap (Vision)Roadmap

Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7(IRP)

Sprint 8

TIMELINE

2-Week

Release 1

Sprint 9 Sprint 10

Release 2

Epic

FeatureStory 1Story 2Story 3Story 4Story 5Story 6Story 7Story 8

Story 5Story 6

Story 7Story 8

Story 1Story 2Story 3

Story 4

FeatureStory 23Story 24

Story 23Story 24

Story Acceptance Feature

Acceptance Feature & Feature SetAcceptance


Program Teams track Feature Dependencies


SAFe Program Board


Breaking down

Features & Themes

for consumption

by the Sprint / Kanban Teams

Sprints (2 Week)

(Quarterly

Program Teams – “Break down Features for Teams to deliver Stories

Releases


Then the Delivery teams build up

the Stories

to create Features

in their Sprints

Sprints (2 Week)

Releases(Quarterly)


The Program Teams – “then accept Features which are being completed Sprint-by-Sprint

FeatureLevel

StoryLevel


epics

TaskLevel Task Definition of Done:

1. Tasks for the Story are completed correctly2. Story Functionality is validated 3. Tasks are reviewed, pair programming where required is completed; tasks and checklists are completed

Complete Tasks

Story

Task

Feature



Elaborate work of Epics into Features, and Stories/Tasks to be

completed



Story Definition of Done:1. All Tasks for a Story are completed2. Story Functionality and Products are validated 3. Story is reviewed and accepted by the Product Owner

Validate and accept tasks as they are integrated into the Story

Feature Definition of Done:1. All Stories within the Feature are done2. Sub-functionality and Products are validated 3. Sub-functionality is reviewed and accepted by the Product Manager and support of the underlying Product Owners

Validate and use acceptance criteria to complete Epics


Program Team’s View – Feature Tracking


Team Execution

Team events create a closed loop system to keep the train on the tracks.

Team events

IterationPlanning

DailyStand-up

BacklogRefinement

TeamDemo

IterationRetro


Program execution – Called the ART – Agile Release Train

Program events create a closed loop system to keep the train on the tracks.

Program events

Team events

Scrum of Scrums PO Sync

Release Management Meetings

System Demo

Inspect & Adapt

PI Planning

IterationPlanning

DailyStand-up

BacklogRefinement

TeamDemo

IterationRetro

Prepare for PI Planning

ART Sync


Agile Release Train – The ART

4Align 50-125 practitioners to a common mission

4Apply cadence and synchronization, Program Increments every 6-12 weeks

4Provide Vision, Roadmap, architectural guidance

D

CA

P

D

CA

PD

CA

PD

CA

PD

CA

PD

CA

PD

CA

PD

CA

P


Demonstrates the full system every two weeks

4An integrated solution demo

4Objective milestone

4Demo from the staging environment, or the nearest proxy

Full system

SystemTeam


How Support / DevOps Teams integrate


Why DevOps is so interesting (lol)

Continuous Planning

Continuous Integration

Continuous Deployment

Continuous Monitoring

Continuous Quality

Asso

ciat

ed T

echn

olog

ies

Key

Dev

Ops

Pra

ctic

es

Ove

rarc

hing

Prin

cipl

es

Log Monitoring

App Monitoring

Sys Monitoring Dashboard

CONCEPT DEFINE DELIVER DEPLOY EVOLVE PRODUCT

1

2

3

4

5

Environment Provisioning

ConfigMgmt

Deploy Automation

Release Automation

DB Deployment

Mobile Deployment

Code Inspection

Test Automation

Profile, Perf & Load Test

Service Virtualization

Test Data Management

Mobile Testing

6 Platform

Con

tain

erC

aaS

PaaS

IaaS

VM

Agile ALM Test & Defect Mgmt.

Release Mgmt. ITSM Design

Tools

Dev EnvCode & Binary

RepositoryBuildTDDCode

Tools CI CollabTooling

Mobile dev Platforms

Prototype Tools

Continuous Delivery Experience

Continuous Planning

Continuous Integration

Continuous Deployment

Continuous Monitoring

Continuous Quality

Asso

ciat

ed T

echn

olog

ies

Key

Dev

Ops

Pra

ctic

es

Ove

rarc

hing

Prin

cipl

es

Log Monitoring

App Monitoring

Sys Monitoring Dashboard

CONCEPT DEFINE DELIVER DEPLOY EVOLVE PRODUCT

1

2

3

4

5

Environment Provisioning

ConfigMgmt

Deploy Automation

Release Automation

DB Deployment

Mobile Deployment

Code Inspection

Test Automation

Profile, Perf & Load Test

Service Virtualization

Test Data Management

Mobile Testing

6 Platform

Con

tain

erC

aaS

PaaS

IaaS

VM

Agile ALM Test & Defect Mgmt.

Release Mgmt. ITSM Design

Tools

Dev EnvCode & Binary

RepositoryBuildTDDCode

Tools CI CollabTooling

Mobile dev Platforms

Prototype Tools


Release Planning in SAFe

using Kanbans



Team Level Level 1


Release Planning


Agenda


Teams primarily operate using the Daily Stand-up & Sprint Planning Ceremonies

Team ExecutionDaily

Sprint

Release

Roadmap

Vision

Team Focus


Executives are less interested in Sprint work, And more interested in the Roadmap & Functionality Deliverables;

i.e. the progress on the Release Backlog

Executive’s Focus

Daily

Sprint

Release

Roadmap

VisionExecutive Focus

Team Execution


Release Planning enables Roadmap Level Planning for a single Release

RoadmapPLM Modules

Release 1(Prototype 1)



Sprint 1

Sprint 2

Sprint n

Sprint 21

Sprint 22

Sprint n

Sprint 11

Sprint n

Timeframe: Months

User Story

1

User Story

2

Timeframe: 2-3 weeks

Timeframe: Multi-year


Executive Focus

Team ExecutionDaily

Sprint

Release

Roadmap

VisionExecutives need to be able to communicate release backlog

changes down to teams

Teams need to be able to communicate the required Sprint changes needed for roadmap requests & their

progress up

Executives like to see measurable Roadmap progress


Release PlanningThis ceremony aligns the demand of the executives with capacity of

the teams; on a regularly scheduled basis

Daily

Sprint

Release

Roadmap

Vision

The SAFe Release Planning (PI) Ceremonyprovides a forum for Executives and Teams

to come together

Executive Focus

Team ExecutionPlanned, Periodic, Productive Re-synching

The Release Planning CeremonyPlanned, Periodic, Productive Re-synching

6.70© 2016 Scaled Agile, Inc. All Rights Reserved.© 2016 Scaled Agile, Inc. All Rights Reserved. 6.70

Big Room Planning – Release Planning

• Lots of wall space so that each team can have their flip chart sheets on the wall (6–7 per team)

Main Screen projecting slides

For tables with distributed team members, there is a laptop with a webcam/audio which is connected to a laptop/webcam at the remote location(s). Ensure you have a high bandwidth connection.

Projector & Laptop

Project, Laptop, audio

Projector & Laptop

Easel Easel

Polycom Webcam& laptop

PLUS a Polycom phone if not part of the hotel

audio system

• Tables are grouped by train and team

13

MgmtReviewTable

Guest Chairs

11

10

9

14

7 6

12

1

8

15

5 4

2

3


The Wall - “Pre-Planning for the Big Room Planning” Exercise


Sprint 11 Sprint 12 Sprint 13 Sprint 14 Sprint 15

RELEASE OBJECTIVES RISKS

Velocity: 34Load: 30




Velocity: 34Load: 0

Objectives /Business Value1. ….2. ….3. ….

Stretch Objectives1. ….

X

Team Planning – Detail and Guidance for their Walls

Yellow

Purple

RedGreen

Orange

= Risks and Dependencies

= Infra / Tech Features

= Features

= Spikes

= Stories

For velocity, use historic information or

8 x (number of developers + testers)

Be sure to adjust for holidays and vacation.

Red = Addressed Risks and Dependencies

Color coding gives visibility into investments

Velocity (Capacity): ____Load: ____


Release Planning – Output from Release Planning / Big Room Planning


Inputting Features / Stories into Sprints in JIRA


Portfoliosin SAFe

using Kanbans



Team Level Level 1


Release Planning


Agenda


Kanbans in SAFe

Epic

Feature

Feature

Feature

Feature

Enabler

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Por

tfolio

Pro

gram

Team

Portf

olio

Ba

cklo

g

Enabler

Enabler

Feature

Feature

Feature

Feature

Capability

Valu

e S

tream

Capability

Capability

Enabler

Enabler

Enabler

Valu

e St

ream

Back

log

Prog

ram

Back

log


Portfolio Level 3

Portfolio Level

Epic

Feature

Feature

Feature

Feature

Enabler

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Por

tfolio

Pro

gram

Team

Portf

olio

Ba

cklo

g

Enabler

Enabler

Feature

Feature

Feature

Feature

Capability

Valu

e S

tream

Capability

Capability

Enabler

Enabler

Enabler

Valu

e St

ream

Back

log

Prog

ram

Back

log


Epics / EnablersExecutives / Product Execs /

Portfolio Owners

Features / EnablersProduct Manager

Stories

Product Owner

Sprint TeamsDemonstrate Story

FunctionalityIn Sprints

Product Management / Program Mgmt.( PMO)ensure progress is made towards the committed

Featuresacross Sprints

Execs / Portfolio Ownerensure progress is made towards the committed

Epicsacross

Releases

Product Management and Program Management


Additional Roles at the Portfolio Level

Level 1Team Level

Delivery L2Program Level




RolesProduct Management

Program Management Team / PMOEnterprise Architect

Implementation TeamDevelopment, Test, Architecture, Data, Reporting & Infrastructure Leads

End to End Testing, Automation, Performance TestingEnterprise Architect & Architecture Review Board

Roles

Portfolio Owner / ExecutiveProgram Director / VP

Chief ArchitectPortfolio Level



Epic

Feature

User Story

Epics are collections of Epics, • Epics typically span 3-6 months in duration to complete • Epics span across releases (ex: SAFe SI – (S)hippable (I)ncrement)• Epics can span more than one team • Epics are the things that the market / clients / end users care about.

The Model above the Feature - that allows the crossing of Releases

User Stories are the smallest increment of value, • User Stories typically are completed in less than a week. • User Stories are contained within the Sprint• User Stories are what Product Owners care about

Features are larger than Stories• Features typically span 2-6 weeks in duration • Features are contained within releases• Ideally, Features are contained within a team• Features are what Chief Product Owners care about

6.83© 2016 Scaled Agile, Inc. All Rights Reserved. Confidential and proprietary information

Feature

Story

Task

Epic

Feature

Story

1 Sprint

1 : M

1 : M

Epic

Functional Area

Roadmap

Task

1 : M

1 : M

1 Sprint

1 Release

More than 1 Release

Ongoing Roadmap

Portfolio Teams primarily focus on Epics and Roadmap items


Portfolio Teams primarily manage the breakdown and acceptance of Epics and Roadmap items

(2 Week)

(Quarterly)

Sprints

Releases

(Annually)


FeatureLevel

EpicLevel

Vision / RoadmapLevel

StoryLevel

Story

Epic

Story Definition of Done:1. All tasks for a Story are completed2. Story Functionality and Products are validated 3. Story is reviewed and accepted by the DHCS Business Product Owner with support of the Xerox Technical Product Owner

Feature Definition of Done:1. All Stories within the Feature are done2. Feature Functionality and Products are validated 3. Feature is reviewed and accepted by the Business Product Owner with support of the Technical Product Owners

Epic Definition of Done:1. All Features within the Epic are done2. Epics are validated, including UAT 3. Epics are reviewed and accepted by the Product Manager with support of the Product Owners

Roadmap Definition of Done: 1. All Epics within the Roadmap are done 2. Roadmaps are validated, including UAT 3. Roadmap is reviewed and accepted by the Portfolio Owner with support of the Product Managers and Product Owners


epics

Module – HCM Oracle Cloud(Portfolio Epic in SAFe)

(Epic in Rally)

TaskLevel

Task

Task Definition of Done:1. Tasks for the Story are completed correctly2. Story Functionality is validated 3. Tasks are reviewed, pair programming where required is completed; tasks and checklists are completed

Validate and accept Stories and their functionality and products as they are integrated into parent epics

Roadmap

Feature

Validate & accept Epics and their functionality and products as they are integrated into parent Themes

Validate and accept tasks as they are integrated into the story

Complete Tasks

Validate & accept Roadmap items

Define and organize the work into Roadmap(s)



Elaborate work of Epics into Features, and Stories/Tasks to be

completed



Elaborate Roadmap work Features & Stories/Tasks to

be completed


Story Backlog Task Backlog In Process Task Done Story Done

Analysis Design Build Test Deploy

Inception Elaboration Construction Transition

Story Backlog Task Backlog In Process Task Done Story Done

User Story

Analysis Design Build Test Deploy

Feature

Idea Business Case Build Measure

Epics Portfolio Level 3 – Kanban (Kanban for Epics)

Delivery Level 2 - Kanban (Kanban for Features)

Delivery Level 1 – Scrum(ban) (Team use of Kanban for Stories & Tasks)

Portfolio Teams primarily use the Portfolio Kanban to mange Epics and Roadmaps


Portfolio View – Kanban to move through the funnel

Some Additional Guidance



SAFe Portfolios

In larger Enterprises, there will be multiple SAFe Portfolios, each helping to manage a set of initiatives, typically at the business unit or departmental level.


Functional Guidance & Governance

Governance

Portfolio

Functional Guidance


Program Escalation

Program events create a closed loop system to keep the train on the tracks.

Program events

Team events

Scrum of Scrums PO Sync

Release Management meetings

System Demo

Inspect & Adapt

PI Planning

IterationPlanning

DailyStand-up

BacklogRefinement

TeamDemo

IterationRetro

Prepare for PI Planning

ART Sync


Escalation Model – for Level 1, L2 and Portfolio Levels

Sr. Executive Team

Program Steering Committee

Scrum of Scrums

Team Stand-up(aka Daily Stand-up)

Issues, Action Items, & Impediments

• Occurs daily • If an impediment is identified which cannot be resolved that day,

it is escalated

• Occurs 2x per month prior to 1 PM • If an issue or action item is identified which cannot be resolved in 24 HOURS;

it becomes an issue, & is escalated as needed

• Occurs as needed (later in day 5:00 PM)• If an issue cannot be resolved within 48 HOURS,

it is escalated to this level as needed

• Occurs 2x-5x per week• If an impediment is identified which cannot be resolved in 24 HOURS,

it becomes an issue or action item, & is escalated as needed

POSM ARCH.


Dev / Test Leads


Epic Boards and Dependency Charts

1. Built at Release Planning 2. Owned by ScrumMasters at the Team Level 3. Owned by Program Mangers at the Feature Level 4. Owned by the Program Director at the Epic level

Dependency Chart - EpicsExternal

DependencySIZED Capacity RiskTO BE SIZED

EPICDocument

Conversion Service

Time / System

Events Sequence

EPICEnhancements to

support distribution to WebCenter 360

EPIC

Resource Library Enhancements - 1

EPICCM: Support Fax & SMS

EPICReporting and SSO

Integration

Decreasing “O

ptionality” - i.e. lower priority (m

ay not needed for imm

ediate release and qualify for MVP)

USER STORYCM: Support

Reporting Integration

USER STORY

PNR to use new attachment

Links* USER STORYGDM to support new attribute "Recipient Disclosure Ur l" on

Recipient*

EPICGDM

Enhancements

EPIC

Basic Analytics

EPIC

Kill Release

EPICCM: Support Fax & SMS

EPICResource Library Enhancements - 2

USER STORY

Login As Customer user

USER STORY

Audit: Utilize Nverse -

Application

EPICReference Data Localization: Application-specific Changes

Capacity available

EPICReporting and SSO

Integration

EPICReporting Refresh

USER STORYSecure

Uploader + DCS

USER STORYEnhance CM Search (POC)

USER STORYIncorporate Search (solar

based API) in Contact management track

USER STORYLogin as User Core

API changes

USER STORY

Audit Support & CM POC

USER STORYAudit Support &

CM POC

USER STORYRef Data

Localizat ion

Broadcast Engine

Adobe Omniture Setup in Cloud

1) NDE to implement Kill Release

2) GDM to add configuration in GDM DB

USER STORY

Support Reporting Integration*

USER STORY

Story not added in V1

London Team to provide Resource Lib – logo

tagging

EPICRelease Status

Reporting

USER STORYRelease status

reporting – screen and PD dependency

USER STORYAdmin changes

for Login As Customer user

USER STORY

Login As Customer user

USER STORY

Logo support needed for RL-2

EPICSupport Fax &

SMS

EPICSupport Fax &

SMS

User Story: Recipient

Test Service

Sprin

t 8Sp

rint 9

Sprin

t 10

Sprin

t 11

Sprin

t 12

Sprin

t 12

PSR Catalog CPQ Order Mgmt. Dashboard NFR’s Integrations Reporting Core Platform




Team Level Level 1


Release Planning


Agenda


SAFe 4.0 recognizes a set of connected Kanban systems

Program Kanban


Value Streamsin SAFe

using Kanbans



Team Level Level 1


Release Planning


Agenda


Kanbans in SAFe

Epic

Feature

Feature

Feature

Feature

Enabler

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Por

tfolio

Pro

gram

Team

Portf

olio

Ba

cklo

g

Enabler

Enabler

Feature

Feature

Feature

Feature

Capability

Valu

e S

tream

Capability

Capability

Enabler

Enabler

Enabler

Valu

e St

ream

Back

log

Prog

ram

Back

log


Portfolio & Value Stream Levels – Are managed the Same

Portfolio

&

Value Stream

Level

Epic

Feature

Feature

Feature

Feature

Enabler

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Por

tfolio

Pro

gram

Team

Portf

olio

Ba

cklo

g

Enabler

Enabler

Feature

Feature

Feature

Feature

Capability

Valu

e S

tream

Capability

Capability

Enabler

Enabler

Enabler

Valu

e St

ream

Back

log

Prog

ram

Back

log


Progress by Business and Support AreasRelease Velocity and ROM

Functional Business Area Projected VelocityTotal ROM Release 3 ROM Distribution

Completed Story Points

Total ROM Remaining

% Complete (Completed Story

Points vs ROM)0 Care Management 132 1,933 6% 1 1,932 0%

62 Financial Management 405 8,965 29% 574 8,391 6%80 Member Eligibility & Enrollment 309 3,774 12% 648 3,126 17%0 Member Management 27 480 2% 0 480 0%

24 Operations Management 491 9,813 32% 213 9,600 2%0 Performance Management 90 1,320 4% 0 1,320 0%8 Plan Management 169 1,624 5% 79 1,545 5%0 Provider Eligibility & Enrollment 22 389 1% 1 388 0%0 Provider Management 162 2,608 8% 0 2,608 0%

174 1,807 30,906 100% 1,516 29,390 5%Support Area

16 Architecture 16 576 7% 71 505 12%79 Data Conversion 79 1,278 17% 420 858 33%19 Infrastructure 19 1,122 15% 177 945 16%0 Interfaces 0 427 6% 0 427 0%

58 PMO 58 1,080 14% 207 873 19%4 Training 4 300 4% 29 271 10%

14 Transition 14 2,910 38% 120 2,790 4%190 190 7,693 100% 1,024 6,669 13%

Total 364 1,997 38,599 2,540 36,059 7%

Func

tiona

l Co

ordin

ated S

uppo

rtRelease – Velocity and ROM

introduction kanban with safe at scale

Documents