To understand the birth of ‘Potentially Shippable Increment’, or P S I., we have to rewind the clock to the 1990s. At that time, the traditional waterfall model was the default approach to software development. Projects were meticulously planned upfront and executed in strict stages—from requirements gathering to design, coding, testing, and delivery. It was a linear process, and products were shipped only when every stage was complete.
In Scrum and other Agile methodologies, ‘done’ is defined by a ‘Definition of Done’ or D o D, a set of criteria for a task, story, or product increment to be considered complete. The D o D is essential for maintaining quality and ensuring that everyone on the team understands what it means to complete a piece of work. The D o D can include criteria related to coding, testing, documentation, and any other activities necessary to prepare a piece of work for release. The concept of potentially shippable products has evolved, just like the products it helps create.
One of the primary challenges is defining ‘done’. Each increment must be fully functional and deliver value, but what does that look like for your product? This might seem simple, but defining ‘done’ requires a clear understanding of the product’s vision, the users’ needs, and the team’s technical capabilities. Another challenge is ensuring high quality in each increment. The term “possibly shippable” means it’s ready to be put into the hands of users and demands rigorous testing and quality commitment. You don’t want to ship something potentially full of bugs.
Building quality from the start and maintaining robust testing practices are essential. A significant challenge is technical debt. Suppose the team is pressured to deliver increments rapidly. In that case, there’s a risk of accumulating technical debt—quick and dirty shortcuts that make the product work in the short term but can lead to problems. Balancing delivery speed with sustainable development practices is crucial. Market readiness and user adoption are challenges.
Just because a product increment can be shipped doesn’t necessarily mean it should be. Each release must be strategically timed, and the market should be ready. You must also consider how each new release will affect your user base. To consistently deliver potentially shippable products, a team must be cross-functional, highly collaborative, and empowered to make decisions. Building and nurturing such a team is a challenge in itself.
The potentially shippable product increment is a broader concept. It refers to a complete product version that could be shipped to customers per the D o D. It’s more about the state of the product as a whole than individual tasks or stories. A potentially shippable product increment doesn’t necessarily have to be released (that decision depends on various business factors). Still, it should be releasable in terms of quality and functionality.
In other words, ‘done’ refers to completing individual pieces of work according to a predetermined set of criteria. A potentially shippable product increment is an accumulation of ‘done’ work that is coherent and valuable and could be released to customers if chosen. The two concepts are connected but operate at different granularity levels. It’s also worth noting that the specific definitions of ‘done’ and ‘potentially shippable’ can vary from one team or project to another, depending on factors like the nature of the product, the team’s working practices, customers’ needs and expectations, etc. Therefore, each team must discuss and agree on these definitions upfront to ensure a shared understanding. Critical summary behind the concept of “potentially shippable product.”
A potentially shippable product is not merely a collection of features or individual pieces of functionality. It’s a cohesive, integrated whole that delivers value to the user. Just because a particular feature or component is completed doesn’t necessarily mean that the product is potentially shippable. Each increment must fit into the larger product meaningfully and contribute to the overall value proposition. Despite the term ‘shippable’, a potentially shippable product is not necessarily released or shipped to the end user at the end of each sprint or iteration. The ‘potential’ is crucial here. It means that the product is in a state where it could be released if the team decides it’s beneficial, but it doesn’t have to be. The ‘shippable’ part of a ‘potentially shippable product’ doesn’t mean the product bypasses any testing or quality assurance stages. On the contrary, it implies that the product increment has been thoroughly tested and is of a quality that could be released to users. It’s not a raw or half-baked increment but a polished, tested one.
While a potentially shippable product is a fully functional and valuable increment, it is not the final product. It’s a step or a stage in the journey towards the complete product. It’s currently a product version, different from when the entire product vision was realised. A potentially shippable product isn’t a product that is void of user value. Suppose the increment can’t help users solve a problem, achieve a goal, or deliver value somehow. In that case, it’s not shippable, no matter how much work has gone into it. A potentially shippable product is connected to business goals and objectives. It should align with the product’s strategic vision and contribute to achieving business goals.
Who is responsible for deciding the release of the potentially shippable increment? In an Agile team structure, the decision to release a potentially shippable product usually involves collaboration and agreement between several roles. However, the ultimate decision often lies with the Product Owner, based on business needs, strategy, and stakeholder input. The Product Owner is the key stakeholder representing the business and customer’s interests. They comprehensively understand the market, customer needs, and business strategy. Therefore, they are best equipped to decide when it’s the right time to release a product increment. They can assess whether the increment brings enough value to the customers and aligns with the business goals.
The Scrum Master ensures that the team adheres to Scrum practices and principles, facilitates team interactions, and removes impediments. While they don’t decide when to release, their role is critical in ensuring the product increment is truly potentially shippable in terms of quality and alignment with the Definition of Done. The Development Team works on delivering a potentially shippable product increment at the end of each sprint. They contribute valuable input on technical aspects but usually wait to decide to release. Finally, external Stakeholders, such as management or other business stakeholders, may also have a say in releasing. They may provide valuable input on business strategy, market conditions, or customer needs.
In summary, while the entire Scrum team collaborates and contributes to getting a product to a potentially shippable state, the Product Owner usually decides whether and when to release it based on various business factors, which may vary somewhat depending on the specifics of the organisation or project. A potentially shippable product is not an unfinished, untested, value-less increment of work that gets shipped at the end of every sprint, irrespective of user needs or business objectives. Instead, it’s a quality, value-delivering increment that fits into the larger product vision and could be released to users if the circumstances are right.
