Comments on: Value vs. Return and Potentially Shippable Product Increments http://www.gettingagile.com/2007/11/20/value-vs-return-and-potentially-shippable-product-increments/ with Sterling Barton Sat, 14 Aug 2010 01:58:30 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Chris Sterling’s Blog » The “Wright Model” for Describing Incremental Architecture http://www.gettingagile.com/2007/11/20/value-vs-return-and-potentially-shippable-product-increments/comment-page-1/#comment-54 Chris Sterling’s Blog » The “Wright Model” for Describing Incremental Architecture Mon, 02 Jun 2008 22:39:58 +0000 http://chrissterling.gettingagile.com/2007/11/20/value-vs-return-and-potentially-shippable-product-increments/#comment-54 [...] since it is quite common to have releases that involve running multiple Sprints until there is enough value for your users. I usually describe potentially shippable product increment is that the software is of a quality [...] [...] since it is quite common to have releases that involve running multiple Sprints until there is enough value for your users. I usually describe potentially shippable product increment is that the software is of a quality [...]

]]> By: Chris Sterling http://www.gettingagile.com/2007/11/20/value-vs-return-and-potentially-shippable-product-increments/comment-page-1/#comment-53 Chris Sterling Wed, 21 Nov 2007 22:23:48 +0000 http://chrissterling.gettingagile.com/2007/11/20/value-vs-return-and-potentially-shippable-product-increments/#comment-53 I believe that is one of the main points in this entry. There is also a point that you can break down work and still come out with a whole product for release. This is sometimes a problem for groups using Scrum and trying to figure out what value is without having their "entire" feature completed which may be many user stories when broken down. One of the main comments I get in this situation is "but that isn't valuable to the customer". Understanding that an increment is still contributing to the overall value of the feature and ultimately to the release is a conversation which I have found must happen in this case. Also, understanding that "value" is not the same as "return" is sometimes helpful. Yes, the customers might not find value until there is more of the feature completed but feedback to increase the value of what has been completed so far is helpful. This will enable a higher return on the investment to create that value at release time when the users actually use the software. I believe that is one of the main points in this entry. There is also a point that you can break down work and still come out with a whole product for release. This is sometimes a problem for groups using Scrum and trying to figure out what value is without having their “entire” feature completed which may be many user stories when broken down. One of the main comments I get in this situation is “but that isn’t valuable to the customer”. Understanding that an increment is still contributing to the overall value of the feature and ultimately to the release is a conversation which I have found must happen in this case. Also, understanding that “value” is not the same as “return” is sometimes helpful. Yes, the customers might not find value until there is more of the feature completed but feedback to increase the value of what has been completed so far is helpful. This will enable a higher return on the investment to create that value at release time when the users actually use the software.

]]> By: Matan http://www.gettingagile.com/2007/11/20/value-vs-return-and-potentially-shippable-product-increments/comment-page-1/#comment-52 Matan Wed, 21 Nov 2007 19:02:28 +0000 http://chrissterling.gettingagile.com/2007/11/20/value-vs-return-and-potentially-shippable-product-increments/#comment-52 Is the main theme here that iterations do not necessarily get their outputs deployed even though each iteration ends with a potentially shippable product? (and that the PO should decide at what point the company should deploy to customers..) Is the main theme here that iterations do not necessarily get their outputs deployed even though each iteration ends with a potentially shippable product?

(and that the PO should decide at what point the company should deploy to customers..)

]]>