Continuing in the vein of product backlog prioritization, there are a few practices that can help bring order to chaos. While there is no single method of tracking the backlog items, and in fact there are several excellent tools that can be used, these suggestions can even be applied to a backlog maintained in an Excel (or Google Docs) spreadsheet.
I like to see two attributes that are calculated to establish a weighted ranking. The first is a triage, really a segmentation of features or stories into must, want, nice, and forget about it. This is your first “dimension”, and one that should be easy (but can be quite contentious).
The second is something that if you have a background in engineering you have a better handle on, the amount of effort required. Ranked from very difficult, to trivial. This is useful when you are preparing what to bring to the sprint planning session. If you have some up front idea of the story points that a story will take, you can better estimate velocity and plan accordingly. Recall that a story should be something small enough that a single developer can implement, and write the unit tests for in a single iteration. If it can’t fit that criteria, then break the story up.
Together, these two metrics, even if the effort is a SWAG, will give you a means to sort, and stack rank your backlog, and simplify or streamline your pre-sprint planning preparation.
Dimension 1 – The Criticality
If you have spent time working with an issue tracking tool (bugzilla, Fogbugz, or JIRA to name a few) then you are aware of the criticality of a reported issue, from “oh my God, drop everything and fix it”, all the way down to typo’s in the UI. Thus, you are intuitively aware of how to segment by importance. It is much the same with your backlog. There will be some features that without them, you have no product, and some that are so far from the top of the priority list, you can admit to yourself that it is likely they will never be done.
What I have used, and seems to work well are the following categorizations:
- Must have – The product can’t exist without it. Whether it is dictated by competitive offerings, or a core capability, it is essential to the product.
These are the non-negotiables, and must be in the final product. Be careful, as the stakeholders will very passionately argue that their pet priority is in this class.
- Want to have – Differentiators, or table stakes raising capabilities or features, this is the second tier, and likely the most contentious discussions will be about what to bundle in here.
In the Whole Product vernacular, this is the “Augmented Product“, or what provides the customer a compelling reason to buy.
- Nice to have – Icing on the cake, things that make it “pop“, but if push comes to shove, you can live without. The nice to have category is the reservoir of future development, and you should pay significant attention to this.
Do be careful though, many things that feel like they should be “nice to have” really ought to be in the next category up. i.e. they should be prioritized higher.
- Not going to happen – There will always be pie in the sky features that are requested. You need to acknowledge them, and they officially remain on the backlog, but like bugs that aren’t really preventing the product from working, the likelihood of them ever being addressed is very low.
Pro-Tip – from the Lean Startup, these are the features that you test early on, and when you find that they aren’t resonating with your customers, you can dispose of them. Be cautious though, as there will be some constituencies in the organization who will be very emotionally attached to some of these. Tread with care when communicating the priorities
What about scope/size/effort?
The goal here isn’t to map perfectly the amount of time or effort required to implement a user story. It is to have a rough idea, so you can “map” the features.
If you don’t have a development background, or a historical perspective on what makes a story take more effort, you will be feeling in the dark. What you shouldn’t do is make blind assumptions. Because it seems like it is easy, doesn’t mean that it is low effort, and quick to implement.
If you are unsure, buy a coffee for one of the developers, and discuss it with them. Get a feel for the size. And this is also a good way to figure out if you have a story that is too big. Perhaps it can be broken into smaller, autonomous stories, that are easier to estimate.
Of these two ranking methods, the one that gives the most trouble to new product managers/product owners is the scope/size/effort. That really does come with experience, and getting a few projects/iterations under your belt. Still, it is worth struggling through, even with less than perfect estimates, as it is useful for prioritization.
One piece of advice. Do not load only the must haves at the top of the backlog. Be sure to bring in some level 2 and 3 features/stories, especially early in the development process. I have found that if you only attack the difficult, meaty, “Must Have” items, it can cause some fatigue in the team. Mix it up, and balance what you bring to the planning.
Regardless of the tools employed, a methodical, structured “map” can help you keep the goals in sight, yet allow the flexibility inherent in the Agile method.
I have mentioned a couple times in this post the concept of a feature map. This isn’t truly a roadmap, but it also isn’t just a list of features or stories either. My next post, I will expand upon this very helpful concept.
What are your experiences in managing and prioritizing your backlog?