Photo by Scott Graham on Unsplash

A Practitioner’s Brief Guide to Scrum

Philip Rogers
A Path Less Taken
Published in
5 min readAug 10, 2023

--

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:

--

--

Philip Rogers
A Path Less Taken

I have worn many hats while working for organizations of all kinds, including those in the private, public, and non-profit sectors.