October 16, 2003
Defining priorities for the product requirements backlog
I wouldn't advocate using this in isolation, as I think that you need to filter your requirements through a user benefit vs feasability process first. But, this is very useful for defining which of those get worked on first.
This link Matt, is also quite similar to something that Janice Fraser from Adaptive Path talks about too. It's what I was alluding to when I loosely referred to 'user benefit vs feasability' as a filter to pass requirements through...
http://www.adaptivepath.com/publications/essays/archives/000018.php
Posted by: Ant at October 17, 2003 11:07 AMI refuse to believe that you Matt, are slow in any way. Sorry for jargon use though. You are right and there's no excuse.
Product Requirements Backlog – this is essentially a long list of requirements or features that you are going to accomodate during a project. What gets designed/built first is determined by the order in which these functional requirements appear on the list.
You cordon off sections of this list to determine what is attempted in each 'sprint' (time allotment).
Posted by: Ant at October 17, 2003 10:55 AMagain, without the jargon pls... for the slow readers like me at the back....
also... take a look at victor's equivalent... not explicitly for ongoing projects, or 'backlogs' but still useful
http://www.noisebetweenstations.com/personal/essays/value-complexity/value-complexity.html
Posted by: matt at October 16, 2003 11:46 PM