Scrum Definition

A development framework based on empirical process control wherein cross functional, self organizing teams deliver working software every thirty days (or less).

Product Backlog (Rules)

• List of everything we want the team to work on
• Includes user facing features, architectural work, defects, etc.
• Cannot have multiple Product Backlogs for the same team
• Can have multiple teams pull from same Product Backlog
• Prioritized (or ordered) from 1-n
• Priority is owned by the Product Owner
• Flexible: items can be added/removed/edited at any time
• Only items in the current sprint are locked down

Product Backlog (In Practice)

• Items at the top of the backlog have been refined and are at a higher level of detail than lower priority items
• Multiple stakeholders contribute items, including team members
• User-facing items are written as valuable User Stories
• Product Backlog Items are estimated by the team. Current agile practice: Many teams use “Story Points” or some similar method to provide a relative size estimate, vs. a time estimate

Product Backlog (More to Consider)

• Product Backlog is regularly updated and refined. Current agile practice: Many Product Owners meet weekly with the team to refine the backlog
• Refinement includes activities like decomposing large items into smaller ones using a “vertical slice” approach, estimating items, and getting consensus on acceptance criteria
• Supplemented by other artifacts that help provide context (like Product Vision, Road Map, Story Map)

2 Level of Planning

Release Planning

Enable product level decisions such as scope, release date, resources required

Sprint Planning

Enable the scrum team to commit to a specific set of work for a given sprint

Poker Planning

• Iterative, team based approach
• Each estimator has a deck of cards with potential estimates based on a set.
• Product Owner reads a backlog item, brief clarifying discussion occurs
• Estimators choose a card indicating their estimate
• Cards are revealed all at once. Differences are discussed, especially outliers
• Re-vote until estimates converge

Sprint Planning

• Timebox: 2 hours per week of sprint
• Arrive at a commitment to a sprint goal or set of Product Backlog Items (PBIs) to be completed
• Facilitated by Scrum Master
• Product Owner provides details on PBIs and Priority
• Team creates a plan to deliver as much value as possible while meeting the Definition of Done

Definition of Done

• The quality bar each Product Backlog Item must pass
• Whatever the team agrees that EVERY Product Backlog Item must go through to be considered done, potentially releasable software.
• A good definition of done should:
• Be attainable without assistance from outside of the team
• Not include items such as “QE signed off”

Definition of Done (Sample)

• Every check-in has formal code review and feedback integrated
• If story marked as “risky”, used pair programming
• Unit Tests all passing
• Code checked into main
• Tested using pseudo -translation build
• No open bugs for user story. (Bugs are fixed or closed).
• All acceptance tests passing.

The Sprint: Rules

• Product Owner can’t add new items to the sprint once Sprint Planning is complete
• Product Owner can Abnormally Terminate a sprint in the case of an urgent issue. This should be rare for most products. Zero Day security problem/bug Major, urgent revenue opportunity Major market shift
• Team can’t extend the length of the sprint in order to finish items

Sprint Burndown Chart

• Simple tool used by the Team to provide
• a measurement on how close they are to meeting the Sprint Goal
• by the end of the Sprint

Three Questions

• What have you done?
• What will you do?
• What’s slowing you down? (impediments)

Sprint Review

• Timebox: 1 Hour per week of sprint
• Inspect and Adapt the Product
• Collaborative discussion of what was built
• Informal
• No slides
• Minimal prep
• Whole team participates
• Invite the world

Sprint Retrospective

• Timebox: 1 Hour per week of sprint
• “Inspect” process
• Regular opportunity to improve the system
• Done after every sprint
• Whole team participates
• Choose one specific change to make for next sprint

• Easy to learn, hard to master (like ruby?)

• Team Collaboration

• Inspect & Adapt

• Self managed

• Proactive approach

• Scrum + XP (Continuous integration, pair programming, TDD, Refactoring, etc)