The two-day training was fun, challenging, and led to some thoughtful conversations among the participants. Without looking back at the book or notes, here are some of the highlights that stuck with me. Please keep me honest if I’m getting any of this wrong:
- The goal is to create high-performing teams with high levels of commitment, trust, collaboration, productivity, and predictability.
- The basic unit of structure is a small, consistent team of roughly 4-7 people, composed of the product owner, the people who will be doing whatever kind of work it is, and a scrum master who facilitates the process.
- Work periods are divided up into discrete and regular timeboxes. Projects are broken down into a series of self-contained Sprints — usually two- or three weeks long. Sprints are measured in working days.
- Each day there’s a short “daily stand-up” meeting where each member of the team checks in on what he/she did yesterday, what he/she plans to do today, and whether any obstacles that need to be cleared.
- At the end of each Sprint there’s a collaborative review and evaluation to see what can be improved upon as the next sprint begins.
- The unit of problem-solving is the user story, which is a declarative sentence in the following format: As a (user) I can (action) so that (business value). Project goals and tasks are made up of of user stories to address and complete.
- Unlike traditional requirements, user stories are negotiable — they’re what the team uses to explore and define what will need to be done and how best to do it together.
- Any tasks or stories that come up along the way and aren’t agreed upon as part of a sprint can be put into a backlog to be handled in future sprints.
- While a team is in the middle of a Sprint, that Sprint’s overall objectives are fixed and not changeable. But since each one is self-contained, future Sprints can be adjusted. This means that theoretically if a new feature needs to go into the docket after all of the up-front planning discussions have been completed, it could go in around Sprint-and-a-half’s worth of time from when it’s proposed.
There’s more to it, but that should give you a sense of what the process is like. Some of the most enjoyable parts of the training were the exercises that gave us all the chance to experience what it’s like to work within a Scrum team. It’s significantly different from how most of us are accustomed to working, and actually trying it gives you a clearer understanding of how powerful and satisfying it can be to attack problems that way.
Special thanks to Pete for his insightful, patient, and instructive training sessions. We look forward to seeing him again for another round of classes, and to bringing the Scrum to our workflow.