How does the team know whether the story that they have completed is just "Done" or is "Shippable" too?
Alistair Cockburn comments on a recent discussion
- Most companies never notice the difference between "end-of-sprint done" and "shippable", so they never talk about it.
- Most programmers don't have any idea how much work it takes to get from "end-of-sprint done" to "shippable", so neither they nor their managers schedule it!
- Following from (2), there isn't an orchestrated dialog between the parties as to how to schedule and evaluate the allegedly-shippable version.
Recently in an article (summarized on InfoQ) Jeff Patton outlined the following characteristics of Shippable:
For a customer, someone who intends to sell or use the software, shippable means they could actually sell and use the software. This means the minimal number of features all need to be present. The software needs to be useful for it's intended purpose - at least as useful as the old software or paper process it replaces. The software needs look and behave well - have a high quality of fit and finish - particularly if this is commercial software and you've got competitors breathing down your back.
Shippable means done. Completely done and dusted. There's no need to iterate on something done - really shippable done.
Alistair Cockburn seems to agree on the Shippable part being fully "done and dusted". He explains that the transition from Done to Shippable is an iterative process. He details this in his strategy of writing three story cards instead of just one. The first story card has the actual story on it. The second one is a placeholder for the inevitable changes to the story after we see it. The third for the fine-tuning after we see those changes. All three appear on the backlog and get scheduled into iterations.
There also seems to be a difference in perception when the community talks about Shippable and "Potentially Shippable". Some Agile practitioners hold that "potentially" means "one sprint away from shippable." Matt Wynne suggests:
One thing you may miss here, is how long changing "potentially shippable" into "actually shipped" might take. Building code and deploying it to a system test or user test environment where the business users can play with your changes might feel potentially shippable, but in the cold hard light of day, it still may be far from truly shippable.
... "potentially shippable" and "shippable" are not the same thing. Some large or complex projects will require the use of "release sprint" or "hardening sprint" at the end of a release cycle (say 6 two-week sprints then a 2-week release sprint). The release sprint is not a dumping ground for sloppy work; rather it is a place where some hardening of the system can occur.
On similar lines Mike Kirby added:
In our company we formally recognize 3 phases of development (this is independent of the use of agile techniques). "Code Development", "Hardening", and "Final acceptance by the program." "Shippable" is what happens at the end of the third phase
The practitioners seem to agree about the difference between Potentially Shippable and Shippable. The way to bridge the gap might be to have a hardening sprint towards the end of the release cycle.
What else should a team keep in mind to reduce the gap between Done and Shippable? Chris Spagnuolo observes:A Team can feasibly decide that "done" means everything from Analysis through Live. The goal of any Team should be to extend the range of "done" as far as possible. Our Team currently defines "done" to mean analyzed, designed, coded, tested, and documented.
Once you have a well laid out definition of done, you can work with the stakeholders to get an idea of how close it is to being Shippable.
On similar lines, Alistair Cockburn adds:
Make the sprints long enough that
(a) users can see and correct the feature within the sprint period,
(b) everyone can get the feature fully shippable, consumer-grade (or whatever you need), within the sprint period.
It simplifies discussion and planning a lot.
It seems that there is too often a strong disconnect between Done and Shippable. Despite the current state of affairs, many seem to agree that the term Done should be sufficient, and should include Shippable.
Agile teams need to work on their definition of Done to make it as close to Shippable as possible. It might not be possible to achieve it overnight; the team might need to extend Done incrementally until finally Shippable happens within a sprint. Teams also need to work in tandem with the product owner and customer to define Shippable in the relevant context.