tl;dr: Scrum is an approach (interface) to allow developers to quickly and efficiently build useful products. By following a few roles and meetings, your team can build more quickly and efficiently, without tripping over common project management shortcomings
Scrum is a common project management paradigm that allows software engineers to efficiently build software. Similar to building and using a CI/CD framework or micro-service framework, it allows software engineers to invest a bit more upfront, and reduce friction and reduce overall work.
Scrum as an interface
Scrum is an interface, in the Java sense of interface, which defines certain roles, meetings and artifacts which a team promises to implement. This interface has been optimized to:
- Minimize meeting time
- Regularize workload
- Keep projects tightly tied to customer need
Unfortunately, most engineers experience with scrum has been ... lackluster (including my own). This is likely due to shoddy or half-assed implementations of the scrum interface, rather than the interface itself.
A core principle of scrum is to quickly build a product, identify feedback, and iterate on the product. This avoids building needless features (clippy), or getting to attached to an inefficient approach.
The atomic unit of time in scrum is a sprint (usually 1, 2, 3 or 4 weeks). During each sprint a team will:
- Produce an atomic, documented and integrate-able unit of work
- Hold each of the planning / recap meetings once
|Role||Brief Description||Primarily works with|
|Scrum Master||Team coach||Product Owner, Developers|
|Product Owner||Work filter||Customers|
Someone familiar with the scrum interface, and responsible for implementing it. Key responsibilities include:
- Identifying and removing blockers
- Coordinating other scrum roles
- Coaching team in scrum interface
- Acting as buffer between developers and external roles
Someone responsible for making sure the product being built is valuable to the customer, and that the extraneous feature requests are removed from the backlog. Key responsibilities include:
- Owns customer relationship
- Owns, filters and prioritizes product backlog
- Accepts backlog items from customer, developers
- Coordinates with scrum master to provide project time lines
People who are able to build the product, and willing to partake in scrum process. Key responsibilities include:
- Estimates effort necessary to complete backlog items
- Accepts backlog item(s) to work on for sprint
- Provides feedback on scrum process
- Provides new backlog items for future sprints
|Meeting||Frequency||Max duration||Brief Description||Input artifacts||Output artifacts|
|Sprint Planning||1 x sprint||Accept work to complete this sprint||Product Backlog||Sprint Backlog|
|Sprint Review||1 x sprint||Review (demo) work completed this sprint||Product Increment||Product Feedback, updated Product Backlog|
|Retrospective||1 x sprint||Review what went well, what didn't go well, and what can be done differently next sprint||Items to change during next sprint|
|Daily Standup||1 x day||15 minutes||Identify blockers, individual status updates|
An opportunity for the team to choose which features can and will be completed by the end of sprint
- Review the filtered and prioritized product backlog
- Accept work that can be completed during the sprint
- Create sprint backlog with features to be completed this sprint
An opportunity to demo work that has been completed, and solicit feedback
- Demo work that has been completed during the sprint
- Gather feedback on current implementation of product
- Update produce backlog w/ feedback
An opportunity to iterate on the scrum implementation
- Review scrum implementation for previous sprint
- Identify what went well, what went poorly, and what should be changed
- Identify one item to change, plan to change it in the next sprint
- Identify blockers
- Individual's status updates
Artifacts act as working documents, concrete interactions between roles, and archival records.
|Artifact||Update Frequency||Owner||Brief Description||Relevant Meetings|
|Product Backlog||Constant||Product Owner||Prioritized list of features that will be implemented||Sprint review, Sprint planning|
|Sprint Backlog||1 x sprint||Scrum Master||List of features that will be implemented by the end of the sprint||Sprint planning|
|Product Increment||1 x sprint||Team||Self contained, deployable product including features on sprint backlog||Sprint review|
A constantly evolving list of features that might be worked on.
- Filtered to remove unrealistic / unnecessary features
- Prioritized, to guide work that is accepted into the Sprint Backlog
- Maintained by the Product Owner, who makes sure that all features bring value to the customer
A list of features that has been accepted for the current sprint.
- Work is taken from the product backlog
- Work can be completed by the end of the sprint
- Work results in self contained, deployable product increment
A self contained, deployable product, that could be released to the customer.
- Sprint: Atomic unit of time, usually 1, 2, 3 or 4 weeks.
- Demo: Present atomic unit of work, created over one sprint, to an audience including technical competent audience members and product customers.
- Feature: Atomic unit of work, generally can be completed by one team member during one sprint (or less). These are features of the product that represent add value to the customer.
- Velocity: (Output) / (Unit time)
Buzzwords / Catch Phrases
Use these words, and people will think you're a pro scrum master.
- Build one to throw away: Quickly build a proof of concept to understand the problem space and data, then start from scratch to avoid technical debt
- Let's put that in the parking lot: Your question is not valuable to the group, or is distracting to the current conversation. Let's save it for after the meeting.
- Inspect and adapt: Evaluate current iteration, use evaluation to inform next iteration
- Have we heard from everyone?: Technique to get everyone to speak / implicit group aporval
- Must have, should have, could have, won't have: Backlog prioritization tool
- Weighted shortest job first: (cost of delay) / (job duration)
- Collective ownership: Everyone on dev team can interact with a resourge (e.g. everyone can modify a database, removing the bottleneck around a database guru)
- Scrum is silent about ...: Because scrum is an interface, it does not care about implementation