The main benefit of having a potentially shippable product at the end of each Sprint is the ability to release the product quickly in case market conditions change.

However, usually in the first half year or more the product doesn't have enough value to be actually shipped. So why spend all this energy to make a potentially shippable increment each Sprint if you know with complete certainty that the product won't be shipped?

  • Because after each sprint you'll have defects that you didn't fix. Then by the end of the project when it's supposed to be "ready to ship" it'll just be a pile of defects with some features thrown in. Jan 31, 2014 at 19:41

6 Answers 6

  • it allows for early feedback, not just from customers
  • it keeps management from getting nervous (they can 'see' the progress)
  • it keeps the dev. team into a good habit

And most important (at least in my opinion)

  • it makes you challenge your initial concept of a minimal viable product
  • it gives you the flexibility to redefine your minimal viable product

Potentially shippable doesn't necessarily mean that the product make sense or is desirable from a market perspective. Just that it works from an engineering one.

I understand 'potentially shippable' as an encouragement to manage technical and functional debt:

  • you should not break something that used to work (no regression)
  • you should have few enough defects that if you were to ship in emergency, it would be quick enough (a couple days) to fix
  • any feature or story declared 'done' should be working, if unperfect
  • any dead code (critical bug preventing access to a functionality or code not working at all) is NOT ok and needs to be fixed or finished with the highest priority.
  • minor bugs, polish, enhancements are ok, as they're just other stories and can be prioritized as they deserve

You seem to be painting yourself in a corner here.

I don't see why a product can't be minimally viable within weeks (if not days, for example see hackathons) instead of months. It depends on the product and the market and who you are shipping to, and for what purpose.

  1. What do you mean by "minimally viable"? Does it need to be polished? If so, how would it be minimally viable? In many cases I've seen products never becoming minimally viable because "no one would buy them". But that's not what minimally viable means. A product you can't sell, you can demo or trial, for example. Or you can give away a minimal version without all the bells and whistles for free to build user base before you introduce new features.

    Keeping the product under wraps until it's "ready" (big-bang release) it's the opposite of MVP. :-)

  2. By definition, each iteration will deliver value in form of potentially shippable increments. Since iterations iterations do deliver value, why isn't the product minimally viable? I agree it won't be great, though, initially and probably not sell-worthy.

  3. "Viable" doesn't mean anything by itself: for what purpose it should be viable?

  4. Who are we shipping to? Not all users have the same requirements. You can often ship to a subset of users much earlier.

A personal anecdote. At Stack Exchange we are always shipping. Let's take our own mobile apps: as soon as we had the build system created, we started using them internally. There was a build going out to interested internal employees within weeks, and an alpha/beta program for selected users. Most of these users did not see a polished, complete, bug-free app, but the feedback we got was invaluable. We are now shipping our first app "for real", openly, to the public, but there's absolutely no doubt that our earlier "potentially shippable" increments were super-valuable for feedback and field testing.

  • Thanks for the answer, but allow me to ask to you something. The first version of Stack Exchange was not bug-free? That's not potentially shippable.
    – Eugene
    Feb 1, 2014 at 7:16
  • “Minimally viable” = “the walls are up and the services are in, but it's not been decorated and furnished yet”. Fortunately, the profile of costs of development of software is totally different to that of building a house. Feb 1, 2014 at 9:10
  • 1
    "I don't see why a product can't be minimally viable within weeks (if not days, for example see hackathons) instead of months.": The fact that for some products it is possible to produce some valuable functionality within weeks does not mean that this is possible for all products.
    – Giorgio
    Feb 1, 2014 at 9:34
  • 1
    @user3251930 no software is bug free, but certainly most shipped software is shippable
    – Sklivvz
    Feb 1, 2014 at 10:59
  • @Giorgio it's certainly not possible in many cases, but if we restrict the scope to products that can be delivered with agile development (in other words that can be delivered incrementally) then it becomes basically a tautology.
    – Sklivvz
    Feb 1, 2014 at 11:02

No, the main benefit of having a potentially shippable product at end of each iteration is ability to get early feedback, to show developers are actually doing something and to motivate developers to actually do something. The "potentially shippable" has nothing to do with actually being able to ship it, but fact that the software has to be in shippable quality.

In this case, there is no problem having really bare-bones product at beginning of the project, as long as customer is able to produce feedback based on it.

  • You can get early feedback without producing a shippable product. For example you don't need to fix all bugs or test the product very thoroughly. Usually a half baked feature is enough to get good feedback.
    – Eugene
    Jan 31, 2014 at 18:39
  • @user3251930 The problem with what you say is that the customer might think that the product is already usable and will wonder why you still have to spend more time to make it work. Which usually means you are not given that time for testing and fixes. Thus increasing the technical debt.
    – Euphoric
    Jan 31, 2014 at 18:59

Part of the reason is that it is up to stakeholders to determine when the product is worthy of release, and this determination is based upon demonstrating the results of each sprint. At any arbitrary point, the product could be deemed "good enough" and released.

It may take many more iterations to bring the project to completion, but it's quite possible that a very small sub-set of features provide the bulk of the product's value, making it worthwhile to release early. If prioritization is done right, those features should be done first.

Iterative development methodologies make no assumptions about how early that "good enough" stage is reached, so it's easiest to make sure the product can always be shipped.


There is value in having a shippable product because it implies that the product quality has been kept higher than it would be if development was performed with a longer term shipping plan.

One has to keep in mind the motivation for the "shippable" requirement. In many software projects with a long development schedule, a lot of resources might go into developing one portion of the software, usually the area called "essential infrastructure" when communicating with higher level managers. This may lead to an imbalance whereby too much resources are spent on one area, while other areas, such as testing, or UI design, are starved of resources. In the end, resources may run out, and the end result is an unusable product.

If on the other hand, the product is kept "shippable", the project at least feels like it was not a complete waste, even if the plug is pulled on development mid-way.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.