Backlog Management Observations

As an Agile Coach I spend a lot of my time just listening and watching. I try to be the last to speak in meetings and spend a lot of time “in the back of the room,” so to speak. I share my observations with my Scrum Masters so we can learn together. Sometimes I just write out what I see and hear, and ask them to identify improvement plans.

Here is some guidance across four topics on Sprint Backlog management that I have written for, and shared with, all of my Scrum Masters over time. Perhaps some of you will find some value, even some new ideas, here.

"Working on"

Confession: This is a phrase in a Daily Standup that generally infuriates me. In many Standups I have heard this phrase from every developer in the team as they report on their stories in the backlog. In other teams I hear this from only most of the developers. These words provide no information other than 'something is occurring but I won't tell you anything meaningful.'

This lack of depth or context in Standup reports will, and has, severely handicapped some of you as Scrum Masters and rendered you unable to provide details when our management asks questions in the Scrum of Scrums (SoS). This includes shared services Scrum Masters as well as product team Scrum Masters. The reporting phase of the Standup (prior to the 16th Minute or After Meetings) should focus on specifically what has been accomplished in the Sprint Backlog (sub-task, algorithm, completion of unit test, etc.) since the previous Standup, and what the developer or tester specifically plans to accomplish before the next Standup. (They do have a plan for today, don't they?)

Clarity from team members on these two specifics introduces accountability and will assure you, as Scrum Master, that the developer has explicit clarity on the work item he or she has selected.

Rule of Thumb: If you don't have enough information to provide a thorough explanation in the SoS of what Fred has actually accomplished since the last Standup, then you cannot be sure that the developers are achieving the backlog priorities or goals. You also are allowing Fred to avoid his responsibility and you are unprepared to determine if Fred is making any real progress. "Working on" does not signal progress. It is all heat with no light.

Filtering Your Kanban Board Display by Name

I see this in several teams when they display their backlog in the Standup. This practice is a classic example of backlog nearsightedness. Here is why.

Filtering your Active Sprint stories by name (for example, just Fred's stories) is a convenience decision: it does simplify finding a given work item for a team member. And when you filter by name you do have the ability to see if Fred is pursuing his selected work items in proper priority order – but only if Fred's stories are positioned in that priority order.

However, when you filter by name you totally lose the global perspective that defines the priorities for all developers or for the entire sprint.

I will share a small war story from a team I served with a previous client. The team had a Sprint Backlog with 12 stories. Fred had two stories, D and F, that he had selected. Looking at just Fred's filtered stories he seemed to be working them in proper priority. But when I asked the Scrum Master to unfilter the display, it was immediately apparent that story B should be the top priority for Fred. Fred did not select B because he was uncomfortable with some uncertainty about the technology so he jumped to D which was a slam-dunk, low-hanging fruit for him and low in the Sprint Backlog. The Scrum Master was totally unaware of this breach of priority because he only looked at each person's name in isolation, not the total work to be accomplished. Total Scrum Master fail.

The most insidious consequence of filtering the board by name is that it fosters a model of isolated individuals rather than a cohesive team all collaborating toward a common goal. On a product team this can be disastrous. Admittedly, on a shared services team that is mostly reactive to external requests, finding a cohesive target for all team members can be challenging. But on all teams there is high-priority work for a time frame, and there is low-priority work. A holistic view into all the work items can surface issues around priority or possible waste that will not be easily detected in the isolated, filtered view of a backlog.

Define and Design Work Items

Sigh. I am always gob smacked when I see this abuse. We do not do 'Define' stories or tasks, or 'Design' stories or tasks. <sarcasm>How about a story for coding and another for testing? </sarcasm> We don't allow stories for Waterfall phases. There are no phases in agile delivery of value. There are only repeated activities of analysis, design, coding, testing…in every story implementation.

I believe all of you know that we should never have stories for just a) requirements specification, b) problem analysis, c) solution design, and so forth.  So enforce this prohibition. If your Product Owner breaks down work this way, it is your responsibility - with the developers' support - to move all of these activities inside one or more stories that deliver identifiable value, not promote them as stand-alone activities that in themselves are not value.

Please remember that while a story does represent work to be done by your team, not everything your team does is a story. Instead of thinking a story is work, start thinking that a story defines a goal.

Phase-based stories such as 'Define' or 'Design' expose a failure of imagination predicated on a significant inability or ignorance of how to slice stories or other work items appropriately so end-to-end functionality is delivered for a small part of a feature.

In-Flight Backlog Changes

This is a large topic. I will focus on one scenario: your Product Owner makes changes that increase the effort (that is, create additional load) for some stories that are in-flight in your sprint.

First, it is totally allowed for a Product Owner to change existing requirements or add new requirements at any time. Second, it is the developers' responsibility to collaborate with the Product Owner on whether, and when, these changes are allowed into a Sprint Backlog.

Assume your team is in a sprint and during the sprint your Product Owner introduces new requirements that will increase the effort in some of those stories. The developers should quickly evaluate the requested additional load and consequences to existing code.

Then the developers and Product Owner must decide among three options:

1. Accept the changes into the current sprint if the developers see no threat to the sprint even with the additional load. The original sprint time box is preserved and the developers meet their sprint commitment.
2. Accept the changes into the current sprint and allow the changed stories to "roll over" because the load is too great to allow completion of implementation within the sprint. The original sprint time box is preserved, but you are forcing yourselves to compromise your sprint commitment.
3. Do not accept the changes into the current sprint. Create a new epic or stories capturing the changes and place these into the Product Backlog for refinement and future Sprint Planning. The original sprint time box is preserved and the developers still meet their sprint commitment, but two deliveries are incurred to achieve the original plus additional functionality.

The important operational point here is this: Changes will occur at any time, but in-flight backlog changes must be managed in a highly disciplined manner. Your developers must have the courage to “Just Say No” if the changes threaten their sprint commitment.

Summary

Managing a backlog is subtle. There is danger lurking in unexpected areas. Beyond the four topics I offer above, every Scrum Master must be aware of additional traps, such as when low-level technical tasks are called stories, when story sizes are manipulated on roll-over stories, when backlog priorities are not clearly maintained during the sprint, and much more. As an effective Scrum Master you must be vigilant to assure that your team is not just going through the motions of staying busy rather than delivering the correct business value.

I love working with teams and executives to find effective solutions. Email me at gary@effectivescrummaster.com and let's explore how we might partner on your challenges.