Scrum à la PabloExperiments that have worked for me in the last 7 years playing with Scrum

What I’ve been doing so far…

(2008-2011)

Program Manager

Microsoft

(2011-2014)

Product Manager / Product Owner

Softonic

(2015-2015)

Product Manager / Product Owner

Packlink

(2015-2015)

Product Manager / Product Owner

EsLife

CertifiedProfessional

Scrum Master

Scrum.org

The presentation contains experiments that workedwith teams I’ve worked with in the past.

They may work with other teams, or they may not.

The best approach is to give it a try:Keep it if it works.Throw it away if it doesn’t.

1. Roles

2. Meetings (events)

3. Tools (artifacts)

4. Reports

What we’ll cover

Product Owner

• Product Backlog Mgt.

• Resolves businessdoubts.

Scrum Master

• Helps with Scrum

• Removesimpediments

Development Team

• Manages sprint backlog

• Finishes tasks

Roles

• In smaller teams, I think it makes sense that the SM is someone else from the team due to the amount of work the role requires in mature teams.• If a Dev takes on the SM role, his/her sprint capacity will be less (10%-15%)

• In some teams we’ve added the role of Firefighter:• The goal is to keep the rest of the team focused on the sprint tasks.• Works on urgent bugs, giving support to other departments, etc. during the sprint.• The firefighter has less sprint capacity (~10%).

• Design/UX: In theory, a user story should be started and completed within a sprint. Usually, if there’s UX/Design work involved, that’s difficult due to the dependencies between design and development. In the past, the strategy that has worked better for me is to have UX/Design working 1 sprint in advance.

Roles:: Experiments

DailyScrum

DailyScrum

Sprint Planning

DailyScrum

Grooming Demo Retro

Meetings (Events)

DailyScrum

DailyScrum

• Instead of starting on Mondays, I’ve seen it working better onTuesdays/Thursdays

• The schema I’ve seen with better results is:

Phase I: Review of candidateuser stories

• PO + Dev team

• Review candidate user storiesfor the sprint

• Clarify doubts from Dev Team

• Around 15-30 min.

Phase II: Break into smallertasks and estimate

• Dev Team

• Analyze

• Dependencies

• Break into smaller tasks

• Estimate (story points)

• Around 3h (2-week sprints)

Phase III: Define sprint backlog

• PO + Dev team

• Define prioritized sprint backlog

• Define sprint goal

• Around 30 min.

Meetings:: Sprint Planning

• 15 minutes.

• Typical 3 questions (Yesterday, Today, Impediments).

• Only relevant stuff.

• Everyone pays attention:

• Token-passing

• Random order

• Burn up / burn down chart gets updated.

Meetings:: Daily Scrum

• It’s not an “official” Scrum meeting, but I find it very useful.

• PO + Dev Lead.

• Held a couple of business days before sprint Planning meeting.

• PO and Dev review candidate user stories at a high level to make sure therearen’t any holes in them. If there are, PO has time to review them withstakeholders.

• The goal is to have the user stories as defined as posible for the Dev team to

estimate during the sprint Planning.

• It shouldn’t take more than 1h.

Meetings:: Grooming / Refinement

• Only US 100% done are included in the demo (based on Definition of Done).

• Technical tasks, which may not be understood by stakeholders, can be left out.

• Don’t improvise the demo (at least initially). If something fails, it can damage the

credibility of the team in front of the stakeholders.

• When the sprint is closed, the list of US for the demo is sent to the stakeholders.

• It shouldn’t take more tan 1.5h (for 2-week sprints).

Meetings:: Demo

• After the Demo.

• The whole Scrum team attends (PO+SM+Dev Team).

• Review of the commitments from previous demo.

• Summary of sprint highlights in 2 categories:

• What has worked

• What hasn’t worked

Alternative: | More of | Less of | Keep doing | Start doing | Stop doing |

Ideally, everyone gathers this feedback during the sprint and it’s shared during the meeting.

• The team makes new commitments to improve. Each one of those has an owner.

• It shouldn’t take more than 2h for a 2-week sprint.

Meetings:: Retrospective

Meetings:: Calendar example1-week sprint Monday Tuesday Wednesday Thursday Friday

Daily Scrum (15 min) Daily Scrum (15 min) Daily Scrum (15 min) Daily Scrum (15 min)

13.00-14.00

14.00-15.00

15.00-16.00

Grooming

(30 min) Demo

(1h)

16.00-17.00

Retrospective

(45 min)

8.00-9.00

9.00-10.00

Planning

(2h)

10.00-11.00

11.00-12.00

12.00-13.00

1. Product Backlog

2. User Stories

3. Care level

4. Definition of Done (DoD)

5. Sprint Backlog

6. Sprint Dashboard

7. Estimates evaluation

8. Reports

Tools (Artifacts)

• It gets updated only by the Product Owner

• Estimates are only provided by the Dev Team.

• It contains everything that is pending to be done in future sprints.

• User stories, bugs, tickets, etc.

• The user stories have to be understandable by a non-technical audience.

• It is a prioritized list with a decreasing level of detail as you get down the list. The top of the list is, ideally, 100% defined.

• Regardless of the tools used to maintain the backlog, it should be visible and available for thestakeholders and the rest of the org.

• There is only 1 product backlog for the dev team.

Tools:: Product Backlog

• Title: Descriptive title.

• Description: Following the format As…. I need…. So I can….

• The As… is from the end user’s point of view, not from the reporter PoV.

• Due date (optional): Deadline to get the US ready (if applicable).

• Acceptance Criteria: What will be cheked to decide if the implementation cover the initial needs

and if it is ready to be deployed to production.

• Care level: Level of details/effort required, depending on the lifespan of the feature.

• Epic: High level group to which the US belongs to.

• Reporter: Who has asked for the functionality, in case there are doubts in the future.

• Initial estimate: High level estimate from the Dev team.

Tools:: Parts of my user stories

Tools:: Care level

Care levelCode

qualitySummary Example (Amazon)

One-nightstand

LowLow risk, low-medium usage, pending validation, likely to change

A/B test in an informative landing

Summerromance

MediumMedium-high risk, low-medium usage, pendingvalidation, likely to change

Experiment in the buying funnel

It’s official HighLow risk, low-medium usage, validatedknowledge, not likely to change

Changes in the user’s profile

Meet theparents

Very highCritical, medium-high usage, high impact onusers, validated knowledge, not likely to change

Integration of a new paymentplatform

Wedding ExtremeCritical for the product performance, validatedand not likely to change

Processing of acquisition and delivery

• Global definition of what it means that something is done.

• The US is not done unless all the conditions of the DoD are satisfied.

• It is defined by the Dev Team + PO.

Some aspects to take into account:

• Who gives the final OK? (QA, PO, PO+Stakeholders)

• In which environment should it be tested? (Dev, Pre, Staging, Prod)

• Should it include unit test?

Tools:: Definition of Done (DoD)

• User stories/items from the Product backlog that will be done during nextsprint.

• It is closed at the end of the sprint Planning.

• All the stories/items are estimated and broken down into smaller tasks(estimated as well)

• All the tasks are included in the Sprint dashboard.

• New tasks can only be added by removing/postponing others.

• The Dev team commits to deliver all the tasks they decide that fit in thesprint.

Tools:: Sprint Backlog

• It reflects the status of all the stories/tasks/bugs in the sprint.

• It allows to see if there’s any issue/bottleneck based on the distribution of the tasks.

• Ideally, there’s an online and a physical version of the dashboard.

• The online one gets updated on the fly, as soon as there’s a change in the task.

• The physical board gets updated during the Daily Scrum.

• The Dev team is in charge of maintaining it.

• Post-it of different colors can be used to identify different kind of ítems (US, tasks, bugs, different projects, etc).

• There can be extra lanes for unexpected ítems (firefighter): |Fire| Must | ASAP |

Tools:: Sprint Dashboard

Tools:: Dashboard Example

ToDo InProgress BufferPeer

ReviewTesting

PreReady to upload

TestingProd

Done Blocked

Fire

Must

ASAP

SPRINT BOARD

FIREFIGHTER BOARD

• Table next to the dashboard with all the tasks and their initialestimtes.

• When a taks reaches the Done column, the real effort invested isadded to the summary table.

• If there’s a significative difference between the initial estimate and the real effort, the reasons for it are added to the table.

• It will allow to identify the estimates deviations and the reasons, to learn for future estimates.

• It can be discussed during the retrospective meeting.

Tools:: Estimates evaluation

In order to increase the visibility of the product progress, the following can

be used:

• Sprint Burn-up/Burn-down: Monitors the sprint progress in terms of storypoints burnt. It gets updated at the end of the Daily Scrum.

• End of sprint / New sprint: They’re sent to all the stakeholders at the end / start of the sprint with details of how it finished one sprint and what’s theplan for the next one.

• Product report: It is sent to all the stakeholders with details about theprogress of the product.

Reports

Reports:: Burn-up / Burn-down

http://www.burndowngenerator.com/

• Sprint title:

• Sprint number. E.g. Sprint 1.

• Weeks covered by the sprint. E.g. Sprint 15-16.

• Other names: E.g. Star Wars planets, characters from The Simpsons, etc.

• Sprint goal: Defined during sprint planning.

• Sprint capacity: Total capacity based on the individual dev capacities.

• Sprint backlog: List of all the stories/tasks to be done during the sprint.

• Total planned: Total amount of user story points planned.

• Total capacity: Total amount of user story points availble for the sprint.

• Available buffer: User story points not planned.

Reports:: New sprint

Reports:: New sprint

• Planned and done: Tasks initially planned for the sprint and

considered done (based on the DoD).

• Planned and not done: Tasks initially planned for the sprint but not

completed.

• Not planned and done: Tasks not planned during the sprint Planning,

but completed anyway.

• Summary: Summary of the capacity, points planned, points burnt and

points not planned but done.

Reports:: End of sprint

Reports:: End of sprint

• Epic/Functionality summary: Summary of the status of all the

epics/new functionalities planned (usually at a quarter level).

• Scrum team evolution: Evolution of the Scrum team performance, at

a user story point level.

Reports:: Product

Reports:: Product

Scrum guides

Official Scrum guide

• Ken Schwaber & Jeff Sutherland. Creadores de Scrum

• Link: http://www.scrumguides.org/

The Scrum Master Training Manual

• Nader K. Rad, Frank Turley. Management Plaza

• Link: http://mplaza.pm/product/scrum-master-training-manual/

Pabgarm (at) Gmail (dot) com

@pabgarm

https://es.linkedin.com/in/pabgarm

Thanks!

For any doubts, questions or feedback, feel free to contact me: