A Practitioner’s Brief Guide to Scrum
This guide offers observations about Scrum, based on my own experiences with its application in the wild. In writing this, I strove to be consistent with what is articulated in the Scrum Guide.
Scrum in a Single Paragraph
Scrum can help teams deliver value frequently to customers. By design, it is incomplete, since its focus is on practices that are necessary to support its three pillars (Transparency, Inspection, and Adaptation). To enable frequent delivery, Scrum seeks to optimize predictability while also controlling risk. Scrum also seeks to harness the potential of the people who have the skills to do the work, while setting delivery expectations among Scrum Teams and their stakeholders. Scrum also strives to make organizational headwinds more apparent, so that people can take steps to improve how they’re working.
Situational Application of Scrum
Let’s consider a few common situations and how they might be approached by a Scrum Team:
- Planned Work
- Unplanned Work
- Blocked Work
Planned Work
Scrum takes the following approach to planned work:
- Work that a Scrum Team intends to do is articulated in a Product Backlog, with the most important and well-articulated work items at the top of the list.
- During Sprint Planning, Developers select high-priority work items from the Product Backlog, partnering with the Product Owner, with facilitation assistance provided by the Scrum Master.
- The Scrum Team selects only as many work items as they think they can realistically complete during the iteration (Sprint), where the Sprint is short in duration (no more than a few weeks).
- Over the course of the planning conversation, the Scrum Team articulates a Sprint Goal, which is a pithy summation of what the team seeks to achieve during the Sprint.
- The selected work items, along with the Sprint Goal, constitute the Sprint Backlog.
Unplanned Work
If a need surfaces to do work during the Sprint that the team didn’t plan to do, the Scrum Team considers:
- Whether doing the unplanned work could jeopardize the Sprint Goal.
- Any other material impact that doing the unplanned work could have on completion of work previously selected for the Sprint.
Based on the above considerations, and their available capacity, the team decides what changes (if any) they need to make to the Sprint Backlog, which may include removal of one or more work items from the Sprint Backlog.
Blocked Work
If work can’t continue on one or more work items, it should trigger a team conversation, either during the Daily Scrum, or possibly ad hoc, where it’s determined:
- Whether the blocked work potentially affects the completion of the Sprint Goal.
- What mitigation strategies are potentially available to reduce the impact of, or eliminate altogether, the block.
- What to work on in lieu of the blocked work, until the block is removed.
The Scrum Team
Scrum is a team-driven approach to getting work done. Key attributes of a Scrum Team are that it is:
- Small. Teams that less than about nine people tend to have fewer problems with staying in sync on the work they’re doing than larger teams do.
- Cross-functional. Teams need to have everyone and everything they need to be successful, with few (if any) external dependencies.
- Self-managing. Teams need to be empowered by leaders to make their own decisions on how to realize the vision and goals associated with the product.
Scrum Team Accountabilities
There are three areas of accountability in Scrum:
- Product Owner
- Scrum Master
- Developers
The Product Owner in 150 Words
The Product Owner (PO) is accountable for maximizing the value of the product and effectively managing the Product Backlog. To maximize value delivery, a PO works closely with a team, ensuring that the work the team does is in line with the needs of the customer. To make customer needs visible, the PO partners with stakeholders and customers to articulate the product vision and goals, making sure the vision and goals are in line with organizational strategic objectives. To manage the Product Backlog, the PO partners with the team to ensure that all work items are prioritized and clearly articulated, and accepts work items as complete. A PO also engages in various customer-facing activities, which may include articulating any changes in team direction and resetting customer expectations accordingly.
The Scrum Master in 150 Words
Servant leadership is central to the work that a Scrum Master (SM) does. First among these facets of servant leadership is service to one or more teams. Facilitation is at the core of service to a team, where the SM helps team members self-manage in the pursuit of value delivery, while also helping address any impediments that might surface. The second facet of servant leadership is partnering with the PO, helping ensure there is team clarity about: 1) what the most important thing to work on is; 2) what the overall vision for the product is; and 3) what the desired outcome is from completing any work item in the Product Backlog. The final facet of servant leadership is to the organization, where the SM seeks to model a continuous improvement mindset, elevate any team concerns that might require leadership action, and ensure there is follow-up to address areas that may negatively impact teams.
Developers in 150 Words
Developers focus on creating value during every Sprint. The specific skills that Developers might have can vary considerably from team to team. Some examples of such skills include being able to code in one or more programming languages, being proficient in code management tools and techniques, creating mockups and prototypes, writing and executing various forms of tests (whether manual, automated, or both), reviewing code written by others, addressing any undesired behaviors that surface during code execution, and writing various forms of documentation. Developers are also accountable for: 1) Co-creating the plan for the Sprint (the Sprint Backlog); 2) Ensuring that there is a consistently high level of quality in the product; and 3) Adapting their plan for each Sprint, as necessary, without jeopardizing the Sprint Goal.
Conclusion
Is there more to Scrum than what I have just described? Most definitely. My primary purpose here has been to briefly describe some key aspects of Scrum that tend to be learned through experience, and yes, your mileage may vary, and your experience may differ from mine. For a deeper dive, see:
