I encourage all of our Delivery Leads to measure how effectively they are managing their backlog through the lens of three goals. These goals can be phrased as the following questions:
- Do you have four to six weeks of sprintable stories at the top of your backlog?
- Is your backlog completely estimated up to your next end-of-project milestone?
- Does your dev team understand the project goals through the lens of the stories in your backlog?
If you can achieve all three of these goals, your team will be pretty well situated to reliably and predictably deliver their best product. Let’s dive into each one in a bit more depth.
Four to Six Weeks of Sprintable Stories
What does it mean for a story to be sprintable? It means the dev team perceives that they can complete the story without needing further input from outside of their team. More specifically, for any questions team members may have about a story, the team has either 1) received an answer or 2) been given the autonomy to answer it on their own.
There are a couple of additional points that help make the sprintable designation meaningful. First, only the team whose work is directed by backlog items can decide whether a story is sprintable–i.e., not a Product Owner or Delivery Lead. Second, only sprintable stories should be brought into a sprint plan. Otherwise, what’s the point?
This goal should be the top priority to prevent your team from getting blocked. Achieving it creates a buffer, making it easier to manage a sudden velocity increase (wouldn’t you be so lucky?) or a temporary lack of backlog management due to an emergency or vacation.
Most importantly, achieving this goal will greatly support the team putting off a reliable velocity metric, which is the first of two required terms to predict completion: velocity/total scope = remaining sprints.
Backlog Estimated Up to Primary Milestone
All of our software projects have an overarching date or budget constraint that guides our management. This constraint should be represented in the backlog as a milestone. By “in the backlog,” I mean in a way that everyone on the team can see the last story prioritized to be done right before it’s met and the first one that is considered out of scope and has been prioritized just beyond our milestone.
Once the milestone is identified within the backlog, all stories, bugs, and chores between that milestone and the current status should have a non-zero point estimate assigned by the dev team. No “?s,” “shrugs,” or blanks. This can be tough for a few reasons, and I’ll go into more depth on effective approaches to estimating in another post, but it’s important not to defer estimating an item for any reason.
I find this point scale has a good mix of sprintable, mid-weight, and OMG-IDK values: 1, 2, 3, 5, 8, 13, 20, 40, and 100. It’s also easy to find a deck of planning poker cards using this scale (just make sure to throw out the "?" cards).
Achieving this goal will give you the second term (total scope) that you need to predict completion. With the first two goals met, you should be well poised to start maintaining a burn chart.
Everyone Understands the Project Through the Lens of the Backlog
Another way of saying this would be, “Empower your team with knowledge so they can bring great ideas to the project.”
To achieve this goal, make sure you’ve walked every team member through every story in the backlog, giving them the opportunity to ask questions. While somewhat obvious, this turns out to be something that’s easy to forget–especially if you have new people joining the team, a big backlog, and limited free time.
It is still important, however. Achieving this goal will enable each of your team members to identify mid-term and long-term wins such as, “If we spend a little more time implementing this story in this abstracted way now, these other four stories further out in the backlog will take less than half the time to implement.” How can we expect any such epiphany about four stories a team member knows nothing about?
Well, that’s everything you have to know about backlog management. Ha! NOT! There’s way more: estimation, prioritization, scope control, reporting, story definition, and acceptance. Following these goals will, however, help build a good foundation of backlog management practices for any team able to achieve them all.