How do You Prioritize Content Work? Here's What We Did for Team Foundation Content

Once we identified most of the items (stories) in our backlog, we started to prioritize them. In our first pass, we adapted a technique that Mike Cohn teaches called Theme Scoring. I say adapted because we didn't identify a small number of themes and rank them using this technique. Rather, we identified our criteria and applied that to each story. Since we had about 150 stories in our backlog, our approach isn't exactly what Mike describes. He proposes this technique for prioritizing a small number of themes or epics. Still, the effort of identifying our criteria and evaluating each story based on that criteria did give us a decent starting point. We used just two criteria:

• Importance of the task
• Impact that help content will likely have on successfully completing the task

We gave the importance criteria a weight of 0.4, and the impact criteria a weight of 0.6. Once we'd assessed the importance and impact of each story, we lined them up based on the weighted score they recieved from this analysis. After that analysis, we scanned through the list and looked for anything that seemed out of place, especially something that was prioritized lower than waht seemed reasonable. In those cases, we asked "Which items would be willing to cut to cover this story?", and we moved it ahead of all of them. That exercise gave us a team-wide rank. At this point, we estimated the stories as a team using planning poker. I'll have to post something about that. It was suprisingly valuable.

This is where we really moved away from what an agile software development team would do. We broke the backlog out into a backlog for each individual writer. (That was a tough decision, and I hope we don't regret it. I'll try to write another post about that decision, but this is about how we prioritized our backlog.) Each writer is now looking at his individual backlog and trying to make sure that the top of the backlog is made up not only of stories that are most important, but that are ready to work on. In many cases, an item that we prioritized high in the stack may not be ready for several months. For example, the software may not be ready, or it may be the wrong time to work with the product unit to get the information that we'll need.

So, each writer moved things around to make sure the top of his stack reprents the most important items that are ready to start. We maintained the original team ranks in a separate field, though. That will allow us to evaluate whether there are writers who are working significantly lower in the team's priorities than most of the other writers. In those cases, we'll consider having him pick up something more important in another area.

That's how we prioritized our backlog. I'm curious how others prioritize content work. Let me know.