We hosted our final Product Stack webinar of the year last week, “Getting in Shape for 2018: Product Management Best Practices.” You can watch the full video below, and join the conversation to stay informed about upcoming events in the new year.
As always, the Q&A portion brought up a number of interesting queries. One of the obvious recurring themes in the questioning concerned the backlog:
Since we didn’t get to respond to every question during the webinar, we’d like to spend more time with them now. Rather than tackle them individually, we thought since there was so much thematic overlap that it might make sense to take a broader look at the backlog itself.
Writing good user stories is a skill every PM should master, but so too should everyone else on the team, including engineers, designers, testers, and support members, since any of these people may be in the position to add stories to the backlog.
This is important, because bad stories can and will wreak havoc on your backlog. Such stories are either defined so poorly that they cause confusion and result in poor execution, or they are too large in scope and are actually many stories masquerading as one. Once you have mastered the story, you are in a position to master the backlog.
In Tracker, one could argue that we have three types of backlog: We have a “doing now” column called Current that contains all the stories the team should be focused on during this iteration or sprint; we have a “to-do next” column called the Backlog, where the product manager or product owner has actively prioritized the next set of stories that the team will work on; and we have a “maybe later” column called the Icebox, where we collect ideas and thoughts on what could be worked on next.
In Tracker, we have three main areas of focus for stories. We have a “doing now” area of the backlog called Current that contains all the stories the team should be focused on during this iteration or sprint. It can sit at the top of the Backlog or be split into its own column or panel. We have a “to-do next” section right after Current, where the product manager or product owner has actively prioritized the next set of stories that the team will work on; and we have a “maybe later” column called the Icebox, where we collect ideas and thoughts on what could be worked on next.
Your Icebox may vary.
We recommend that all team members have access to one shared backlog, and that they work their way down this prioritized list from top to bottom. In other words, they all see the work that is coming down the pipe in the next couple of weeks, but they should only do the tasks that have been determined to be most important first. They can’t cherry pick the things they want to work on. All this being the case, it’s the PM’s job to ensure that there is enough work in the queue to feed the team. The only way for a PM to know if there are enough stories in the Backlog is for the PM to also know how voraciously their team consumes stories.
We’re only going to touch very cursorily on this next topic. For the PM to properly stock the backlog with stories, they need to know the average number of stories their team consumes on a weekly basis. You can’t simply count the number of stories completed on average, over a period of time, for the simple reason that not all stories take the same amount of energy or time to complete. Each story needs to be weighed on its own merits, and its caloric value determined. That means your team needs to master the art of pointing or estimating stories. The important thing to remember about estimating stories is that it is a group activity, the purpose of which is to truly understand the work required to complete that story. Points are best as a measure of effort or complexity rather than being mapped to hours or days. If teams estimate consistently, the PM will over time, have an idea of how much work their team can conceivably complete in a given week, based on how much that team has competed in past weeks (aka, their velocity).
Having enough clearly defined and prioritized stories in the backlog for at least 2–3 weeks of work should be the goal. However, it’s important to recognize that the backlog also serves as a micro roadmap for the team. To them, this may be the place they turn to to understand where the work is headed as a whole. Having stories and milestones—even if they are still tentative and rough—listed in your backlog for a month or two down the road helps teams better understand the big picture, which in turn enables them to more effectively complete their present work.
It’s very easy for the backlog to become a catchall for every idea and feature request that comes a team’s way—as well it should. That’s why we created the Icebox in Pivotal Tracker.
Whenever someone wants the team to consider a feature, this should be added to the Icebox (and not the Backlog). If you find yourself with an unwieldy backlog, move every story that’s more than a month or so out into the Icebox. If these stories are important, keep them at the top of your Icebox.
Over time, it’s possible that your Icebox accumulates a very impressive list of stories. It’s up to the PM to keep an eye on all these stories and ensure that the “best by” date hasn’t expired. Even if a story seemed relevant six months ago, if it didn’t make it into the active backlog in that time, you should reevaluate it. You may still feel that the story could be worked on down the road and not want to lose sight of it. In that case, create a milestone with a date (using a release marker) called “evaluate on this date,” and seriously look at the story in three months. (Tracker tip: consider giving all the stories for a milestone or release, including the marker, the same label. This eases search and conversion to a label later). If at that time you want to work on it, prioritize it further up in your Icebox; if not, remove it from your Icebox.
What to do with old stories? There are a few ways to archive Icebox stories:
At the end of the day, unlike with email, you shouldn’t aim for inbox zero, but you should also not allow your backlog of stories to become so unwieldy that you’ve reached a point where it stresses you out just thinking about it. This is all easier said than done, of course, but keep in mind the old saying, Mens sana in corpore sano: a healthy mind is a healthy body. Whomever is in charge of your backlog is responsible for the ongoing care and grooming of this list of work, and a healthy backlog means a healthy team.
Category: Productivity Community
