Scrum Practices: The missing guide #1
The guide to the most commonly used and effective practices on top of Scrum. Part 1 of the series.
The Scrum Guide is minimal — it defines a bare-bones framework, on top of which you are expected to add practices to establish a viable process. If you want to start fresh with Scrum, the framework as described by the guide is not enough to go by. In this series, I will introduce you to some common building blocks of a Scrum-based process. Even if you’re already an experienced Scrum practitioner it’s never a bad idea to go back to the basics, validate your assumptions, and share some best practices. Let’s dive in!
The Sprint Board
This is the guidance we get from the Scrum Guide regarding visualizing our Sprint works:
The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum
…
The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint
(source: The Scrum Guide ™ 2017 https://www.scrumguides.org/scrum-guide.html#artifacts-sprintbacklog)
Despite this open-ended guideline, in practice, almost everyone uses something derived from a Kanban board to visualize their Sprint Backlog. I call it here “the Sprint Board” as opposed to the more commonly used “Scrum Board” to decouple this common practice from the Scrum framework (the Kanban based board is not actually part of the framework, the word “Board” doesn’t appear anywhere in the Scrum Guide) and because the board is typically used to visualize only the Sprint Backlog (when it includes a Backlog column it could be more appropriate to call it a Scrum Board).
The Sprint Board is a set of columns representing the state the work is in (“To do”, “In progress”, etc.), under which the Sprint items are placed to indicate the state they’re in. When using a physical board it is common to use colorful Post-It notes with short descriptive text written with a thick marker for easy reading. The board is placed somewhere visible so everyone can see the state of the Sprint at a glance. During the Daily Scrum, the team typically stands around the board and updates the state of each item together.
Common Sprint Board pitfalls
Too many columns: Some teams believe that the more columns they have the more transparent their board is or the more “comprehensive” their process is. This is a bit of a “more is better” kind of thinking, but actually what we want to strive for is to simplify the process.
Handover bottlenecks: In many teams, specific columns “belong” to specific team members. For example, in teams where only a QA person is allowed to perform a review, tickets that end up in the review column could only be moved out of it by the QA person. Hence, that column “belongs” to the QA. Only they are allowed to move tickets out of it. This kind of approach (mockingly nicknamed “Mini Waterfall”) leads to bottlenecks, where inadvertently the speed of work difference between the different “owners” of columns would lead to tickets accumulating in one of those columns, leading to some of the team having nothing to do while others having their hands full. What you want to strive towards is a board where everyone can participate in moving a ticket towards done, no matter which state the ticket is in.
Organizing the Backlog
The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”.
(source: The Scrum Guide ™ 2017 https://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog)
The Scrum Guide only recognizes Product Backlog Items (PBIs). How these items actually look like is left open by the Scrum Guide. What follows are some common practices to communicate these PBIs.
User Stories
User Stories are a common convention for writing PBIs. Instead of describing the work to be done, they capture the need or wish of the user that the work will fulfill, leaving the implementation details open to discussion.
A common format for User Stories is:
As a …. <role/persona>
I want …. <behavior>
So that … <value>
(source: Mike Cohn, User Stories Applied (Boston: Addison-Wesley, 2004), 135.)
For example:
As a Line Manager
I want to see an overview of my subordinates’ contract expiry dates
So that I can renew contracts on time
The benefit of the User Story over the more straightforward “to do” task is that it encourages conversation by providing context. Imagine we had the following task instead of the above User Story:
Create a table showing the name of the subordinate and their contract expiry dates
It could very well be that when the team implements the User Story they will end up with this exact screen. But it could also be that upon reading the User Story the discussion on how the Story’s intent could be achieved would bring up new suggestions that weren’t thought of when the ticket was created. Maybe instead of creating a whole new screen, the same value could be delivered with less work simply by sending a reminder email before a contract is about to expire?
By providing the context as to WHY we’re building this feature and omitting the HOW, the User Story encourages conversations, unlike the to-do task which simply dictates what is to be done.
Common User Story pitfalls
Technical Persona: You want to avoid choosing a persona that represents a technical role. Examples to avoid: “As a Product Owner I want feature X So that we could later implement feature Y”, or “as a developer, I want unit tests so that the code will be easy to refactor”. These kinds of non-user stories discourage the capturing of intent and return us to thinking in terms of solution. User Stories should only be used to capture the needs of your users or stakeholders. A stakeholder example would be your legal department requesting that the system would be GDPR compliant so that the company would not be sued. That’s a valid User Story.
Too broad of a persona: If all your User Stories start with “As a user I want..”, you’re omitting vital context. Your users are not all the same and their wishes are not uniform. Try to capture the user’s subgroup, state of mind, or intent when they have the need you’re addressing. “As an angry reader I want…” is immediately more evocative than “As a user I want…”.
Epics
Epics are items that are too big to fit into a Sprint (Epic = Long story). In Scrum the team is expected to choose PBIs it can complete within a Sprint when planning. However, not all PBIs are small enough to be completed within a Sprint. Before pulling them into a sprint they need to be broken down further until they can fit, which is often done as part of a Backlog Refinement. Refining PBIs is time-consuming and therefore you typically only want the highest priority PBIs in your backlog refined, those that are likely to be pulled into the upcoming Sprint.
Epics allow you to keep items in your backlog without investing time in refining them. They represent work to be done that only needs actual refinement when their time to be implemented is approaching. At that point, they could be broken down into multiple User Stories so that the work can fit in a Sprint.
Typically the highest priority items in the backlog are User Stories, and as you go down the Backlog you see more Epics.
Common Epic pitfalls
Open-ended Epics: Some management systems (e.g. Jira) encourage the use of Epics as containers for certain types of activities. There could be a “Technical debt” Epic to contain all technical debt stories or “Checkout Page” Epic to contain any work related to that page. Of course, Technical Debt is never fully paid off and the Checkout Page could always use more work, and therefore these container Epic tend to never be removed either, leading to an ever-growing list of immortal Epics that is tough to manage. Create Epics with specific intent and once that intent is captured by Sprint sized stories, remove the Epics.
Highly detailed Epics: The intent of Scrum is to complete work and release working software on a regular basis in order to facilitate learning over your product and your market. Learning is then captured in the backlog by adding, removing, or modifying PBIs. Therefore the content of your lower priority items on your backlog tends to be volatile. You don’t want to spend a lot of time defining these items as their content can and should change as your product evolves. The time you spend defining these items in detail will be wasted once they need to be modified due to changes in the system or the system’s context. The detailing work should come when the Epics are broken down to Sprint sized User Stories.
Putting it all together
The Scrum Guide does not give specific guidance on how to implement its various requirements and therefore the use of additional techniques and processes on top of the Scrum Guide is unavoidable. However, since these techniques are not unique to Scrum it is important to know how to use them in a way that still keeps true to the intention of the Scrum framework.
In this part of the series, I covered some common techniques to organize and visualize the Sprint backlog and the Product backlog following the requirements of the Scrum Guide. In the next part, I will introduce techniques for estimation and planning.
Always keep in mind that these practices are intended to serve the team and their ability to deliver highly valuable products. They are not a goal in itself, therefore do not hesitate to change or drop practices that don’t make sense or don’t deliver results.
Got any must-have practice that you think belongs in this guide? Please let me know in the comments!
