Slides used to introduce Scrum at the DevCon, July 13, 2013. At the Orange & Bronze HQ, Makati.

1. Scrum
Ruben D. Canlas Jr.
rcanlas@alumni.cmu.edu
• From The Scrum Primer by Pete Deemer, et al. (Available on the web)
• The Elements of Scrum by Chris Sims and Louise Johnson
• Scrum Reference Card by CollabNet.

2. • Plans are nothing; planning is
everything.
• – Dwight D. Eisenhower.

3. Project Management

4. Outline
• What is scrum?
• Agile principles and values
• How to increase the success of shifting to scrum
4

5. Activity: Amazing Race
• How would planning be
different if you were in The
Amazing Race versus a
Europe group tour?

6. Group Tour versus Amazing Race
Amazing Race
Europe Group Tour
Goal
Vague idea of finish line. Some
details available but most are
unclear.
Details known before hand.
Itinerary likely to be followed.
Strategy
Make some plan but be ready to
abandon/adjust per leg of the race.
Stick to the itinerary.
Learning/
coping method
Teams discover new details per leg
of the race. Regular pit stops allow
teams to assess and course-correct.
Rely on tour leader.
Decision
making
Empowered, self organizing teams.
Decisions mostly made by tour
leader.

7. Amazing Race and Scrum
Amazing Race
Scrum
Goal
Big goal (global race) with no idea of
finish line
Big goal contained in Product
Vision. Product Backlog contains
coarse-grained feature list.
How to reach
goal
Big goal broken down into legs per
country. Teams finish each leg of the
race and proceed to next.
Product Backlog broken down into
manageable chunks (sprints) with
shippable products per sprint.
Learning
method
Teams discover new clues per leg of
the race. Regular pit stops allow
teams to assess and course-correct.
Team discovers and refines
features per sprint. Reflection/
inspection after every sprint help
teams to improve.
Adapting to
Surprises
Each team makes own decisions to
adjust quickly to new challenges.
Dev Team and PO make decisions
to adapt to surprises. (SM
facilitates)

8. Self Organizing Teams (aka High Performance
Teams or HPTs)
• Tightly knit
• Empowered to make decisions
• Working to deliver a common goal
• Can surmount any obstacle, solve any problems, no matter what

9. Scrum is appropriate in high uncertainty (eg
software or product development)
-- Based on CollabNet
Traditional
Project
Management
Learning or
Adaptive
Teams

11. The Agile Manifesto
• We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
• Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
• That is, while there is value in the items on
the right, we value the items on the left more.
http://agilemanifesto.org/iso/en/principles.html

12. Make everything
visible or known to
stakeholders: plans,
schedules, issues,
etc
Stop and review
the product
the process
Self-correction
based on results
of inspection
The 3 Scrum
Principles
The Scrum Master must ensure that
the team members adhere to these 3
principles, always.

13. Scrum/Agile is Visual: Scrum Team after Daily
Standup, reviews and updates tasks

14. SCRUM
• Agile method for developing software
• Capitalizes on self organizing teams (aka High Performance Teams)
• Based on Lean Principles

15. Rituals, Practices Artifacts
Scrum in a Nutshell

16. s

17. Roles: the primary stakeholders of Scrum

18. Rituals practices: regular activities that the
Scrum must perform in order to work well

19. Artifacts: important documents and related habits

20. Important
• Sprint Review: to inspect and improve (adapt) the product
• Sprint Retrospective: to inspect and improve the team’s process

21. Product Backlog sample (owned by PO)
Size estimates: 1, 2, 3, 5, 8, 13, 21, 34, 55, BIG

22. Sprint Backlog sample (owned by DEV)

23. Sprint Planning
Zoom in on a critical Scrum ritual

24. Sprint Planning, Part 1
• Goal: Find out what the PO wants and define shared goals for this sprint
PO and Team review high
priority User Stories
Discuss this sprint s goals
and context behind the
product
User Stories = Product Backlog
Items
Team tries to gain insight into
the PO s thinking (what PO
wants)
Notes:
• SM facilitates the process/discussion
• Assumes Product Backlog has been
created and refined with Team s
participation
• Use the Socratic method (Q A) to
discover/uncover more context and
insight
Review Acceptance Criteria
that all User Stories must
meet
Eg: Done means coded to
standards, reviewed,
implemented using TDD, tested
by users, integrated, and
documented

25. Sprint Planning, Part 2 (Overview)
• Goal: Task planning: how to implement the User Stories (Product
Backlog Items)
Notes:
• PO optional in Part 2, but must be
within reach (eg by phone) to answer
questions
• The Team chooses the tasks; PO or
SM does not assign them.
• This increases Team buy-in and
confidence in self-organizing.
Optional: Estimate available
time for this sprint (hrs/day)
Discuss the design of the
solution
Decompose User Stories
into tasks (Sprint Backlog)
Start from first User Stories
(highest priority)
Sprint capacity estimation per
member
Tip: Use whiteboard for more
visual discussion
Members take on sprint
tasks based on capacity
Until all sprint capacity is used
up

26. Day to Day for Scrum (2-week sprint)
• Monday: Sprint Planning: (9-12:00)
• Tue: daily scrum
• Wed: daily scrum
• Thu: daily scrum
• Fri: daily scrum
• Monday: Tue: daily scrum
• Wed: daily scrum
• Thu: daily scrum: Prod backlog
grooming (virtual): PO only
• Fri: Sprint Review; Sprint Retro
Recommended level of effort:
Dev Team must be full time
PO must be be accessible to the Dev Team
SM must be full time

27. Notes on doing the rituals/meetings
• Prefer face to face meetings always
• If not possible, use voice calls or voice internet chat
• Last resort: text-based communication, eg SMS, email, Basecamp
• Reason: face-to-face is faster and more efficient over other methods
• Daily scrums are important because we could instantly find out any delays
and help capture problems and facilitate resolution on a daily basis
• During a Scrum Retro:
• Pick only 2-3 problems to solve in the next sprint (instead of a long list of
resolutions)
• Reason: 2-3 problems are more solveable than a long list of resolutions;
solve the other problems in the succeeding sprints

28. Best practice meeting durations
• Sprint Planning: 2 hrs for a 2 week sprint
• 1 hr per 1 week sprint
• Sprint Demo: 1-2 hrs for a 2 week sprint
• 30-60 min per 1 week sprint
• Sprint Retro: 2-4 hrs for a 2 week sprint
• 1-2 hrs per 1 week sprint
• Story Time (aka Product Backlog Grooming): 60-120 min for a 2 week sprint
• 30-60 min per 1 week sprint

29. Sprint Retro
• What do we need to stop doing?
• What do we need to start doing?
• What do we continue?

30. Sprint Backlog sample

31. The Scrum Team is composed of Roles:
• Product Owner (PO)
• Scrum Master (SM)
• Development Team (DT or The Team)
The Scrum Team is a self-managing team that
focuses on team learning.

32. Product Owner (PO)
• Responsibility: maximize business value (aka return on investment, ROI).
• Defines and owns the Product Vision
• Represents the business and customers
• Owns the Product Backlog
• Identifies and prioritizes product features/stories
• Creates acceptance criteria for stories
• Always available to answer team questions
• Aka chicken
There should be only one PO per project.

33. Product Owner
• Final arbiter of requirements questions
• Accepts or rejects each product increment
• Decides whether to ship
• Decides whether to continue development
• Considers stakeholder interests
• May contribute as a team member
• Has a leadership role

34. Development Team (DT or Dev)
• Goal: delivers the user stories (aka, the product features)
• Builds the product (software, website, new gadget).
• Self-organizes to deliver user stories
• Owns the estimation process
• PO and SM must be able to trust the DT in making estimates
• DT must get better and better at making estimates
• Owns the how to do the work decisions
• Avoids not my job syndrome: must use self-organization to learn how to
overcome obstacles
Ideal Dev Team number: 5 to 9 developers
including programmers, analysts designers, GUI designers/
programmers, documentors, etc

35. Development Team (DT or Dev)
• Cross-functional: includes all expertise needed to deliver potentially shippable
product after each sprint.
• May include people with skills in analysis, development, testing, interface
design, database design, architecture, documentation, and so on.
• Goal is for each member to work out of their comfort zones/expertise and
learn something new
• Decides how best to accomplish the user stories. (PO decides what user
stories to prioritize in a sprint.)

36. Scrum Master (SM)
• Goal: deliver a self-organizing team
• Self-organizing team: a team that embraces the principles of agility:
transparency, inspect, and adapt
• A team that makes problems visible and can self-adjust to solve them
• One way to look at SM role is as facilitator of group learning
• Scrum expert, coach, and advisor
• Must help PO and DT understand and live the Scrum way
• Evangelist: Makes sure everyone (including team and management) buys
into Scrum practices and principles
• Impediment bulldozer: helps the team remove obstacles
• Change management: help lead the organization through the often difficult
change required to achieve success with agile development.
The SM only facilitates. Unlike a Proj Mgr, the SM does not make
decisions about products, priorities, and schedules.

37. Artifacts (Details)

38. Product Vision
• Big picture: True North, The Finish Line
• Identifies the users
• Captures the essence of the product; sells the product to stakeholders
• Objectives
• Defines the value of the product to the organization/users

39. Exercise: writing your Product Vision
1. Who is going to buy/use the product? Who is the target customer?
2. What customer needs will the product address?
3. What product attributes are critical to satisfy the needs selected, and therefore for the
success of the product?
4. How does the product compare against existing products, both from competitors and
the same company? What are the product s unique selling points?
5. What is the target timeframe and budget to develop and launch the product?
6. Who do you need to consult further?
7. What information (documents, flowcharts) do you need? Are they up-to-date? Does
everyone agree to them?

40. Product Backlog
• Force-ranked list of desired functionality
• Visible to all stakeholders
• Any stakeholder (including the Team) can add items
• Constantly re-prioritized by the Product Owner
• Items at top are more granular than items at bottom
• Maintained during the Backlog Refinement Meeting

41. User Stories (aka Product Backlog Item or User
Stories)
• Specifies the what more than the how of a customer-centric feature
• Often written in User Story form
• Has a product-wide definition of done to prevent technical debt
• May have item-specific acceptance criteria
• Effort is estimated by the team, ideally in relative units (e.g., story points)
• Effort is roughly 2-3 people 2-3 days, or smaller for advanced teams

42. Sprint Backlog
• Contains the User Stories chosen for a particular sprint
• From the User Storiess, we create an itemized list of tasks to deliver the User
Stories
• Represents the Dev Team s commitment to deliver for that sprint
• Contains refined size estimates per task
• Visible to the team
• Referenced during the daily scrum

43. Sprint Backlog daily tracking is better if visible

44. References
• From The Scrum Primer by Pete Deemer, et al. (Available on the web)
• The Elements of Scrum by Chris Sims and Louise Johnson
• Scrum Reference Card by CollabNet.