Scrum
Ruben D. Canlas Jr. [email protected] • 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.
• Plans are nothing; planning is everything. • – Dwight D. Eisenhower.
Project Management
Outline
• What is scrum?
• Agile principles and values
• How to increase the success of shifting to scrum
4
Activity: Amazing Race
• How would planning be
different if you were in The
Amazing Race versus a
Europe group tour?
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.
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)
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
Scrum is appropriate in high uncertainty (eg software or product development)
-- Based on CollabNet
Traditional Project
Management
Learning or Adaptive Teams
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
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.
Scrum/Agile is Visual: Scrum Team after Daily Standup, reviews and updates tasks
SCRUM
• Agile method for developing software
• Capitalizes on self organizing teams (aka High Performance Teams)
• Based on Lean Principles
Rituals, Practices & Artifacts
Scrum in a Nutshell
s
Roles: the primary stakeholders of Scrum
Rituals & practices: regular activities that the Scrum must perform in order to work well
Artifacts: important documents and related habits
Important
• Sprint Review: to inspect and improve (adapt) the product
• Sprint Retrospective: to inspect and improve the team’s process
Product Backlog sample (owned by PO)
Size estimates: 1, 2, 3, 5, 8, 13, 21, 34, 55, BIG
Sprint Backlog sample (owned by DEV)
Sprint Planning
Zoom in on a critical Scrum ritual
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”
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
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
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
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
Sprint Retro
• What do we need to stop doing?
• What do we need to start doing?
• What do we continue?
Sprint Backlog sample
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.
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.
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
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
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.)
Ideal Dev Team number: 5 to 9 developers including programmers, analysts & designers, GUI designers/
programmers, documentors, etc
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.
Artifacts (Details)
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
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?
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
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
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
Sprint Backlog daily tracking is better if visible
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.