Categories

A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Scrum – What does ‘a potentially shippable candidate’ mean in terms of Sprint end ?

One of the most common terms in scrum relates to the milestone ending, or the Sprint ending timeline. At the end of every Sprint cycle, as part of the deliverables, there is an expectation of releasing the software in a form that is called ‘potentially shippable software’. And this is where there is a lot of confusion, even in my discussion among other Scrum Masters, there is confusion regarding the exact meaning of this term. Even in a team, until there has been discussion about what this means, there can be confusion; such confusion is unhealthy and needs to be prevented. The Scrum Master, as part of their tasks, should ensure that there has been a discussion about what does potentially shippable software means, and there is a conclusion within the team about this, along with discussion with the Product Owner to ensure that all the major stakeholders have agreement on this term (it would be a big shock for the team if the Product Owner does not agree with the team at the end of the Sprint on this topic).
So what does potentially shippable mean ? There can be many definitions for the same depending on the team and the nature of the project; but a simple definition for the same would be: When the features which are certified as potentially shippable can actually be sent to customers within 1-3 days of the date of the Sprint end, and the Product Owner also agrees that this is possible given the current state of the feature. Now, this is where the teams can have a disagreement, with several team members arguing that potentially shippable can be very difficult to achieve in the middle of a cycle, since the feature depends on several other items in the product, and you can’t just ship a feature to a customer. For example, your feature may be near perfect, but you certainly can’t expect the customers to get the product unless the installer that actually places the product on the machines of the customer is done, and the same is true overall of many other non-code items such as detailed documentation, Help Files, Localized versions of the features, and so on.
So, to get around these problems and to have a definition that the team can meet regularly, there are certain modifications that can be made to the definition of a potentially shippable product. Instead of defining this to mean that the feature can be shipped over to the customer, this could be meant to denote that all the code work for the feature is done, all the testing is done, the feature is in good shape, the Product Owner is happy with the quality of the feature and has confirmed that the feature delivered has met the requirements. And the most important requirement, that the feature can be shown to the customer in a complete state. However, this also means that when the Backlog is being defined by the Product Owner, the items in the Backlog should be setup as features valuable for the customer (or rather, since there will always be design and infrastructural items on the Backlog, maximize the creation of items on the backlog such that the number of items on the backlog that are of direct value to the customer). Another critical item for getting this done is to ensure that defects relative to a feature are fixed in the particular Sprint where the feature is being developed.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>