One of the core concepts of Scrum is to produce working software each sprint. The Scrum Guide is very clear:
Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it.
This is what we often refer to as potentially shippable. It means that the features we’ve completed so far are not only code complete but have also been tested and are free from any critical bugs. At the end of the sprint, if the product owner says “awesome, let’s release this!”, we would be confident to do so. And that without us then having to integrate, do functional testing, code refactors, performance testing, bug fixing and so on.
Without potentially shippable software, we’re missing the point of sprints
There are several reasons why the potentially shippable increment is so important:
- Shorter feedback loops. The most valuable feedback from customers and users is the one they give us once they can see and use the functionality we have built. Only then will they be able to say definitely “yes, this is what we need”. The less frequently we’re able to show them working software, the bigger the risk that we are building the wrong thing.
- Creating value. Imagine that we run out of time in our project or that we have to move on to something else. Everything being 60% complete would mean we would have delivered nothing. “Oh, yeah, much of the functionality is there but there are a few horrible bugs and we need to build the UX”. In contrast, consider if we had built 60% of the features to a shippable state. We could ship and people would be able to use the product to do most of the things we intended.
- Avoiding surprises. If we integration and testing to the end, or do it in bigger batches every few sprints, chances are we are in for some nasty surprises. We might well come across some quite fundamental bugs or incorrect assumptions, which will take significant time to fix. Our release burn-up that was showing we were on track to hit our deadline turns out to be a complete fabrication! This is why the Agile Manifesto states that working software is the primary measure of progress.
Release sprints could tempt us to defer technical debt
Some suggest having a “release sprint” or “snagging sprint” before going live, to complete those final things needed to be truly shippable. However, in addition to the risks described above, this could lead us into temptation. Why bother with bug fixes, refactoring and so on now if we could focus on building new functionality instead?
Technical debt, such as this, will not only make the code harder and slower to work with. The longer we leave bugs and bad code, the more expensive the fix will be. By that time, will we have moved on to other features and forgotten about the intricacies of the code. We will also have added additional complexity, making the issues harder to fix than if we did it sooner.
Potentially shippable doesn’t mean it must be shipped
One important thing to point out is that a potentially shippable increment doesn’t necessarily mean that we will ship it. Quite often, we need to complete additional functionality before something becomes valuable to the users.
For example, imagine we are building a room booking system. As our first sprint goal, we make it possible to book a room. You can’t yet choose which room to book and you can’t edit or delete your booking, though. And you can’t see whether the room is available before booking it.
We built this functionality as a potentially shippable increment so we could release it. If we did, it would allow people to book this one room. Awesome! Do we ship it? Probably not, as it wouldn’t be all that valuable to the users yet.
Not shipping must not mean not learning
What we must do, however, is to make sure we learn more about our product from each product increment. If we were to spend four sprints before finding out that our underlying assumptions were wrong, we will have wasted a lot of effort!
The ultimate learning is shipping the product and see how it performs in the wild. However, if that’s not possible, we should try to get as close as possible. This could for example include deploying the increment to a “like-live” environment where the customer and/or other stakeholders can play with it to confirm it does what they expect it to.
Getting to potentially shippable increments may take time
It can be hard and take time to become able to produce truly shippable features in each sprint. However, we shouldn’t let that stop us from trying to get as close as possible.
The three main things to work towards are:
- A product backlog made up of user stories. The backlog items we bring into our sprints need to be “vertical slices” of user-facing functionality, rather than technical tasks, so that they can be shipped separately.
- A sufficiently strict Definition of Done. The Definition of Done defines what needs to be completed for each story to be considered done. We need to work towards this including everything we need to do to for the story to be shippable. This will typically include things like code complete, unit tested, user acceptance tested, performance tested, signed off by product owner (or customer), relevant documentation updated etc. Start by including what is feasible now and keep improving the DoD until ‘done’ means ‘shippable’.
- A cross-functional team. To be able to produce a potentially shippable increment, the team needs to be cross-functional, so that it doesn’t depend on anyone outside of the team in order to be able to do this. This means the team can’t just include people with programming skills. It also needs those with skills in requirements gathering, user experience design, testing etc.
Not always possible
In some cases, it won’t possible to get to a position where we can just press a button and ship. For example, to release an app to the Apple app store, the app needs to be approved by Apple. They may come back and say that we need to change something. Therefore, until the app has been approved, we’re not strictly done.
This approval used to take up to ten days, which would make it impossible to fit it into a sprint. In this case, the Definition of Done would probably include “ready to send to Apple for approval” rather than “approved by Apple”.
Finally, how do we know we have reached a point where our product really is potentially shippable? I quite like Troy Magennis’ approach. He suggests doing an anonymous survey to ask the developers “would you ship tomorrow?”. If high percentage say no, you are not there yet.