Comments on: Make the Product Backlog DEEP http://blog.mountaingoatsoftware.com/make-the-product-backlog-deep Succeeding With Agile® Wed, 08 Feb 2012 15:06:15 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Making the Product Backlog DEEP « All Things Product Owner - Roman Pichler's Thoughts on Agile Product Management and Product Ownership http://blog.mountaingoatsoftware.com/make-the-product-backlog-deep/comment-page-1#comment-65554 Making the Product Backlog DEEP « All Things Product Owner - Roman Pichler's Thoughts on Agile Product Management and Product Ownership Mon, 08 Feb 2010 08:25:42 +0000 http://blog.mountaingoatsoftware.com/?p=486#comment-65554 [...] owe the acronym to Mike Cohn who uses it in his latest book Succeeding with Agile and who has also blogged about it.) Let’s explore the four qualities in more [...] [...] owe the acronym to Mike Cohn who uses it in his latest book Succeeding with Agile and who has also blogged about it.) Let’s explore the four qualities in more [...]

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/make-the-product-backlog-deep/comment-page-1#comment-63980 Mike Cohn Tue, 12 Jan 2010 19:39:25 +0000 http://blog.mountaingoatsoftware.com/?p=486#comment-63980 Hi Philip-- That topic is addressed in the blog post called "<a href="http://blog.mountaingoatsoftware.com/when-should-we-estimate-the-product-backlog" rel="nofollow">When Should We Estimate the Product Backlog</a>". Mike Hi Philip–
That topic is addressed in the blog post called “When Should We Estimate the Product Backlog“. Mike

]]> By: Philip Page http://blog.mountaingoatsoftware.com/make-the-product-backlog-deep/comment-page-1#comment-63972 Philip Page Tue, 12 Jan 2010 17:57:17 +0000 http://blog.mountaingoatsoftware.com/?p=486#comment-63972 When is a good time to estimate stories in the product backlog. I have read that it is best to have this completed prior to the sprint planning meetings. When is a good time to estimate stories in the product backlog. I have read that it is best to have this completed prior to the sprint planning meetings.

]]> By: Best Links of the Week – Christmas 2009 Version : Agile PM Scrum http://blog.mountaingoatsoftware.com/make-the-product-backlog-deep/comment-page-1#comment-62454 Best Links of the Week – Christmas 2009 Version : Agile PM Scrum Sat, 26 Dec 2009 01:10:53 +0000 http://blog.mountaingoatsoftware.com/?p=486#comment-62454 [...] Make the Product Backlog DEEP – more on good practices for maintaining the Product Backlog from Mike Cohn. [...] [...] Make the Product Backlog DEEP – more on good practices for maintaining the Product Backlog from Mike Cohn. [...]

]]> By: Stone Shi http://blog.mountaingoatsoftware.com/make-the-product-backlog-deep/comment-page-1#comment-62203 Stone Shi Wed, 23 Dec 2009 08:29:36 +0000 http://blog.mountaingoatsoftware.com/?p=486#comment-62203 The sister rule could be, make the Stories INVEST. The sister rule could be, make the Stories INVEST.

]]> By: Podcast #2: O Batman da semana « Blog da Bluesoft http://blog.mountaingoatsoftware.com/make-the-product-backlog-deep/comment-page-1#comment-61826 Podcast #2: O Batman da semana « Blog da Bluesoft Fri, 18 Dec 2009 21:42:27 +0000 http://blog.mountaingoatsoftware.com/?p=486#comment-61826 [...] Make the Product Backlog DEEP [...] [...] Make the Product Backlog DEEP [...]

]]> By: Fabrice Aimetti http://blog.mountaingoatsoftware.com/make-the-product-backlog-deep/comment-page-1#comment-61753 Fabrice Aimetti Fri, 18 Dec 2009 06:46:08 +0000 http://blog.mountaingoatsoftware.com/?p=486#comment-61753 Hi, I've translated your interesting post in french : <a href="http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/12/16/Rendre-le-Product-Backlog-DEEP" rel="nofollow">"Rendre le Product Backlog DEEP"</a> Regards, Fabrice Hi,
I’ve translated your interesting post in french : “Rendre le Product Backlog DEEP”
Regards, Fabrice

]]> By: Ådne Brunborg http://blog.mountaingoatsoftware.com/make-the-product-backlog-deep/comment-page-1#comment-61716 Ådne Brunborg Thu, 17 Dec 2009 22:01:11 +0000 http://blog.mountaingoatsoftware.com/?p=486#comment-61716 Thank you all for your comments, I find them really helpful. As I wrote in a comment on the "How Do You Get from Here to Agile? Iterate." post, we've established a "Scrum Process Backlog", and (not surprisingly) the first item relates to estimating and the PBL. So, my questions above are the questions and associations that rose to the top of my mind when I read the blog post. (a side note: I just love how this blog addresses the very issues I find we need to address when implementing Scrum!) Mike - here's how I've tried to explain Story Points: It can be broken down into three components - "Risk" (or uncertainty), which of course you want to reduce as much as possible (the "D" in DEEP will reduce risk). Second part is "Complexity", which can be understood as the amount of analysis/design you need to do. The last one is "Size", which reflect the amount of deliverables to be produced. (Every programming task requires some analysis of the problem, and some design of the code, before being coded - and this fits well with AMDD, where each iteration (sprint) contains some modeling.) But overall, it should reflect how much time we expect to spend on the User Story. Roman - recently, one of our teams (we have 2) estimated a PBI to 20 story points, but failed to pinpoint more than ca 1/3 of the hours normally estimated for a 20-point PBI, yet the team felt 20 story points was justified. The PBI was committed to the Sprint, and the Sprint did not meet its commitment. Next sprint ends tomorrow, and looks like commitment will be met. So, lesson learned for the team. --- I can see how a DEEP product backlog will really help us deliver. The problem is getting the business side to understand it as well. Good thing I'm attending a CSPO-course soon, will probably help :) Thank you all for your comments, I find them really helpful.

As I wrote in a comment on the “How Do You Get from Here to Agile? Iterate.” post, we’ve established a “Scrum Process Backlog”, and (not surprisingly) the first item relates to estimating and the PBL. So, my questions above are the questions and associations that rose to the top of my mind when I read the blog post.

(a side note: I just love how this blog addresses the very issues I find we need to address when implementing Scrum!)

Mike – here’s how I’ve tried to explain Story Points: It can be broken down into three components – “Risk” (or uncertainty), which of course you want to reduce as much as possible (the “D” in DEEP will reduce risk). Second part is “Complexity”, which can be understood as the amount of analysis/design you need to do. The last one is “Size”, which reflect the amount of deliverables to be produced. (Every programming task requires some analysis of the problem, and some design of the code, before being coded – and this fits well with AMDD, where each iteration (sprint) contains some modeling.) But overall, it should reflect how much time we expect to spend on the User Story.

Roman – recently, one of our teams (we have 2) estimated a PBI to 20 story points, but failed to pinpoint more than ca 1/3 of the hours normally estimated for a 20-point PBI, yet the team felt 20 story points was justified. The PBI was committed to the Sprint, and the Sprint did not meet its commitment. Next sprint ends tomorrow, and looks like commitment will be met. So, lesson learned for the team.

—

I can see how a DEEP product backlog will really help us deliver. The problem is getting the business side to understand it as well. Good thing I’m attending a CSPO-course soon, will probably help :)

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/make-the-product-backlog-deep/comment-page-1#comment-61684 Mike Cohn Thu, 17 Dec 2009 15:43:16 +0000 http://blog.mountaingoatsoftware.com/?p=486#comment-61684 Hi Roman-- Thanks for joining the discussion. I know you cover these ideas more in <a href="http://www.romanpichler.com/publications/" rel="nofollow">your upcoming book</a> and it will be great to have that available in a few months. Hi Roman–
Thanks for joining the discussion. I know you cover these ideas more in your upcoming book and it will be great to have that available in a few months.

]]> By: Roman Pichler http://blog.mountaingoatsoftware.com/make-the-product-backlog-deep/comment-page-1#comment-61659 Roman Pichler Thu, 17 Dec 2009 08:53:39 +0000 http://blog.mountaingoatsoftware.com/?p=486#comment-61659 As much as estimating low-priority product backlog items can be challenging, working with coarse-grained items supports the continuous discovery of the product's functionality. I think of low-priority items as placeholders for more detailed functionality to be discovered later on. I find that if a team cannot size an item, it usually pays to investigate why. Is it because the team does not understand what the item means? Or is it because the team is unsure how to implement the item? Both can indicate that there is risk involved in delivering the item. If that's the case, decompose the item so that the team can implement a small piece of the functionality thereby addressing the risk. As much as estimating low-priority product backlog items can be challenging, working with coarse-grained items supports the continuous discovery of the product’s functionality. I think of low-priority items as placeholders for more detailed functionality to be discovered later on.

I find that if a team cannot size an item, it usually pays to investigate why. Is it because the team does not understand what the item means? Or is it because the team is unsure how to implement the item? Both can indicate that there is risk involved in delivering the item. If that’s the case, decompose the item so that the team can implement a small piece of the functionality thereby addressing the risk.

]]>