Experiments that have worked for me in the last 7 years playing with Scrum in Agile teams. The presentation covers 4 key pilars of Scrum: - Roles: Product Owner, Scrum Master and Development Team. - Scrum Events: Planning Meeting, Daily Stand-up, Grooming/Refinement, Demo and Retrospective. - Scrum Artifacts: Product Backlog, User Stories, Definition of Done, Sprint Backlog, Sprint Dashboad. - Reports: End of Sprint Report, New Sprint Report, Burn-up/Burn-down, Product Report.

1. Scrum à la Pablo
Experiments that have worked for me in the last 7 years playing with Scrum

2. 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
Certified
Professional
Scrum Master
Scrum.org

3. The presentation contains experiments that worked
with 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.

4. 1. Roles
2. Meetings (events)
3. Tools (artifacts)
4. Reports
What we’ll cover

5. Product Owner
• Product Backlog Mgt.
• Resolves business
doubts.
Scrum Master
• Helps with Scrum
• Removes
impediments
Development Team
• Manages sprint
backlog
• Finishes tasks
Roles

6. • 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

7. Daily
Scrum
Daily
Scrum
Sprint
Planning
Daily
Scrum
Grooming Demo Retro
Meetings (Events)
Daily
Scrum
Daily
Scrum

8. • Instead of starting on Mondays, I’ve seen it working better on
Tuesdays/Thursdays
• The schema I’ve seen with better results is:
Phase I: Review of candidate
user stories
• PO + Dev team
• Review candidate user stories
for the sprint
• Clarify doubts from Dev Team
• Around 15-30 min.
Phase II: Break into smaller
tasks 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

9. • 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

10. • 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 there
aren’t any holes in them. If there are, PO has time to review them with
stakeholders.
• 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

11. • 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

12. • 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

13. Meetings:: Calendar example
1-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

14. 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)

15. • 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 the
stakeholders and the rest of the org.
• There is only 1 product backlog for the dev team.
Tools:: Product Backlog

16. • 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

17. Tools:: Care level
Care level
Code
quality
Summary Example (Amazon)
One-night
stand
Low
Low risk, low-medium usage, pending validation,
likely to change
A/B test in an informative landing
Summer
romance
Medium
Medium-high risk, low-medium usage, pending
validation, likely to change
Experiment in the buying funnel
It’s official High
Low risk, low-medium usage, validated
knowledge, not likely to change
Changes in the user’s profile
Meet the
parents
Very high
Critical, medium-high usage, high impact on
users, validated knowledge, not likely to change
Integration of a new payment
platform
Wedding Extreme
Critical for the product performance, validated
and not likely to change
Processing of acquisition and
delivery

18. • 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)

19. • User stories/items from the Product backlog that will be done during next
sprint.
• 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 the
sprint.
Tools:: Sprint Backlog

20. • 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

21. Tools:: Dashboard Example
ToDo InProgress Buffer
Peer
Review
Testing
Pre
Ready to
upload
Testing
Prod
Done Blocked
Fire
Must
ASAP
SPRINT BOARD
FIREFIGHTER BOARD

22. • Table next to the dashboard with all the tasks and their initial
estimtes.
• When a taks reaches the Done column, the real effort invested is
added 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

23. 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 story
points 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 the
plan for the next one.
• Product report: It is sent to all the stakeholders with details about the
progress of the product.
Reports

24. Reports:: Burn-up / Burn-down
http://www.burndowngenerator.com/

25. • 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

26. Reports:: New sprint

27. • 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

28. Reports:: End of sprint

29. • 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

30. Reports:: Product

31. 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/

32. Pabgarm (at) Gmail (dot) com
@pabgarm
https://es.linkedin.com/in/pabgarm
Thanks!
For any doubts, questions or feedback, feel free to contact me: