"potentially shippable" vs "truly shippable"

[dotnetguy]

"Potentially shippable" and "truly shippable" have different meanings
in the context of Scrum. Please explain these differences in a
nutshell....

[Vernon Stinebaker]

Why would there be a difference?

Potentially shippable simply means the Product Owner has the responsibility/right to decide whether or not to actually ship the product increment. The team has the responsibility of delivering a (truly?) shippable product increment each and every sprint. If the team doesn't deliver this, the Product Owner's right to decide is lost and therefore the product increment is not potentially shippable.

-Vernon

Sent from my iPad

> --
> You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
> To post to this group, send email to scruma...@googlegroups.com.
> To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.
>

[RonJeffries]

Well ...

Truly shippable is not a Scrum term AFAIK.

Potentially shippable means that the product is technically good enough to ship. The team determines just what this means using the Definition of Done but it generally means quite free of bugs, runs all the tests, and the code is clean. It means if the PO looked at it and decided that the backlog items reported as done were enough to make a product, we could ship it then and there.

I like to say "If they happen to walk in and want to ship it, we should be able to say 'Take the top CD off that stack'."

Ron Jeffries

www.XProgramming.com

I know we always like to say it'll be easier to do it now than it

will be to do it later. Not likely. I plan to be smarter later than

I am now, so I think it'll be just as easy later, maybe even easier.

Why pay now when we can pay later?

[Dan Rawsthorne]

"potentially shippable" has little to do with shippability, and a lot to do with quality. Here is the definition: Potentially Shippable means that "the increment consists of thoroughly tested, well-structured, and well-written code that has been documented and built into an executable reviewable by the Stakeholders" (see Ken Schwaber, The Enterprise and Scrum, Microsoft Press, 2007, pg. 112). The idea is that if the increment had enough functionality to be useful, then it has enough quality to be willing to ship it - it is not a prototype, it is 'real' code. This confuses a lot of people, so I don't use the phrase. I use "demonstrably done and reviewable" since that's what it really means... and this latter phrase can refer to results other than software. In Ken's scrum class (which I've taken twice now, once in 2003 and once in 2010) he emphasizes this: potentially shippable means that the Team has done its due diligence and created appropriate quality code, hence it is "potentially shippable" if the PO thinks there's "enough there" to want to ship it.

As far as I know, "truly shippable" is not a scrum phrase, and so I assume it actually means shippable - it has the functionality and the quality we want.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

[George Dinwiddie]

Andrew

I suggest evaluating what the differences are in your context.

* What does it take to put your software into the hands of actual
users? That's truly shipping.
* What do you presently consider "done" for development? Would you
call that "potentially shippable"
* What needs to be done to get from the second point to the first? Can
any of that be done sooner?

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[John Miller]

Decision to Release vs Shippable? Is that the question?

Thank You,
John
Sent from my iPhone. It likes to sabotage my grammar.

[Ken Rubin]

In my soon-to-be-published book Essential Scrum, I defined "potentially shippable" in the following way:

"This definition (of done) specifies the degree of confidence that the work completed is of good quality and is potentially shippable. 

For example, when developing software, a bare-minimum definition of done should yield a complete slice of product functionality that is designed, built, integrated, tested, and documented. An aggressive definition of done enables the business to decide each sprint if it wants to ship (or deploy or release) what got built to internal or external customers.

To be clear, “potentially shippable” does not mean that what got built must actually be shipped. Shipping is a business decision, which is frequently influenced by things such as “Do we have enough features or enough of a customer workflow to justify a customer deployment?” or “Can our customers absorb another change given that we just gave them a release two weeks ago?”

Potentially shippable is better thought of as a state of confidence that what got built in the sprint is actually done, meaning that there isn’t materially important undone work (such as important testing or integration and so on) that needs to be completed before we can ship the results from the sprint, if shipping is our business desire."

BTW, I have never heard the term "truly shippable" before.

Hope this helps...

Regards,

Kenny

Enter a drawing for a free copy of my forthcoming book: "Essential Scrum: A Practical Guide to the Most Popular Agile Process" at www.essentialscrum.com.

Managing Principal, Innolution, LLC

Phone: (303) 827-3333

book | website | email | linkedin | twitter 

[dotnetguy]

"While the product needs to be solid at the end of each sprint, we
call it *potentially* shippable as a reminder that the developed
features may not be sufficient yet to be truly shippable."

Succeeding with Agile: Software Development Using Scrum, Mike Cohn

[Michael Vizdos]

All of these definitions really are just a slippery slope to avoid being "Done."

Not "Done. Done."

Or "Done. Done. Done."

Or.

Whatever.

Thank you,

- Mike Vizdos

My site: michaelvizdos.com
Cartoons: implementingscrum.com
Twitter: twitter.com/mvizdos
Facebook: facebook.com/vizdosenterprises
Google+: gplus.to/MichaelVizdos
LinkedIn: linkedin.com/in/mvizdos

PS --> In my spare time I am also involved as the Executive Director
with Gangplank Henrico.

Learn more at:

www.GangPlankHenrico.org
facebook.com/GPHenrico
groups.google.com/group/gangplank-henrico
www.twitter.com/GPHenricoCty
www.meetup.com/GPHenrico

www.whatisgangplank.com
www.gangplankhq.com

[George Dinwiddie]

John,

On 7/12/12 9:07 AM, John Miller wrote:
> Decision to Release vs Shippable? Is that the question?

I'm sorry, but I don't understand your question.

- George

[dotnetguy]

I think 1 example Mike Cohn mentioned was that a developer could
develop a print preview feature in 1 release and then the print
feature in a subsequent release. A user would not care about print
preview without print so the product would not be truly shippable.
However, the print preview feature itself would be potentially
shippable. Maybe this is what Mike Cohn meant by "potentially
shippable" vs "truly shippable."

> >> For more options, visit this group athttp://groups.google.com/group/scrumalliance?hl=en.

[George Dinwiddie]

Andrew,

On 7/13/12 11:33 AM, dotnetguy wrote:
> I think 1 example Mike Cohn mentioned was that a developer could
> develop a print preview feature in 1 release and then the print
> feature in a subsequent release. A user would not care about print
> preview without print so the product would not be truly shippable.
> However, the print preview feature itself would be potentially
> shippable. Maybe this is what Mike Cohn meant by "potentially
> shippable" vs "truly shippable."

That's a nice illustration of the point. In that situation, were I the
product owner I would choose to work those stories in the opposite
order. That way there's no difference between potentially and truly
shippable.

There are other aspects of "truly shippable" that have been woven into
this discussion. Think about the case of shrink-wrapped software. Part
of truly shippable includes designing the box, making a master CD or
DVD, preparing advertising campaigns, etc. It's helpful to think about
how some of this can be done earlier, rather than as an "after
development" phase.

[Dan Rawsthorne]

Well, as I stated before, the phrase "potentially shippable" comes from Ken, and is baked into scrum itself, so we don't actually have to guess what it means... just sayin'...  Dan  ;-)

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

[RonJeffries]

Dan,

On Jul 13, 2012, at 12:34 PM, Dan Rawsthorne wrote:

Well, as I stated before, the phrase "potentially shippable" comes from Ken, and is baked into scrum itself, so we don't actually have to guess what it means... just sayin'.

That's not clear to me. I think we always have to guess what people mean, and Ken is far from an exception to that notion, even if he has been exactly right all these years. Which I think is ... unlikely.

Ron Jeffries

www.XProgramming.com

If not now, when? -- Rabbi Hillel

[dotnetguy]

@George - Executing those tasks in the reverse order was my first
thought as well.  I think in the example Mike gave, he suggested that
print preview could be squeezed into the sprint while print was larger
and had to be deferred to a dedicated sprint.  It may be possible that
print preview also provided some infrastructure for print as well.
 But I concur with your initial impression on this.

It seems like there's different opinions on whether "definition of
done" = "potentially shippable" = "actually shippable"....

[Michael James]

To me "potentially shippable" is necessary but insufficient to achieve "worth selling." While it would be admirable if the product were *worth selling* to a customer the very first Sprint, this involves business decisions that are ultimately the Product Owner's call. The development team is responsible for *potentially shippable* (e.g. properly tested), which should be within their control.

--mj
(Michael)

[George Dinwiddie]

Andrew,

On 7/13/12 1:19 PM, dotnetguy wrote:
> @George - Executing those tasks in the reverse order was my first
> thought as well. I think in the example Mike gave, he suggested that
> print preview could be squeezed into the sprint while print was larger
> and had to be deferred to a dedicated sprint. It may be possible that
> print preview also provided some infrastructure for print as well.
> But I concur with your initial impression on this.
>
> It seems like there's different opinions on whether "definition of
> done" = "potentially shippable" = "actually shippable"....

There are always gray areas, and the devil is in the details. The
important aspect, in my mind, is that we keep thinking about it and keep
improving.

[dotnetguy]

ok - sounds like "definition of done" is a requirement for new
features while "potentially shippable" is more of a mantra for
continuous improvement and refinement to the "definition of done".
Agreed?

[Joe Blauer]

Hi Andrew,

That's really splitting hairs IMHO, and exactly contrary to George's point which I take as: 

Let's not get hung up on the exact meanings of words and phrases, and remember what we're trying to accomplish, which is to provide something as useful as possible as early as possible.

--

JOE BLAUER, MBA
ASSOCIÉ / PARTNER

☎ 514 262-3939 #202
❑ www.tp1.ca

[dotnetguy]

Hi Joe - If you're helping a client transition towards a pm framework
I think it's good to have a clear understanding of concepts in that
framework and be able to explain those concepts to the client with
confidence.

For example, a client might be new to Scrum and at the end of a Sprint
ask why a feature was not shippable.

Or based on a client's understanding of Scrum he might make a
declaration in the planning meeting that all features delivered in the
Sprint must be shippable.

These are real-world scenarios. It's good to be prepared for these
scenarios by being confident in your own understanding of these grey
areas....

On Jul 13, 1:30 pm, Joe Blauer <jbla...@tp1.ca> wrote:
> Hi Andrew,
>
> That's really splitting hairs IMHO, and exactly contrary to George's point which I take as:
>
> Let's not get hung up on the exact meanings of words and phrases, and remember what we're trying to accomplish, which is to provide something as useful as possible as early as possible.
>
> --

> JOE BLAUER, MBA
> ASSOCIÉ / PARTNER
>
> ☎514 262-3939#202

> ❑www.tp1.ca

[Joe Blauer]

Andrew,

I always like to begin the discussion with one of values, a very important one of which is to "embrace the grey"

The agile mindset takes its start from the hypothesis that many sins have been committed in the name of precision, before precision is warranted.

Tough sell, I know. But the data bears it out.

--

JOE BLAUER, MBA

ASSOCIÉ / PARTNER

☎ 514 262-3939 #202

❑ www.tp1.ca

[dotnetguy]

Joe - I think the definition I provided above provides a reasonable
definition of potentially shippable:

"potentially shippable" is a mantra for continuous improvement and

refinement to the definition of done.

I don't think this is too precise at all.  I think "continuous
improvement" and "refinement" indicate that the meaning of
"potentially shippable" is not necessarily black and white....

On Jul 13, 2:04 pm, Joe Blauer <jbla...@tp1.ca> wrote:
> Andrew,
>
> I always like to begin the discussion with one of values, a very important one of which is to "embrace the grey"
>
> The agile mindset takes its start from the hypothesis that many sins have been committed in the name of precision, before precision is warranted.
>
> Tough sell, I know. But the data bears it out.
>
> --

[John Miller]

You can can continuously improve and still not having something
shippable. I can still ship something and not continuously improve.

Thank You,
John
Sent from my iPhone. It likes to sabotage my grammar.

[George Dinwiddie]

Andrew,

On 7/13/12 2:17 PM, dotnetguy wrote:
> ok - sounds like "definition of done" is a requirement for new
> features while "potentially shippable" is more of a mantra for
> continuous improvement and refinement to the "definition of done".
> Agreed?

I would say that Potentially Shippable is the minimum generic Definition
of Done. Teams then need to decide what, exactly, these mean for them.
As part of continuous improvement, they should refine and improve these
over time.

- George

>
>
> On Jul 13, 12:43 pm, George Dinwiddie <li...@iDIAcomputing.com> wrote:
>> Andrew,
>>
>> On 7/13/12 1:19 PM, dotnetguy wrote:
>>
>>> @George - Executing those tasks in the reverse order was my first
>>> thought as well. I think in the example Mike gave, he suggested that
>>> print preview could be squeezed into the sprint while print was larger
>>> and had to be deferred to a dedicated sprint. It may be possible that
>>> print preview also provided some infrastructure for print as well.
>>> But I concur with your initial impression on this.
>>
>>> It seems like there's different opinions on whether "definition of
>>> done" = "potentially shippable" = "actually shippable"....
>>
>> There are always gray areas, and the devil is in the details. The
>> important aspect, in my mind, is that we keep thinking about it and keep
>> improving.

[dotnetguy]

@John

> You can continuously improve and still not have something shippable.

If a team continuously improves at aligning their definition of done
with potentially shippable and they can't meet their definition of
done then the team should probably identify problem statements
regarding why they're not able to achieve their defined definition of
done.

> I can still ship something and not continuously improve

If you're definition of done is aligned with potentially shippable and
all of the conditions of satisfaction have been met in your shipped
product then you are doing very well.  In reality there are usually
ways to improve especially since various factors change over time -
see kaizen....

On Jul 13, 2:39 pm, John Miller <agilescho...@gmail.com> wrote:
> You can can continuously improve and still not having something
> shippable. I can still ship something and not continuously improve.
>
> Thank You,
> John
> Sent from my iPhone. It likes to sabotage my grammar.
>

[dotnetguy]

@George,

> I would say that Potentially Shippable is the minimum generic Definition of Done

I think this statement may be a bit off.  If a team creates an
insufficient DoD then the features won't be sufficient to be
potentially shippable.

However, the team can continuously improve and refine their definition
of done so features will be as close as possible to potentially
shippable and in some cases truly shippable.....

[John Miller]

Yes, I agree.
But, my statement prior still holds true by rules of logic.

Kaizen is a big part of Scrum. I actually view Scum primarily as a
Learning Framework for teams and organizations. Awesome results are
the outward manifestation of continuous improvement.

In defining our terms, CI and DoD are independent. Although, one
should engage in CI to reach their DoD and to adapt their DoD.

Thank You,
John
Sent from my iPhone. It likes to sabotage my grammar.

[John Miller]

Hi George,

I am wondering if Andrew's question is really defining the difference
between "potentially shippable" vs the actual act or decision to
"Release" a feature.

Did his "truly shippable" mean a decision to Release the "potentially
shippable product "

Who's on first?

Thank You,
John
Sent from my iPhone. It likes to sabotage my grammar.

[John Miller]

Potentially Shippable - Is a fundamental concept for all Sprints,
Teams, and Products/Services a Scrum Team adheres to.

Def of Done - unique, detailed, and specific to the context of the
team, customer and produce.

Truly shippable is not a recognized term by the Scrum community.

Thank You,
John
Sent from my iPhone. It likes to sabotage my grammar.

[dotnetguy]

@John - My point is that DoD should align as much as possible with
potentially shippable.  A team's DoD will not always end up being
potentially shippable even if the team intended it to be for a variety
of reasons.

Teams will often discover gaps between their DoD and potentially
shippable.  Continuous improvement and refinement should be used to
help close this gap.  Is there any part of this statement you disagree
with?

On Jul 13, 3:51 pm, John Miller <agilescho...@gmail.com> wrote:
> Potentially Shippable - Is a fundamental concept for all Sprints,
> Teams, and Products/Services a Scrum Team adheres to.
>
> Def of Done - unique, detailed, and specific to the context of the
> team, customer and produce.
>
> Truly shippable is not a recognized term by the Scrum community.
>
> Thank You,
> John
> Sent from my iPhone. It likes to sabotage my grammar.
>

[John Miller]

Hi Andrew,

There is not only alignment, but, DoD defines potentially shippable
for that team. They are one and the same for a team. I think you
caught the scent, but, you need to move further.
Potentially shippable is a "universal concept" for all Scrim teams.
DoD is the "localized " translation of that concept for a particular
team at a particular time.

Thank You,
John
Sent from my iPhone. It likes to sabotage my grammar.

[dotnetguy]

Yes - DoD should be the same as potentially shippable and that is the
goal of DoD but I'm recognizing that potentially shippable may go
beyond a team's basic understanding of DoD at a given point in time so
a team should inspect and adapt their DoD as gaps between these 2
states are discovered.

Therefore DoD is not necessarily potentially shippable (although it
should be) but rather a team's best assessment at a given point in
time so CI and refinement should be used iteratively to align DoD as
closely as possible with potentially shippable....

On Jul 13, 5:00 pm, John Miller <agilescho...@gmail.com> wrote:
> Hi Andrew,
>
> There is not only alignment, but, DoD defines potentially shippable
> for that team. They are one and the same for a team. I think you
> caught the scent, but, you need to move further.
> Potentially shippable is a "universal concept" for all Scrim teams.
> DoD is the "localized " translation of that concept for a particular
> team at a particular time.
>
> Thank You,
> John
> Sent from my iPhone. It likes to sabotage my grammar.
>

[John Miller]

If it does not meet DoD, then it is not shippable, by definition.
If teams are shipping and not meeting their explicit written DoD, then
they are operating from a different DoD, even if it is unwritten.

A written DoD should reflect the actual criteria one would make the
decision to ship. Perhaps this is what you mean, that, the written DoD
should be congruent with the behavior and vice versa.
This seems to be an integrity and discipline problem, not a definitional one.

I have been wrong before and perhaps splitting hairs.

Sent from my iPad

[dotnetguy]

Hi John - I think I explained my perspective as clearly as possible in
my last post.  You don't seem to be disagreeing with anything in my
last post although it seems like you may not be completely clear on
how I presented my perspective.

So I think we can probably leave this thread as-is for now unless
someone else wants to jump in to agree or disagree with anything we've
discussed....

On Jul 13, 6:30 pm, John Miller <agilescho...@gmail.com> wrote:
> If it does not meet DoD, then it is not shippable, by definition.
> If teams are shipping and not meeting their explicit written DoD, then
> they are operating from a different DoD, even if it is unwritten.
>
> A written DoD should reflect the actual criteria one would make the
> decision to ship. Perhaps this is what you mean, that, the written DoD
> should be congruent with the behavior and vice versa.
> This seems to be an integrity and discipline problem, not a definitional one.
>
> I have been wrong before and perhaps splitting hairs.
>
> Sent from my iPad
>

[John Miller]

Could be. Sounds good.

Sent from my iPad

[Dan Rawsthorne]

Not for me. Potentially Shippable is part of the definition of done for any story involving product. For others it makes no sense, obviously. Features are (usually) epics made up of such stories, and need to be Actually Shippable at some point. As mj and others have pointed out, this last  is a product ownership issue, not a devteam issue.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

[dotnetguy]

@Dan - I hear you saying that you explicitly include "potentially
shippable" as a criterion in your DoD.

IMO - "potentially shippable" is the goal that DoD aspires to.  DoD
can be improved after lessons learned each iteration to more
effectively and efficiently support that goal.

It seems to me like your approach is similar to including "done" as a
criterion in DoD....

On Jul 14, 3:24 pm, Dan Rawsthorne <drawsth...@gmail.com> wrote:
> Not for me. Potentially Shippable is part of the definition of done for
> any story involving product. For others it makes no sense, obviously.
> Features are (usually) epics made up of such stories, and need to be
> Actually Shippable at some point. As mj and others have pointed out,
> this last  is a product ownership issue, not a devteam issue.
> Dan Rawsthorne, PhD, PMP, CST

> 3Back.com <http://www.3Back.com>
> Author of /Exploring Scrum: the Fundamentals/
> <http://www.amazon.com/dp/1461160286>

[George Dinwiddie]

Andrew,

On 7/14/12 4:59 PM, dotnetguy wrote:
> @Dan - I hear you saying that you explicitly include "potentially
> shippable" as a criterion in your DoD.
>
> IMO - "potentially shippable" is the goal that DoD aspires to. DoD
> can be improved after lessons learned each iteration to more
> effectively and efficiently support that goal.

If you're not creating potentially shippable software each sprint,
you're not really doing Scrum. You're just going through the motions.
Ken Schwaber is pretty clear on this.

I see no value in going through the motions of any Agile method and not
producing potentially shippable software at each increment.

[dotnetguy]

That's right George - DoD is the criteria that a team defines in order
for a feature to be potentially shippable....

[Dan Rawsthorne]

No, I said that DoD must include what needs to be included to make the results potentially shippable. I don't use the term myself, as I find that most people get confused. I say "demonstrably done"...

Dan Rawsthorne, PhD, PMP, CST
3Back.com

Author of Exploring Scrum: the Fundamentals

[Tom Mellor]

It's never done until you ship it. Then you'll find out from users and customers how done it is.

[dotnetguy]

@Tom - That's right.  CI and refinement should be used to align DoD
with customer expectations.