Value vs. Return and Potentially Shippable Product Increments
Posted by Chris Sterling on 20 Nov 2007 at 11:51 pm | Tagged as: Agile, Architecture, Product Owner, Scrum, XP
Aman, a trustworthy and accomplished IT manager, looks at Scrum and Agile for his first time. After going over timeboxes, value-driven backlogs and potentially shippable product increments, Aman assumes that this method of developing software is not applicable to their projects. Aman sees a problem producing valuable increments of software every iteration. Some of their features are much larger than what could be developed in one iteration. He quickly nudges the Agile Coach, Priya, about this major oversight on the part of their organizational sponsor for Scrum and Agile. Priya is empathetic to Aman’s position since she has held that position before. She decides to learn a little more about Aman’s world and see if they can find a way through this issue.
One of the most often asked questions I get as a Certified Scrum Trainer and Agile Coach is around potentially shippable product increments and value of those increments to the customer. In my opinion this is a question about what is “value” and how does that relate to a “return”. In iterative and incremental methods of developing software such as Scrum and Extreme Programming (XP) there is emphasis on potentially releasable product increments at the end of each iteration. This provides some benefits such as the following:
- Product Owner is enabled to identify early release opportunities
- Software continues to be in a more predictable state
- Forces system integration more frequently
- Reduces duration of stabilization phase at time of release
- Increases early feedback of architecture and system design issues
- Minimizes amount of architecture by only supporting implemented features
The product accrues value as we progress from iteration to iteration adding more features into the product. How value is measured for software projects may come in various forms such as:
- Increase market potential
- Create valuable upgrade features for existing customers
- Reduce total cost of ownership
- Improve operational effectiveness
- Enabling platform for future software endeavors
Although the product may be potentially shippable at the end of each iteration there may not be enough value accrued to ship it. Therefore we use each iteration deliverable as an increment of value towards an ultimate releasable product.
A value-driven approach such as Scrum will prioritize the implementation of the highest value features first. This means that each potentially shippable product increment delivered will contain the most valuable feature elements to produce a releasable product. As the release schedule progresses the Delivery Team will increase production of valuable software as the architecture becomes stable and unknowns lessen. Since we are continually working on the next most valuable features for the release the amount of value we produce per iteration will begin to level off. The following shows the value per feature added throughout a release cycle.
Although the software has continued to get more valuable, the value is not realized until there is a release and the end users are using the software. In an Agile environment we tend towards shorter release cycles in order to maximize return on our investment of valuable features implemented in the software.
As Priya and Aman discuss the implications of potentially shippable product increments delivered each iteration Aman gets a clearer picture of what is required in breaking down the features into consumable chunks a Delivery Team can implement inside an iteration. Priya describes the accrual of value as each iteration passes. Aman finished by describing how the customers of their product can then realize this value once it is released and they start using the software. Aman now understands that a release still contains essential elements such as the sufficient amount and correct valuable features to give the customers the best experience possible with the software.
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..)
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.
[…] 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 […]