围棋与软件开发：Choose Backlog Items That Serve Two Purpose# Parenting - 为人父母
a*g
1 楼
围棋与软件开发：Choose Backlog Items That Serve Two Purposes
http://www.mountaingoatsoftware.com/blog/choose-backlog-items-t
-purposes
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 pi
eces 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 fai
r 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 sto
nes 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 somethi
ng 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 ho
pe to share some new thoughts on that here in the coming months.
One thing that has become increasingly clear is that when prioritizing produ
ct 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 n
ew functionality is. This is often, of course, adjusted by how long that fun
ctionality will take to develop. That is, a product owner wants something pr
etty 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 p
roduct backlog item that is moderately desirable (given its cost) but that a
lso 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 backlo
g item is developed. If the team or product owner is going to learn from dev
eloping a feature, do it sooner.
Learning can occur in a variety of ways. Developers may learn from doing a p
roduct backlog item that the new technology they’d counted on being easy is
n’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 th
e product owner thought.
Another consideration is how much risk will be reduced or eliminated by deve
loping 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 b
acklog 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.
＝＝
Mike Cohn is the founder of Mountain Goat Software, a process and project ma
nagement consultancy that specializes in helping companies adopt and improve
their use of Agile processes and techniques. He is the author of User Stori
es Applied for Agile Software Development, Agile Estimating and Planning, an
d Succeeding with Agile. Mike is a co-founder of the Agile Alliance. He is a
lso a co-founder and current board member of the Scrum Alliance. He can be r
eached at i**[email protected] or connect with Mike on Google+.
http://www.mountaingoatsoftware.com/uploads/blog/Go-Baduk_Board
dium.jpg
http://www.mountaingoatsoftware.com/blog/choose-backlog-items-t
-purposes
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 pi
eces 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 fai
r 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 sto
nes 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 somethi
ng 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 ho
pe to share some new thoughts on that here in the coming months.
One thing that has become increasingly clear is that when prioritizing produ
ct 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 n
ew functionality is. This is often, of course, adjusted by how long that fun
ctionality will take to develop. That is, a product owner wants something pr
etty 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 p
roduct backlog item that is moderately desirable (given its cost) but that a
lso 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 backlo
g item is developed. If the team or product owner is going to learn from dev
eloping a feature, do it sooner.
Learning can occur in a variety of ways. Developers may learn from doing a p
roduct backlog item that the new technology they’d counted on being easy is
n’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 th
e product owner thought.
Another consideration is how much risk will be reduced or eliminated by deve
loping 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 b
acklog 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.
＝＝
Mike Cohn is the founder of Mountain Goat Software, a process and project ma
nagement consultancy that specializes in helping companies adopt and improve
their use of Agile processes and techniques. He is the author of User Stori
es Applied for Agile Software Development, Agile Estimating and Planning, an
d Succeeding with Agile. Mike is a co-founder of the Agile Alliance. He is a
lso a co-founder and current board member of the Scrum Alliance. He can be r
eached at i**[email protected] or connect with Mike on Google+.
http://www.mountaingoatsoftware.com/uploads/blog/Go-Baduk_Board
dium.jpg