I've been playing a fair amount of Go lately. If you're not familiar with Go, it's a strategy game that originated in China 2,500 years ago. It's along the lines of chess, but it's about marking territory with black and white pieces played on the intersections of a grid of 19x19 lines. 
Like Scrum, there are very few rules in Go. Also like Scrum, there are a fair number of principles, often called proverbs in the Go world. One of these Go principles is that a move that does two things is better than a move that does one. For example, a single move may defend a group of the player's stones while threatening the opponent's stones.
Even if you don't know Go, I think this proverb is understandable--after all, something that does two things sounds like it would be better than something that achieves only one goal. But this isn't hard-and-fast advice. It's a principle or proverb because sometimes a move that does one thing--but does that thing very well--will be the better choice.
In addition to playing more Go over the past week or two, I've also spent a lot of time thinking about approaches to prioritizing product backlogs. I hope to share some new thoughts on that here in the coming months.
One thing that has become increasingly clear is that when prioritizing product backlog items, an item that can achieve two goals should often be higher priority.
Let’s see how a product backlog item can help achieve two goals.
Normally, product backlog items are prioritized based on how desirable the new functionality is. This is often, of course, adjusted by how long that functionality will take to develop. That is, a product owner wants something pretty badly until finding out that feature will take the entire next quarter. So, desirability often tempered by cost (usually in development team time) determines priorities.
But there can be other important considerations. And prioritizing highly a product backlog item that is moderately desirable (given its cost) but that also achieves one of these secondary goals may make that item a better first choice overall.
One such consideration is how much learning will occur if the product backlog item is developed. If the team or product owner is going to learn from developing a feature, do it sooner.
Learning can occur in a variety of ways. Developers may learn from doing a product backlog item that the new technology they’d counted on being easy isn’t. A product owner may learn by showing a new user interface built for a specific product backlog item is not something users are excited about as the product owner thought.
Another consideration is how much risk will be reduced or eliminated by developing a product backlog item. If a certain product backlog item needs to be developed and doing so will be risky, my preference is to do that product backlog item early so that I have time to recover from the risk if it hits.
Selecting product backlog items to work on that achieve two (or all three!) of these goals can be a very powerful prioritization strategy. Adding value while simultaneously reducing risk or accelerating learning is just as good as playing a Go stone that achieves two goals.
