Comments on: Is the Product Backlog an Idealog? http://stateofflux.com/2009/04/10/is-the-product-backlog-an-idealog/ always changing Sat, 13 Mar 2010 22:54:08 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Why a bug tracker is not a good tool for agile project management? « tinyPM Team Blog http://stateofflux.com/2009/04/10/is-the-product-backlog-an-idealog/comment-page-1/#comment-6390 Why a bug tracker is not a good tool for agile project management? « tinyPM Team Blog Sat, 13 Mar 2010 22:54:08 +0000 http://stateofflux.com/?p=73#comment-6390 [...] I like the idealog concept that Mark Mansour described at: http://stateofflux.com/2009/04/10/is-the-product-backlog-an-idealog [...] [...] I like the idealog concept that Mark Mansour described at: http://stateofflux.com/2009/04/10/is-the-product-backlog-an-idealog [...]

]]> By: tinyPM Team Blog » Why a bugtracker is not a good tool for agile project management? http://stateofflux.com/2009/04/10/is-the-product-backlog-an-idealog/comment-page-1/#comment-2145 tinyPM Team Blog » Why a bugtracker is not a good tool for agile project management? Thu, 16 Jul 2009 13:24:09 +0000 http://stateofflux.com/?p=73#comment-2145 [...] I like the idealog concept that Mark Mansour described at: http://stateofflux.com/2009/04/10/is-the-product-backlog-an-idealog [...] [...] I like the idealog concept that Mark Mansour described at: http://stateofflux.com/2009/04/10/is-the-product-backlog-an-idealog [...]

]]> By: Rich Mironov http://stateofflux.com/2009/04/10/is-the-product-backlog-an-idealog/comment-page-1/#comment-1426 Rich Mironov Thu, 11 Jun 2009 17:58:42 +0000 http://stateofflux.com/?p=73#comment-1426 I use both approached, but for different purposes. As you suggest, project-specific teams really want to work down the backlog of things that are truly needed for that project. Putting things on such a backlog that won't get done (or are for other projects) simply creates a sorting/filing problem later. As an agile product manager (often a/k/a product owner), I know that my product will live on for a long time. Years and years if it's well-received! I want a place where good ideas can live for a while, even outside the scope of what the team can build in this sprint or this release. Many agilists would refer to this as the product backlog, rather than the release backlog or sprint backlog. It includes variously underdefined things that may get more definition later. Great to call this an IdeaLog as long as it doesn't generate yet another disconnected list of things that need to be found and re-integrated later. See some of my thoughts on agile PM at http://www.enthiosys.com/entry/insights-tools/product-bytes/ -Rich I use both approached, but for different purposes. As you suggest, project-specific teams really want to work down the backlog of things that are truly needed for that project. Putting things on such a backlog that won’t get done (or are for other projects) simply creates a sorting/filing problem later.
As an agile product manager (often a/k/a product owner), I know that my product will live on for a long time. Years and years if it’s well-received! I want a place where good ideas can live for a while, even outside the scope of what the team can build in this sprint or this release. Many agilists would refer to this as the product backlog, rather than the release backlog or sprint backlog. It includes variously underdefined things that may get more definition later.
Great to call this an IdeaLog as long as it doesn’t generate yet another disconnected list of things that need to be found and re-integrated later.

See some of my thoughts on agile PM at http://www.enthiosys.com/entry/insights-tools/product-bytes/
-Rich

]]> By: Jack Milunsky http://stateofflux.com/2009/04/10/is-the-product-backlog-an-idealog/comment-page-1/#comment-109 Jack Milunsky Thu, 09 Apr 2009 20:24:38 +0000 http://stateofflux.com/?p=73#comment-109 A really good thought provoking blog. Well done! I personally am in favour of a single backlog. I think if managed well, (I know, it's not easy but with the right tools ....) it's a far better option. I hate having to manage multiple lists. It quickly gets out of hand. Additionally, you never know when or where that next great idea is going to come from. And if ideas arn't taken seriously they stop coming up with them. There's really something impactful about telling a customer "it's on the backlog" Also, one other comment, stories don't and should not only come from the product owner/s. Cheers Jack www.agilebuddy.com blog.agilebuddy.com A really good thought provoking blog. Well done!

I personally am in favour of a single backlog. I think if managed well, (I know, it’s not easy but with the right tools ….) it’s a far better option. I hate having to manage multiple lists. It quickly gets out of hand. Additionally, you never know when or where that next great idea is going to come from. And if ideas arn’t taken seriously they stop coming up with them. There’s really something impactful about telling a customer “it’s on the backlog”

Also, one other comment, stories don’t and should not only come from the product owner/s.

Cheers
Jack
http://www.agilebuddy.com
blog.agilebuddy.com

]]> By: Dan Prager http://stateofflux.com/2009/04/10/is-the-product-backlog-an-idealog/comment-page-1/#comment-108 Dan Prager Thu, 09 Apr 2009 18:25:41 +0000 http://stateofflux.com/?p=73#comment-108 I also think that method B wins. With the long list approach you inevitably get duplicates as ideas that were at a low priority get re-added rather than promoted, adding further to the management burden. It just doesn't seem agile. That said, in the more public sphere, UserVoice combines method A with search and votes to good effect. I also think that method B wins. With the long list approach you inevitably get duplicates as ideas that were at a low priority get re-added rather than promoted, adding further to the management burden. It just doesn’t seem agile.

That said, in the more public sphere, UserVoice combines method A with search and votes to good effect.

]]> By: Michael Dubakov http://stateofflux.com/2009/04/10/is-the-product-backlog-an-idealog/comment-page-1/#comment-107 Michael Dubakov Thu, 09 Apr 2009 13:26:50 +0000 http://stateofflux.com/?p=73#comment-107 I use Idealog as well. We've tried to put most ideas into Backlog and it quickly become a mess. In TargetProcess we have Requests (ideas and issues), so now we collect all ideas in requests list (currently it has about 600 active ideas, I mean not rejected). Each idea has Votes attached (for example, top idea has about 40 votes). Based on votes and own vision I create stories from ideas that we are going to implement in the near future (let's say about 2 month horizon) and that forms our Backlog. Works very good, since it is quite easy to prioritize the backlog. Idealog is a good name :) Maybe we will use it in future releases of TargetProcess, if you don't mind ;) I use Idealog as well. We’ve tried to put most ideas into Backlog and it quickly become a mess. In TargetProcess we have Requests (ideas and issues), so now we collect all ideas in requests list (currently it has about 600 active ideas, I mean not rejected). Each idea has Votes attached (for example, top idea has about 40 votes). Based on votes and own vision I create stories from ideas that we are going to implement in the near future (let’s say about 2 month horizon) and that forms our Backlog. Works very good, since it is quite easy to prioritize the backlog.

Idealog is a good name :) Maybe we will use it in future releases of TargetProcess, if you don’t mind ;)

]]>