Grooming

Grooming
What is Product Backlog Grooming
Product backlog grooming, also called product backlog
refinement, is the activity of keeping your product up to
date. This is necessary, as your product backlog is likely
to change based on the learning obtained from
developing software and exposing it to customers, users,
and other stakeholders.

Grooming
What is Product Backlog Grooming

Grooming
What does Grooming Entail?
Grooming the product backlog consists of the following
steps, which are described in more detail in my
postThe Product Backlog Grooming Steps:
1.Analyse the customer and user feedback
2.Integrate the learning
3.Decide what to do next
4.Get the product backlog ready: Select a sprint goal
andwrite detailed userstories that are ready

Grooming

What does Grooming Entail?

Carrying out the grooming steps should result in
aproduct backlog that isDEEP:detailed
appropriately,emergent,estimated, andprioritised.

Its Not Extra Work...Its THE Work

Impact of NOT Grooming
The backlog
Looong and
inefficient
Grooming
sprint
planning
Loooong
and
inefficient
standups
Missing
sprint
commitment
s
You build the
wrong thing

PANIC!

Outcome when you DO

Groom the backlog
Shared
understandin
g
Earlier
feedback
Realistic
sprint
commitment
s
You build the
right thing

Grooming
Grooming Patterns

Grooming is an ongoing event. It has no end but rather various states of

readiness
Initial grooming must take into account two things:
Work already in Progress (or a near time Horizon)
Intake of work for the next calendar (2017 Project Lists)
Because we have two patterns, the agenda switches for each pattern:
Minimal work to refine the work already in progress
Refine lightweight Business Case with missing data
Focus on Program grooming
Intake of new work:
Follow Portfolio Kanban Activities
Derive Initiative Value Statement
Refine to Lightweight Business Case
Prepare for Program Grooming

T-shirt sizing Used for Initiatives/Epics

T-shirt sizing is a low fidelity way of estimating the size of work
within a ballpark figure. More akin to Rough Order of Magnitude
(ROM) or Level 0 estimating. Initiatives should not be greater
than 3 Program Increments (PI) in duration. This encourages
smaller batches, smaller queues, and manageable WIP limits.
T-shirt Size

# of Sprints

1 PI

2 PI

3 PI

Factors/Reasons

Around 10-12 weeks in size

Assumes multiple Teams from the ART

May have dependencies with other Value

Streams or ART

Usually Dependency based

If we were to assign numbers to S, M, L such as 1, 2, 3 then

it can be used as a rough approximation for Job Size. This
allows it to be used for WSJF purposes as well as to initially
load-balance an ART.

T-shirt sizing Used for Features

T-shirt sizing is a low fidelity way of estimating the size of work
within a ballpark figure. More akin to Rough Order of Magnitude
(ROM) or Level 0 estimating. Features must be able to be
completed within a Program Increment (PI).
T-shirt Size

# of Sprints

Factors/Reasons

Features that can be done in less than a Sprint

are probably Stories
Mostly 1 team might be shared

3 Sprints

Many User Stories & Enablers

Complexity or Sequencing important

4 Sprints

Usually Dependency based

1 - 2 Sprints

M
L

If we were to assign numbers to S, M, L such as 1, 2, 3 then it can

be used as a rough approximation for Job Size. This allows it to be
used for WSJF purposes as well as to initially load-balance a set of
teams.

Condensed Grooming
Business
Role
Produc
t
Manag
er

Produc
t
Owner

Technology
Description

Responsibilities

Role

Builds, maintains,
and presents vision
and roadmap for a
product (e.g.,
Prospect Services)
based on customer
needs.
Dedicated to a
single product.

Represents
Business in
Portfolio and
Program
Grooming

Encourages
collaboration
between teams and
across value stream
boundaries

Responsible for
writing, prioritizing
and approving the
user stories within
one of the products.
Ensures the pipeline
is full and prioritized.
Dedicated to a
single agile team.

Helps break down

initiatives into
prioritized
Features and
manages the
Manages
pipeline and
prioritizes the
Program and
Sprint pipelines

Ensures
Value
alignment of the
Stream
value streams
Archite
architectural
ct
needs with the
overall
architectural
roadmap of the
company.
Facilitates
Release
release planning,
Train
processes and
Engine
execution.
er
Escalates
impediments and
manages risk.

Works with value

stream
stakeholders to
help ensure
alignment
Facilitates the
Scrum of Scrums

Description

Makes
decisions
regarding
functionality
and priority
within the
sprint
Not all operating
model roles are shown above, but
they have all been defined (e.g., ScrumMaster,
developer, tester, etc.)

Responsibilities

Helps manage risks

and dependencies

Facilitates release
planning readiness:
vision, product
backlog and
meetings

Defined forums which bring key stakeholders together, expedite decision

making and create an atmosphere of trust and transparency (2/2)
Forum

Portfolio Grooming

Attendees Business

Attendees BT

VP
Product Manager

VP
Director
VS Architect
Enterprise Architect
Release Train Engineer

Product Manager
Product Owner

Product Owner

Developer
Tester
ScrumMaster

ScrumMaster
Release Train Engineer
BT Senior Manager

Program Grooming
Value
Stream
Forums
(BT and
Business)

Team Grooming

Scrum of Scrums

Program Increment

Functional
forums
and
communiti
es of
practice

Functional Huddle
Team1
Technical standards
Huddle
Architecture Huddle

1 - There are separate function team huddles for each role

Value Stream Architect

Release Train Engineer
Director
System Tech Lead

All members and partners of

Value Stream

All members and partners of

Value Stream

Product Owner

VP
Director
Senior Manager
Direct Reports

Value Stream Architect

Domain Architect
System Tech Lead

Decision maker

Work will flow from Portfolio level to the teams

and will involve Business and BT at all levels
Goals

1. Business & technical

ideas identified to meet
goals

Portfolio

3.

Value stream

Technology role

Decision makers

Roles dedicated to Value Stream

forum
VP

2.

Business role

Initiatives prioritized,
defined, and estimated

Business
Initiative

Technology
Initiative

Feature A

Initiative 2
Feature C

Feature B

Feature D

Initiative 1

Highest priority
initiatives broken down
into features

VP

Marketing Ops

Risk BT

Marketing Ops

Risk BT

Product
Managers
(PM)

Value Stream
Architect
(VSA)

BT
Director

Product
Managers
(PM)

Value Stream
Architect
(VSA)

BT
Director

Roles outside of
Value Stream
(Coordination is
critical)
Infrastructure

Feature E
Features1 defined,
estimated and broken into
User Stories

Feature A

A1 A2 A3

Feature D

D1 D2 D3 D4

Program

External teams
(Shared Services)

External teams engaged

Product
Owners
(PO)

Kanban

5.

Release Train
Engineer
(RTE)

7.

Demos presented as
soon as each User
Story is completed

Sprint 1

Sprint 2

Sprint 3

Sprint 4

Shared
Services

Demo (Demonstrations of working software )

Story A1: Done, accepted!
Team
Story D3: Done, but now
we want to improve, and
will create a new story

Arch Arch
Arch Arch

Shared
Services
PO1

SM

Dev Dev Dev Dev Test Test

DBA Security
Arch DMSS

PO2

SM
RTE

Team

Domain
Architects

Tech
Leads

Release
Team 1

Agile
Team
System
Team

Team 2

Team

User Stories fully

groomed and delivered
by teams. External
team output integrated.

Kanban

6.

Agile
coach

Dev Dev Dev Dev Test Test

System
Team

4.

Scrum of scrums

Eng Eng Eng

MIS

Work will flow from Portfolio level to the teams

and will involve Business and BT at all levels
Goals

1. Business & technical

ideas identified to meet
goals

Portfolio

3.

Value stream

Technology role

Decision makers

Roles dedicated to Value Stream

forum
VP

2.

Business role

Initiatives prioritized,
defined, and estimated

Business
Initiative

Technology
Initiative

Feature A

Initiative 2
Feature C

Feature B

Feature D

Initiative 1

Highest priority
initiatives broken down
into features

VP

Marketing Ops

Risk BT

Marketing Ops

Risk BT

Product
Managers
(PM)

Value Stream
Architect
(VSA)

BT
Director

Product
Managers
(PM)

Value Stream
Architect
(VSA)

BT
Director

Roles outside of
Value Stream
(Coordination is
critical)
Infrastructure

Feature E
Features1 defined,
estimated and broken into
User Stories

Feature A

A1 A2 A3

Feature D

D1 D2 D3 D4

Program

External teams
(Shared Services)

External teams engaged

Product
Owners
(PO)

Kanban

5.

Release Train
Engineer
(RTE)

7.

Demos presented as
soon as each User
Story is completed

Sprint 1

Sprint 2

Sprint 3

Sprint 4

Shared
Services

Demo (Demonstrations of working software )

Story A1: Done, accepted!
Team
Story D3: Done, but now
we want to improve, and
will create a new story

Arch Arch
Arch Arch

Shared
Services
PO1

SM

Dev Dev Dev Dev Test Test

DBA Security
Arch DMSS

PO2

SM
RTE

Team

Domain
Architects

Tech
Leads

Release
Team 1

Agile
Team
System
Team

Team 2

Team

User Stories fully

groomed and delivered
by teams. External
team output integrated.

Kanban

6.

Agile
coach

Dev Dev Dev Dev Test Test

System
Team

4.

Scrum of scrums

Eng Eng Eng

MIS

CCP as a Shared Service Team

formation
Coach: Mohammad Khan

Shared Service

What is Shared service?

Shifting common administrative activities from
individual business units to a centralized operation
to reduce costs and improve service quality

What it does?

Improves overall efficiency and control while

giving every business unit access to functionally
deep and talented resources.
Enables business units to focus on what really
matters like satisfying customers and developing
new products and services to sustain competitive
advantage.

Shared Services
How service provides
people, processes,
technology,
structures, and
funding will be done.

Shared Services is a service delivery model where organizations

achieve economies of scale through the creation of a separate entity
in which the customers have a degree of ownership and
determines the types of services and service levels provided

Dedicated
Governance Model

Focused on
Selected business
or IT services