The Scrum Master tactics series are a series of articles in which I write about and explore contemporary techniques that will aid you in your journey as a Scrum Master. The tactics explained stem from my personal experience as a Scrum Master which I accumulated over the years in working with many different teams and contexts. Though each of these tactics have value in their own way, I let you be the judge on assessing this value given your context and apply these tactics whenever you deem appropriate.
Have you ever found yourself in Daily Scrum’s in which the event seems like an individual status report? Do you experience the feeling that team members seem to be and stay on their own little islands given their role in a Sprint? Is your Development Team busy around the clock but little work is actually delivered at the end of the Sprint? Then there might be a possibility that your team trumps individual efficiency over effective delivery of value.
You probably are familiar with the great video of Henrik Kniberg, stating the difference between working effective and working efficient and how these measures can greatly improve results when properly combined. Although Henrik’s movie is spot on, your organization’s core business probably isn’t delivering ping-pong balls. So how do you focus on effectively delivering value while trying to be as efficient as you can possible be?
Visualizing your Sprint Backlog
Most teams I have worked with choose to employ visual management to chart their progress in a Sprint. They choose a board, a space on the wall or some digital tool to visualize their Sprint Backlog. In my experience, those Sprint Backlogs are structured along the lines of the image below:
Example #1: very common Sprint Backlog visualization. Colors reflect specific sub-tasks.
The columns in the Sprint Backlog above are kept to a bare minimum, whereas the team creates sub-tasks of PBI’s with respect to given roles (e.g. analysis-tasks, design-tasks, development-tasks, test-tasks). While there is nothing wrong with this approach, it can lead to ‘individual efficiency’ where team members strongly focus on completing their role-specific sub-tasks, moving from one PBI to the next and losing sight on completing the PBI’s as a whole.
The focus on individual work will only increase if your team decides to employ the three famous, yet very optional questions at the Daily Scrum (‘What did I do yesterday’, ‘What will I do today’ and ‘Is anything blocking me?’).
If you find yourself in this situation, your Daily Scum probably transpires as a status meeting: every member waits their turn to report to you, dear Scrum Master, on what they have been up to. While doing this individual ‘report-out’, other members of the team lose attention, seem preoccupied in thinking what to say when it’s their turn, or just mentally ‘check-out’.
With the teams I have worked with where this was the case, I introduced two concepts to shift the focus from individual efficiency to delivering value as a team.
Concept one: visualizing your Sprint Backlog a little differently… mapping the flow of work
The purpose of Scrum is to deliver a ‘done’ increment each Sprint. The Sprint Backlog should support this objective and be designed in such a way that in just by looking at it, it tells you the current state of each PBI; the Sprint Backlog should articulate the flow of the work, from the moment it is picked up by the Development Team until it’s delivered by that same team. Rather than creating specific sub-tasks for each PBI, more state-visibility can be achieved by promoting these sub-tasks to columns. Sub-tasks like “analyzing”, “developing”, “testing” will be removed and the columns on the Sprint Backlog will read “analysis”, “development” and “test”.
Example #2. Map the workflow by promoting specific tasks as column to improve visibility.
By visualizing sub-tasks as columns, it becomes immediately clear where a certain PBI’s resides in the workflow and will give an indication of which next steps the PBI needs to take to be ‘done’. It will also provide direct feedback on the amount of work in your system and show you instantly where there are bottlenecks or air bubbles in the flow of the work.
Concept two: applying focus by installing a WIP limit
To let the team focus on delivering PBI’s instead of their individual tasks, install a WIP (Work In Progress) limit: each column will be given a number, which translates to a maximum amount of PBI’s that may be in that column and that amount is not to be exceeded. WIP limits force the team to focus on completing PBI’s before starting work on other PBI’s using the ‘pull’ mechanism.
With this new design of the Sprint Backlog in place, the Daily Scrum can be conducted in a different way. Rather than having each team member state what they have done, direct the whole team’s attention to the board. Walk through every item on the Sprint Backlog from the right side to the left of your mapped workflow and ask for each PBI what would be needed to get to the next step in our workflow. So, in case of PBI 1 in the image above, the test column is at it’s maximum according to the WIP limit of 2. In order to deliver, PBI’s need to traverse from ‘test’ to ‘done’ in order to ‘free up’ the queue at the test column and allow for ‘pull’. Provoke therefore discussion within the team on what testing activities are needed to get PBI 1 done, before discussing next PBI’s.
Now, are the team members less efficient with utilization of their working time with this approach? They probably are, but with this approach your team is far more likely to deliver PBI’s in a more effective manner. Efficiency still remains important and should be looked at after the team delivers PBI’s.
To improve efficiency, the team needs to inspect and adapt it’s WIP limits on a regular base to assess if efficiency and flow can be improved by in- or decreasing those limits. Make WIP limits a standard topic within your Retrospective’s to embed it in your cadence and provoke discussion accordingly.
In conclusion
As mentioned, the purpose of Scrum is to deliver a done increment. In order to achieve this objective, PBI’s must be delivered. Focus on the delivery of value rather than keeping individuals busy and let your redesigned Sprint Backlog act as a guide to conduct your Daily Scum events.
View the approach I explained in this blog as an initial starting point: given your context and workflow you might have different roles and tasks within your team. The exact number of your WIP limits is also subjective to your context. Frequently inspect and adapt on the WIP limits you have installed to optimize your flow in subsequent Sprints.