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.

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