My focus is on making software, coaching Agile/Scrum teams, and being a husband and father--definitely not on blogging--so please do not expect very frequent posts here.

Tuesday, December 1, 2015 Scrum Rubric

Agile is a set of values, and does not imply or require certain practices. Scrum is a framework that says a software product should be developed by a self-organizing team, in multiple fixed-length sprints, in full collaboration with the product owner, using Agile values and principles throughout. Scrum specifies a few practices, but as a framework, it is up to the team to insert many other practices into it.

The following is a guideline on practices to strive for. It is not a maturity model—the goal is not to adopt as many of these practices as possible. It is not a roadmap—do not try to adopt a minimal set of processes at first before adopting others. Instead, it is a menu of options. We recommend you, as a team committed to Scrum, immediately adopt all of sections A, B, and C; adopt as much of section D as you can; and consider adopting any practices in section E.

Following this rubric is not sufficient; you must learn and apply the concepts and stories of Scrum from training, books, other practitioners, and experience, starting with the Scrum Guide. It is possible to adopt most of these practices and still miss the point of Scrum, so do not take this rubric as a gold standard.

(I offer coaching on all these practices.)

A. Agile values and principles – If you don’t follow these, then nothing else matters
  • Value people over process
  • Value working product over documentation
  • Value collaboration over contracts
  • Value responding to change over following a plan
  • A willingness to change any practice, attitude, or relationship that conflicts with the four values
B. The price of admission – If you don’t do these, you ain’t doin’ Scrum
  • A commitment from all to follow the Agile values and principles
  • Empowered, committed, singular, decisive product owner who is always available and interested
  • Self-organizing team with 2-9 most-time members (do not include 40% or lower allocations)
  • A designated Scrum Master on the team
  • Fixed-end sprint iteration of 1-4 weeks
  • A product backlog consisting of all the important known work to be done
  • A sprint planning session starting each sprint
  • A sprint backlog consisting of all the work to be done in the current sprint
  • A scrum each day during the sprint; self-assigned tasks
  • Emphasis in the scrum is on finding and exposing blocks; discussions happen afterward, not during
  • A commitment to daily adjust based on circumstances
  • Potentially shippable working software at the end of each sprint
  • A retrospective meeting every sprint
C. Practices strongly urged
  • Estimating product backlog items using planning poker or other system
  • A formal sprint goal
  • Sprint backlog broken into tasks, estimated in hours remaining, updated daily by the team
  • Work remaining daily burndown chart
  • Regular backlog grooming sessions
  • A well-attended sprint review and demo meeting to stakeholders at or after end of sprint
  • Sprint planning happens the first day after the end of the previous sprint (no gap)
  • A shared definition of “done”
  • A short quality plan
  • Automated unit testing  (for software)
  • Zero compiler warning tolerance (for software)
  • Literally standing up during the scrum
  • Velocity tracking and capacity planning
  • A “Minimum Viable Product first” attitude
  • A refactor-as-you-go attitude
  • A team of generalists and generalizing specialists
  • Steady, sustainable pace; no overtime
  • Fixed-end sprint iteration of 1-3 weeks
D. Practices recommended for most Scrum teams
  • A product owner who reports to the business, not to IT
  • Product owner sits with the team
  • Most product backlog items in the form of proper user stories
  • Swarming on fewer stories at once
  • Spikes whenever needed
  • A technical debt backlog; a commitment to work on technical debt
  • Continuous integration: Automatic builds, automatic testing, automatic code analysis (for software)
  • Asynchronous code reviews (for software)
  • Co-located team; common work area/team room
  • Coding standards (for software)
  • Ad hoc pair programming encouraged (for software)
  • Automated integration tests (for software)
  • Shorter sprints
  • Manual testers on the team (for software)
E. Optional practices to consider for your team
  • User Story mapping
  • Story brainstorming sessions
  • Estimation of ROI using planning poker
  • Test-Driven Development
  • A burn-up chart of completed vs. remaining work in the backlog
  • Light-hearted shame trophy for breaking the build
  • $1 or other light-hearted fine for being late to scrum or other important meetings
  • Pair programming required
  • Continuous deployment
  • Chaos monkey
  • Advanced training
  • Automated behavior-driven and/or acceptance tests
  • Zero bug tolerance
  • Mandatory fun
  • Personas
  • 1:1 retrospectives
  • WIP limit
  • Reserved time for training/self-education
Values to remember throughout
  • The 12 Agile principles
  • Servant leadership
  • Self-organizing team
  • Remove impediments and keep out distractions