This document provides an overview of Scrum, an agile framework for project management. It describes the 3 roles - Product Owner, Scrum Master, and Team Members. It also outlines the 3 artifacts - Product Backlog, Sprint Backlog, and Burndown Charts. Finally, it details the 4 ceremonies or events in Scrum - Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. The document provides details on how each role, artifact, and ceremony works and its purpose in the Scrum framework.
3. Scrum Overview
● Take a prioritized backlog of features
● Deliver potentially shippable increments
of product every 1-4 weeks
● Using 3 roles, 3 artifacts, and 4
ceremonies
● suggested 5-9 people per team
○ scale via multiple scrum teams and scrum of
scrums
4. ● Owns the Product Backlog
● Responsible for the business value of the
product (ROI)
● Client or client proxy
● Usually a business person or domain
expert
● Answers questions about Backlog items
● Needs to learn how to value at the
feature level vs the product level
The Product Owner
5. ● Developers, Testers, DBAs, UX, Ops - no
longer
● Responsible for completing tasks in the
backlog
● No I in team, succeed or fail as a group
● Self-organizing
● Cross-functional
Team Member
6. ● There to facilitate the Scrum
● Protects the team from distraction
● Removes impediments
● Coach/mentor/servant leader
● Works for the team
Scrum Master
7. ● Created/groomed by the Product Owner
● Ordered by business value
● Priority can be a function of value,
technical scope, and technical necessity
Product Backlog
8. ● The tasks from the product backlog that
will be completed this sprint
● product backlog broken into manageable
chunks
● 50-80% capacity
Sprint Backlog
9. ● Shows progress through the sprint
● A measure of success...
(or defeat)
Burndown Charts
http://xprogramming.
com/articles/bigvisiblecha
rts/
10. ● Chickens and pigs
● 3 Questions
○ What did I do yesterday?
○ What am I planning to do today?
○ Do I have any impediments?
● Discussions should be reserved to
interested people in separate meetings
Timeboxed to 15 minutes
Occurs daily
Daily Scrum (Standup)
11. ● Planning Poker
● 2 parts
○ Estimate features, talk about why they are
important (What and Why)
○ Break down the features into small tasks
and grab highest priority features until out
of capacity (How)
Each part timeboxed to 1 hour per week in sprint (ex. 2
week sprint, part 1 - max 2 hours, part 2 - max 2 hours)
Occurs first day of sprint
Sprint Planning
12. ● Show working software to stakeholders
● Take questions and feedback
Timeboxed to 1 hour per week in sprint
(ex. 2 week sprint max of 2 hours)
Occurs last day of sprint
Sprint Review/Demo
13. ● Extremely important
● Reflect on how the sprint went
● Identify things that need to change
Timeboxed to 45 minutes per week in sprint
Occurs last day of sprint after Sprint
Demo/Review
Sprint Retrospective
14. ● Keep to < 10% of capacity
● Break down, analyze, estimate large
stories
● Either a meeting or team available to
help product owner
Optional Sprint Task - Product
Backlog Refinement/Grooming
16. ● The team must agree to a definition
● Coded, unit tested, accepted by PO
● + automated acceptance test in place
● + documented
● + ready for deploy to production
Definition of Done
17. ● Up to the team to choose appropriate
practices
● Start with 2-week sprints, adapt
● Don't start or end sprints on Monday or
Friday (they're the most likely vacation
days)
● Automated Acceptance and Unit Tests
○ TDD and ATDD/BDD
● Continuous Integration
Recommended Practices
18. ● Pair Programming
● Planning Poker
● User Stories
● Communities of Practice
Recommended Practices(Cont.)
19. ● Seed the product backlog
● Build/grab a team
● Make decisions on team rules, definition
of done, practices, technology stack
● Setup version control, continuous
integration, continuous delivery,
architectural skeleton
Sprint 0/Iteration 0/Project
Inception
20. ● The team decides them
● Examples:
○ Late to meeting: penalty
○ Leaving the build broken: penalty
○ No laptops or phones at meetings (except
driver)
○ Definition of done
○ Respect others - keep it short, 1 person
talking at a time, project your voice if on
conference call
Team Rules
21. ● Relative
○ Story points, T-shirt size, etc.
○ Pros:
■ Relative size stays the same, hour estimates per
unit of size should improve
■ Can't be mapped between teams
○ Cons:
■ Harder to learn how to do
■ Can't be mapped between teams
Relative vs Hour Estimation
22. ● Hours:
○ Pros:
■ Easier to grasp
○ Cons:
■ Difference between senior and junior estimates
■ May be taken as a commitment rather than an
estimate
Relative vs Hour Estimation
23. ● Other departments don't accept the
Scrum practices
○ Anything can go on backlog, but nothing will
be worked immediately
○ Non-agile contracts
○ Dependencies with non-agile teams
○ Annual reviews involve ranking people
against one another instead of on team
success or knowledge transfer
Pain Points
24. ● Product Owner isn't full time with team
● We sometimes let sprints go long
● We don't do Daily scrum or sprint
retrospective
● We still throw code over a wall to testers
● Team split between multiple projects
● Not always bad ... but not Scrum
Scrum, But...
25. ● Incorrect metrics
● Hiring
● Furniture police
● Hero team members
● Training
All Dysfunction is Organizational
or Process Related
26. ● Co-located team - 0.6x
● Large scale (Scrum of scrums) - 1.4x
Time Bonus/Penalties
27. Number of Projects
● 1
● 2
● 3
● 4
● 5
● 6
The Myth of Multitasking
Effective Hours per Day
● 5-6
● 4
● 3
● 2.5
● 2
● 1
via Slack by Tom DeMarco
28. Overtime is a Lie
● Overtime over a week will regress to the
mean
○ 1st week you'll get extra capacity
○ After that at best you're getting 40 hours for
the 50 or 60 you're paying for
● More defects
● Employee morale declines
29. ● Succeeding with Agile by Mike Cohn
● Agile Estimating and Planning by Mike Cohn
● User Storied Applied by Mike Cohn
● Agile Retrospectives by Esther Derby and Diana Larsen
● Agile Coaching by Rachel Davies and Liz Sedley
● Agile Software Development with Scrum by Ken
Schwaber and Mike Beedle
● http://www.mountaingoatsoftware.com/topics/scrum
● http://scrumfoundation.com/library
Further References