Practicing Scrum

I recently attended an Agile training by Ron Lichty. These notes are my attempt to digest and process this outstanding Scrum workshop, focused on delighting customers and team happiness for our Engineering and Product teams.

Defining Scrum

Scrum is an Agile process framework for teams of less than 10 members. Teams break their work into goals that can be completed within timeboxed iterations, called sprints (usually two weeks). They track progress and re-plan in 15-minute timeboxed stand-up meetings, called daily scrums.

“The point is not to do Agile. The point is to be effective. Agile provides us insights.”

Al Shalloway, agile author

Ideal team

• 5-9 people (max)
• Collocated
• Dedicated
• Focused
• Cross-functional
• Self-organizing

Definition of done

• Entire team participates, including Product Owner
• Prior to coding a single line
• Post it where the team can see it
• Agile: it can change
  • If the current definition of done is getting in the way or not effective, the team can change it at the Sprint retrospective

Project planning

• Entire team participates
  • Product manager brings product backlog stories
  • Only folks who will build it (engineers, designers, etc) do sizing
  • Others (architects, etc) can attend but only as a resource
• 1/2 day, covering 50-150 stories, 3-6 months of backlog
• Always size stories relative to other stories
• Snake sizing / two-pass relative sizing
  • Ron Lichty’s adaptation of the Steve Bockman method, aka the Team Estimation Game

Snake sizing / two-pass relative sizing

• First pass: order all stories by relative size
• Each team member:
  • takes top story from the deck
  • reads it aloud
  • places it to left or right of another story
  • stories on the left are easier, on the right are harder
  • sizing is all relative
  • go with gut
  • aim to get consent from others’ eyes, but consensus isn’t required
  • if others don’t consent, it’s an opportunity for discussion and learning from each other’s perspectives
• Second pass: start at easiest to find dividing line for points
• Use modified Fibonacci: 1, 2, 3, 5, 8, 13, 20, 40, 100
  • 20, 40, and 100 are just huge, huger, hugest.
    • Don’t get stuck on them, they need to be split into smaller stories to make it into a sprint.
• Store snake in order for future sessions
• When new stories arrive that could go into next 2-3 sprints of work, they need to be pointed
  • Lay the snake back out and do more relative sizing

Product business value sizing

• Product Owner, with input as needed from Architects and Tech Leads
• Use same two-pass relative sizing approach, with another deck of cards
• This time ordered by value to business
• Use regular Fibonacci: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987, 1597…
  • Business value for a story can be 1000x more than another story

Product Backlog Items (PBIs)

• User PBI, aka User Stories
  • Product assesses value
• Technical PBI
  • For value pointing, Architect assesses value, and can bring in Tech Leads
  • As a team keep the codebase malleable, paying down technical debt

Backlog

• Before sprint planning, backlog needs 2 1/2 sprints worth of stories ordered by ROI (business value / points)
• Order by ROI, dependencies, and “judgement” of opportunities to learn by consulting with Architect, Tech Leads

Sprints

• Starts with sprint planning
• Ends with demos to stakeholders and a sprint retrospective, aka sprint retro

Sprint planning

• Team pulls cards from backlog, not Scrum Master or Product Owner
• Team decides what’s the most productive they can be and asks Product Owner if that’s acceptable
• Team breaks stories into tasks and estimates tasks in days, smallest 1/2 day
• May write names on tasks

User stories

• A unit of business value
• “As a [user type] I want [to do X] so that [I get value]”
• Testable
• Fits in a sprint (an epic is a story that doesn’t fit)
• A placeholder for communication

Technical debt stories

• 20% of each sprint’s points, or there will be technical bankruptcy
• Can have separate swimlane or same user story backlog

Agile disciplines

• Self-organizing teams means 1 leader at a time
• Like jazz: playing together and playing off each other
• Psychological safety is paramount
  • Everyone talks equally, no one dominates
• Trust and respect are key

Standups

• Daily, 15 min timeboxed
• 3 questions, in context of current sprint:
  • What did I accomplish yesterday?
  • What will I accomplish today?
  • What is blocking me?
• Team moves cards as done, updates card with time spent and time left
• “Fist to Five” vote: are we on track for our Sprint Plan
  • If there are votes below 4, discuss where the team might fall short.
    • Project Owner can then choose what not to do

Sprint Retrospectives

• Team only: product and engineers. No engineering managers.
• Key questions:
  • What’s getting in our way?
  • What can we experiment with?

Scrum ceremonies and events

• Standup: 15 min daily
• Sprint: 2 week duration
• Retrospectives: 1 hour on last day of sprint
• Demos: 15min per team on last day of sprint
• Project planning: 1/2 day relative sizing with 6 months of stories (team and managers)
• Sprint planning: 2 hours on first day of new sprint (team and managers)

Project Workflow

Focus on what matters the most

1. Delight customer
2. Team happiness

“Do as little [design, code, requirements, testing, QA] as possible, and no less.”

John Steele