This Post is part of  Scrum Master Series

Sprint Zero:

Overview of the main backlog items (legacy bugs, Infrastructure Items, Analysis Work)

Dividing large Epics into small stories that allow prioritization by PO considering Return on Investment (ROI)

Product Backlog

Backlog Items should describe the what not the how they can take the form of User Stories

"As a <some Role> I want <Something> so that <Some Benefit>"

User Stories Should Meet the I.N.V.E.S.T Criteria

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

On backlog: research Spikes, artifacts required by the organization

Not on backlog: tasks level work (code, design, etc.)

Team estimate tasks by relative team effort, planning poker approach can be used

Sprint Planning One

Includes Product Owner, Scrum Master & Team, PO identifies highest priority backlog items

Team estimates how many items it can complete next iteration, meeting takes 4 hours

Sprint Planning Two

Occurs immediately after sprint planning one when PO is gone, team decomposes backlog item into tasks

With effort estimates (4 – 16 hours each), team builds Sprint backlog from those tasks, meeting takes 4 hours

Sprint Backlog

The list of PBIs from the main Product Backlog that the teams commit that they will be able to deliver in the next sprint

Each PBI should be divided into subtasks and prioritized and time estimated

Each PBI should have well defined acceptance criteria description

Done shouldn’t be a big requirement story

PBI story card should contain

• Title
• Description "as a <> I want < …"
• Size ( from the planning poker)
• Priority ( Return on Investment ROI )
• Done Description ( Acceptance Criteria )

PBI story card can be wiki or SharePoint item that the team can access easily

Daily Scrum

The daily team meeting where member describes there current / past work and problems facing them

The daily scrum happens in front of a task board and burn down chart

The daily scrum contains the following sections

• Sprint Back log list (PBI story cards)
• Tasks : the sub tasks of each PBI
• WIP : work in progress by the team
• Done : the task finished by team and meets the acceptance criteria

By the burn down chart the team should be able to say how much time is left to complete PBIs

Sprint Review

During Sprint review team present to the PO product increments, identify any missing features

Gain acceptance from Product owner and review Sprint Velocity

Sprint Velocity is the sum of PBI values(S, M, L …) completed during that sprint

Sprint velocity is not a measure for performance because it depends on the estimates

If one of the PBI needs refactoring it is considered done and added to sprint velocity

If velocity is not predictable after 3-4 sprints then we have a problem   �

First sprint should be confusing

Sprint Retrospective

Discussing + what went well and ∆ what should we change about the process

Use sticky notes for writing +and ∆, collect notes from team then group and prioritize them

To be ready for discussion, output should be things we can do to change impediments and

Organizations problems, ∆ notes should be the form of required change not the problems

This is more proactive.

In bad political companies it is better to let the team do it without MS, PO or mangers to feel more open

Backlog grooming

After each Sprint some new PBIs are introduced and some old PBI needs refactoring

Sometimes Product owner should spend time doing the following

• Review Highest Priority stories
• Re write weak stories
• Split Epics
• Refine Acceptance Criteria
• Re Estimate Stories
• Re Prioritize stories