A Potentially Shippable Product: What Does It Mean To You?
By Lisa Montaño / Filed under Agile, Scrum / October 19th, 2012
I teach an “Introduction to Scrum” class a few times a month, and many students come with the expectation of learning how to implement Scrum within their organizations by the end of the day—an expectation that I have no hope of fulfilling. Every organization is different, and delivering a valuable piece of working software at the end of each Sprint means something different depending on the organization and the business. Because Scrum is a framework for working that leverages principles and ceremonies rather than adherence to a specific methodology, organizations must determine how to leverage the principles within their own context. A perfect example of a Scrum concept that has to be made relevant to the individual organizational context is the “Potentially Shippable Product”.
- (Click on the image to enlarge)
The signatories of the Agile Manifesto say that Agile values “working software over comprehensive documentation”, that a team’s highest priority is to “satisfy the customer through early and continuous delivery of valuable software/products”. In other words, teams should strive to deliver a “Potentially Shippable Product” at the end of every Sprint – working software that can be evaluated by customers and that has some real business value. Whether a team is working on a single-team project or a multi-team effort, creating in-house software or a product for re-sale, using Scrum as a product development tool requires the organization to determine and define what Potentially Shippable Product means to them.
The product owner and the team will determine what constitutes a potentially shippable product, in meaningful chunks of features that the customer will be able to provide feedback on during the product review and demonstration. In his book “Succeeding with Agile” (2010), Mike Cohn says:
“To fully define potentially shippable would require knowledge of the domain and application that only the team, including its product owner and ScrumMaster, will have. In fact, one thing any new team should do is discuss and agree on a “definition of done” that defines a potentially shippable product increment appropriate for its environment (p 261)…
Cohn makes two distinctions in his discussion of a Potentially Shippable product. First, he mentions the need for the organization to agree on a “definition of done” that satisfies the needs of the domain for calling working software complete. So, a team needs to determine its organizational working agreements and quality requirements before a product may be released into a production environment or sold in the marketplace.
Some of the criteria that an organization may use to qualify a “potentially shippable” product as done include:
- Software code has been designed
- Software code has been written
- User interface has been designed
- Unit testing is done
- User Acceptance testing is done
- Integrated within and between teams
Once the team agrees on the definition of done for tasks, product backlog items, and sprints, then the work of the sprint can commence and team members can use the “definition of done” agreement as a guide for completing their individual and collaborative tasks.
Delivering something observable, meaningful, and valuable to the customer or end user is the next point that Cohn makes in his discussion of a Potentially Shippable Product:
..The intent is that each sprint should deliver something of immediate value to users or customers that they can see. Because one of the benefits of working in sprints is the ability to generate feedback from users and customers at the end of each sprint, a team will get better feedback if at least some of the work done each sprint results in features that users can see (p 263).”
So not only does the team need to deliver working software, but they also have to deliver something that the customer will perceive as useful and valuable. The underlying assumption here is that the team, product owner, customer, and stakeholders have collaborated together to define what “valuable” means in the context of their product and business.
One of the most challenging transitions that new Scrum teams will make is to shift the focus from project phases and milestones, to delivering an emergent product over time. Scrum delivers products incrementally, beginning with basic features and functions, and with iterative cycles of development and feedback, evolves into a more robust, fully functional product that serves the customers’ most important needs, delights customers, and inspires them to become not only repeat customers, but product evangelists.
Related posts:
