BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Does "Done" Mean "Shippable"?

Does "Done" Mean "Shippable"?

This item in japanese

Bookmarks
There has been a lot of discussion on various agile forums and blogs about the difference between 'Done' and 'Shippable'. It might sound like both mean the same, however discussions on the lists and various blogs suggest that these are still widely misunderstood, mis-used terms. Here is a roundup of recommendations about how to handle "Done."

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

  1. Most companies never notice the difference between "end-of-sprint done" and "shippable", so they never talk about it.
     
  2. 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!
     
  3. 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.

Mike Cohn seems to agree:

... "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.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Excellent article

    by Siddharta G,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I really liked this article. It brought out the differences between "done" and "shippable" very effectively. Would love more such articles.

  • it's done when it's done

    by Jeff Carroll,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The Scrum paradigm makes too many assumptions about the project lifecycle that are not universally true; probably the most controversial is that code should be shippable at the end of a sprint.

    Many projects don't work this way, and shouldn't be made to; manipulating a product or project release cycle to adhere to a methodology is making the tail wag the dog.
    I have seen rigid, doctrinaire Scrum implementation expunge all flexibility and benefit from what was originally a relatively adaptive and agile improvised process, achieving the exact opposite of what was, or at least should have been, desired.

  • Re: it's done when it's done

    by Bruce Rennie,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Wait a sec. Let's not confuse desire with ability.

    Do you think any of the contributors to this article wouldn't WANT to be able to be shippable at the end of any given sprint? I know I would. I can't always do that, so I occasionally have to come up with compromises like a "hardening" sprint.

    Your reply implies that there are times when it would actually be undesirable to get to a shippable state at the end of a sprint. Can you help me understand that by providing an example?

  • Re: it's done when it's done

    by Geoffrey Wiseman,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    As far as I'm concerned, the precondition for being involved in process selection and refinement is a willingness to accept whatever works for the people involved - the teams, the organization, etc. Dogmatic application of principles that don't fit doesn't help anyone.

  • Re: it's done when it's done

    by Bruce Rennie,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hey, I'm all for not being dogmatic. I would just like someone to show me an example of where being ready to release at the end of a sprint doesn't "fit".

    I suppose there are shops out there who have rejected the ideal of being shippable at the end of every sprint. I just can't think of a good reason why they'd do that.

    At any rate, I would tend to think that these shops are far outweighed by the number who would like to be shippable but cannot for whatever reason. It's more of a question of capability than desire.

  • Re: it's done when it's done

    by Deborah (Hartmann) Preuss,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Bruce: a common answer is "but our customers will only accept updates twice a year!"

    Of course, any statement starting with "but" is suspect and likely to be an excuse :-)

  • Re: it's done when it's done

    by Siddharta G,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    This is exactly why I liked this article. It brings out differences between the theory (done is shippable) and actual practice (often done is not shippable). And since a lot of the planning in Agile is done on the basis of "done = shippable" (extrapolating velocity for example), this leads to further questions.

  • Re: it's done when it's done

    by Ralph van Roosmalen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    But why is done often not shippable? Has it to do with software that doesn't meet the exact requirements of the product owner because he has come up with some extra requirements or does it has to do with testing, development, documentation tasks that are not ready?

    Software that doesn't exactly meet the requirements of the product owner is in my opinion done and shippable. Sure next sprint we will improve or change the software, but this software is done and shippable. Software never meets the requirements because customers always think up new requirements. So done or shippable has nothing to do with requirements (To make a clear statement ;))

    If not all task are finished software is not done and so not shippable. No discussion about that I think.

    The only step that I can distinguish between done and shippable is for example the installation software that you don't build every iteration. But this is, in my opinion, a shortcoming of your (automated) process. Improve your process so that you automatically have the installation software every iteration.

  • Re: it's done when it's done

    by Vikas Hazrati,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    That is a good point Ralph. In most agile teams the definition of done is narrow and does not take it to the shippable point. That is the reason agile practitioners propose to enhance the definition of done to be as close to shippable as possible.


    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.

  • Done, "Done Done", and "Done Done Done"

    by Jim Bethancourt,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Scott Davis tells a funny story about a time when he was doing on-site consulting, and the development teams all used the following terms:

    Done - the software was written
    Done Done - all unit tests passing
    Done Done Done - the software was successfully QA tested

    So the VP of software development comes over to a fairly young developer and asks how his progress is, and his response was "Oh - I'm done". The VP says "Great! When is it going out the door?", and the developer replies "Oh wait!! It's only Done, not Done Done Done!".

    I may be getting the details slightly wrong, but the story clearly echoes the moral of the article. :-)

  • Re: Done, "Done Done", and "Done Done Done"

    by Deborah (Hartmann) Preuss,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I'm pretty sure I've heard done-done at every client I've visited! (usually followed by a nervous laugh) Sometimes, it's the reason they invited me... when it's not, I try to get it on the agenda :-)

  • Re: it's done when it's done

    by Wayne Mack,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The difference between Done and Shippable arises because there are some tasks that are not feasible to do for every iteration due to time or cost. Some examples:

    * Time and cost to meet regulatory, environmental, independent, or third-party test requirements.

    * Time and cost to reproduce CDs, PROMs, or other delivery device.

    * Time and cost to install software.

    * Time and cost to reproduce and distribute user documentation.

    * Time and cost to train sales and support staff.

    * If development environment does not fully reflect production, time and cost to restest and develop rollback procedures.

    None of these is completely insurmountable, but they do represent effort that a company may choose not to expend until there is a driving need to ship. Then the company will expend the effort and cost.

  • Raising the bar?

    by Cameron Purdy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I always thought that the saying was: "If it compiles, ship it!" ;-)

    Peace,

    Cameron Purdy
    Oracle Coherence: Data Grid for Java and .NET

  • Re: it's done when it's done

    by Michael James,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yes, in practice many businesses don't need to ship every Sprint. This is why Ken Schwaber uses the term "potentially-shippable product increment" and describes a "stabilization Sprint" for low-risk polish and packaging activities. Unfortunately people misinterpret "stabilization Sprint" as a place for testing and integration which you should be doing every Sprint.

    --mj

  • Re: it's done when it's done

    by Michael James,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The Scrum paradigm makes too many assumptions about the project lifecycle that are not universally true; probably the most controversial is that code should be shippable at the end of a sprint.


    Actually we say "potentially shippable product increment," which means shippable within one stabilization Sprint.

    But I'm curious why you feel this is the tail wagging the dog. What is everyone working on that's more important than the ability to get a product out the door?

    --mj

  • Re: it's done when it's done

    by Ralph van Roosmalen,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    * Time and cost to meet regulatory, environmental, independent, or third-party test requirements.
    * Time and cost to reproduce CDs, PROMs, or other delivery device.
    * Time and cost to install software.
    * Time and cost to reproduce and distribute user documentation.
    * Time and cost to train sales and support staff.
    * If development environment does not fully reflect production, time and cost to restest and develop rollback procedures.


    It's only an example but I want to react on these activities...

    * Time and cost to meet regulatory, environmental, independent, or third-party test requirements.
    So you do this only once? Isn't that a pile-up of potential problems, so creating waste in your production?

    * Time and cost to reproduce CDs, PROMs, or other delivery device.
    Automate it!

    * Time and cost to install software.
    Automate it!

    * Time and cost to reproduce and distribute user documentation.
    In our organisation this is not a development activity, we create the base documents and other part of the organisation reproduce it. But I agree, you don't want to reproduce user documentation for an release that will not be shipped to customers.

    * Time and cost to train sales and support staff.
    This is not included in our sprint, we deliver software, we don't train people during the sprint. And why not train sales after every sprint, so they can demonstrate the new software at the customer site (On there own laptop)? This gives you a lead on your competitors who don't use Scrum (agile).

    * If development environment does not fully reflect production, time and cost to restest and develop rollback procedures.
    Change it!

    Scrum isn't easy, and to do it well you have to have a good automated process. And of course it's easy to say just automate it... but in my opinion it's very important to automate the process and become very efficient.

  • Re: it's done when it's done

    by Deborah (Hartmann) Preuss,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Michael, you assume someone wants the software. IT spent a decade training users to take what they're given, when they are given it. This has removed the pressure from customers to deliver!

    I suspect we sometimes, now, pull back from promising frequent delivery, in case they take us seriously! Which, of course reveals insecurity. The only way to get past this is, of course, is to make the promise, track your progress against it, and aggressively remove obstacles!

    Customers are typically willing to extend us the benefit of the doubt when they understand we are working for their benefit.

  • Shippable = done + usable

    by Javid Jamae,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    If you say you are done with something and you have to go back and do "hardening" then you're not done.

    IMO the "potentially" part of "potentially shippable" means that you might not be able to ship because you don't have a set of cohesive features done. For example, you finished an edit feature, but you haven't finished the add feature yet. Though all the features that you've implemented are "done", you can't ship because its not usable without an add.

  • Re: it's done when it's done

    by Javid Jamae,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The difference between Done and Shippable arises because there are some tasks that are not feasible to do for every iteration due to time or cost.


    If they are tasks that are associated with the feature, then the feature should not be marked as done until those tasks are done. You shouldn't redefine the word done just because you can't finish the tasks within the timebox you've specified. That's why we've come up with ridiculous terms such as "done done". You should work to come up with ways to improve the lead time on those tasks that take longer. Most of the ones you've listed could be done in a more agile/lean/iterative way if the organization put some good thought into it.

    Time and cost to train sales and support staff.


    That has nothing to do with done or shippable. That has to do with "in production".

  • Re: it's done when it's done

    by Michael James,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    That has nothing to do with done or shippable. That has to do with "in production".


    "In production" has a lot to do with "done." Putting something in production is a reasonable thing to request when planning a stabilization Sprint.

    Remember "done" is negotiated between the Product Owner and the Team.

    --mj

  • Transitioning from "potentially shippable" to "shippable"

    by Michael Sawicky,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    One of the biggest challenges for transitioning between “potentially shippable” and “shippable” is when a release must be verified against customer data – specifically for systems that operate against hundreds of millions of transaction records that may be “owned” by other systems. The cycle for acquiring and loading a current set of customer transactions and regression testing all “potentially shippable” enhancements can consume several days - even if the automated regression test only require a few minutes of run time (although more likely these systems require batch executions that consume several hours of processing time).

    This may be an example of an extreme case, but the good news is that even this extreme challenge can be managed by combining careful planning with a strong discipline to test frequently enough to prevent build up of too much risk. The task is to arrive at a minimally sufficient test frequency that minimizes risk in a cost-effective way. Typically, the scope of this challenge is beyond the mission of any development iteration. Instead it must be interspersed between feature development work or coordinated as an external effort that is executed in parallel with feature development. The real challenge is not so much the coordination of the work streams, but in getting sponsorship and commitment to make it a priority. Simply deferring this type of testing to a “hardening sprint” will result in having too much risk too late in the game.

  • Task definition at fault?

    by Chris Cundill,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Just a quick thought: perhaps the definition of tasks needed to achieve a product/goal is lacking? If tasks only cover coding and testing activities then planning has fallen short. Maybe if all the tasks needed to achieve a product/goal were properly defined, it would be possible to have a shippable product (with polish applied) within one sprint and negate the need for stablization sprints or such like.

  • 'Done-Done' checklist with Mind Map diagrams

    by tribhuwan negi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Reference checklist for 'Done-Done' for User Story and 'End of Iteration' with Mind Map Diagrams is here-
    blog.tribhuwannegi.com/2012/03/mind-map-diagram...

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT