What does it mean to have a potentially shippable product increment each sprint?  Why does it matter? What happens if you cannot produce one each sprint? For scrum teams, and the organizations they serve, these are important questions to answer since they often influence the behavior of the group.

The product increment, or “increment” as listed in the scrum guide, is one of three artifacts defined in scrum.  It is the latest version of the product, created by completing product backlog items during a sprint. Product backlog items are pulled into the Sprint Backlog each sprint in an effort to maximize value to the organization and its customers.  This may seem obvious or rudimentary, it bears repeating since it’s often forgotten.

While scrum is not bound to software development, it is still its most frequent application.  In that context, maximizing value requires delivery of the latest product increment to a production environment.  In production, customers and users can benefit from the latest features and improvements. The pace at which an organization can satisfy the needs of its customers, compete with other providers, and learn are dependent on the ability to ship regularly.  Ideally, an organization would have the “option” to ship, or deploy to production, every sprint. When the option offers significant learning, benefit to customers, or competitive advantage, they will exercise the option.

[It’s worth noting that getting organizations to recognize the value in shipping frequently and taking advantage of the option is not a small undertaking. Many organizations are used to long running projects with no urgency to deliver before a date in the distant future]

Scrum teams must produce a potentially shippable product increment in order to make this option available.  Potentially shippable must mean that the product increment is both safe to ship and desirable to ship. Desirability is all about the effectiveness of the product owner to choose the right product backlog items and the development team’s ability to implement an effective solution.  Safety implies that the software has gone through rigorous testing and deployment to prove that it won’t break functionality or regress the user’s experience in any way.

Definition of Done

It’s not a formal scrum artifact, but the “Definition of Done” has its own section in the scrum guide because of its importance, the option to safely ship a desirable product increment every sprint.  Much has been written about the “Definition of Done” so we’ll keep it’s introduction to a minimum. In essence, the Definition of Done is an agreed upon checklist of conditions that make it safe to ship the latest product increment.

The checklist is created by the Development Team and serves as a standard of delivery.  It typically contains a commitment to testing, clean code that conforms to standards, deployment readiness and verification, and operations enablement to support the product.  Other things may be included too, but you get the idea.

Remember, the team’s goal is to create a potentially shippable product increment so the organization has the option to ship.  In order for that to be possible, the Definition of Done must include all of the things that allow the organization to feel confident that the software will work and be well supported.

Like any new skill, delivering software incrementally is hard at first.  Most new teams are unable to produce a potentially shippable product increment each sprint.  Consequently, they produce a Definition of Done that can realistically be achieved each sprint, but falls short of what’s needed to safely deploy.  You might be wondering, what’s the value in having an incomplete definition? Why bother?

I’m glad you asked.  Let’s start first with the Development Team, a group of cross-functional, skilled knowledge workers who pursue a shared goal every sprint.  Allowing the team to pursue an achievable definition of done each sprint, gives them a better chance to meet their sprint goal. Teams that meet their goals regularly build morale.  They feel good and believe they can meet future goals that are similar. They are also less afraid to challenge themselves and grow their capabilities.

Next, let’s consider the stakeholders.  These can be managers, directors, vice presidents and they can be from information technology, “the business”, partners, customers, etc.  They rely on the team to complete their product backlog items every sprint. It’s easier to trust teams that delivery regularly.

Last, but not least, formal documentation of the Definition of Done makes the gap in what we can achieve and what we want apparent.  It’s this transparency that allows the Development Team to deliver a consistent level of quality while exposing opportunities to do better.

Ok, that all makes sense, but what about the software?  If you don’t have option the option of shipping every two weeks, what’s the point?  Who performs the work needed to complete the product backlog items? And when are you finally able to ship?

That’s the rub.  Scrum teams, and their supporting organizations, often struggle to answer these questions.  It causes stress, confusion, and ultimately distracts the team from their focus on the sprint goal.  So how do teams and organizations deal with this problem?

There are a few ways that are common, and some of these are to be avoided.  From my experience, here’s the list:

1. The Hardening Sprint
2. The Sprint Backlog of Things
3. The End to End Flow
4. Comprehensive Definition of Done

We will explore each of these, in order from worst to best, to understand them and why they should or should not be used.

The Cliff

Product backlog items are visible both in the product backlog, before being pulled into a sprint, and also in the sprint backlog, while the team is performing the work.  Scrum teams deliver each product backlog item according to their current definition of done. When they meet the definition the product backlog items are marked as “Done” and the group continues any remaining work on the other product backlog items until the sprint ends.

When the current definition of done leaves the product increment short of potentially shippable, more work is required.  So what happens to the product backlog items marked as “Done” after the sprint is over?

The sprint backlog is cleared to make way for new product backlog items each sprint.  There is no guidance for what to do with product backlog items that are not potentially shippable.  Keep the need for visibility in mind as we review options organizations commonly adopt.

The Hardening Sprint

Waterfall used stages to perform particular activities, like testing, operational readiness, and deployment.  It performed these in large batches, often consisting of the entire scope of work. The hardening sprint originated from this concept.  It dedicates an entire sprint to perform remaining activities for product backlog items from previous sprints, a growing batch of incomplete work. This approach suffers from many of the same issues as waterfall, but the impact is less because it’s done in smaller batches, a few sprints instead of an entire project.

The idea is that the people that first worked on the product backlog items are the best to complete the remaining work (i.e. no hand-offs).  The hope is that by dedicating one sprint to these activities, the organization can ship at the end of the sprint and resume new feature development, the following sprint. The organization is willing to sacrifice a sprint every so often, especially if it’s still releasing more frequently than it did in the past (e.g. once per quarter instead of once per year).

Pros

• Psychologically, there is comfort in the familiarity of the approach and thus it’s met with less resistance.
• Allows organization to leverage existing release management and defect triage processes.
• Likely still delivering more frequently than in the past, so the stakeholders are happy.

Cons

• Lost opportunity to maximize value each hardening sprint (i.e. opportunity cost).
• Visibility into progress of incomplete product backlog items is ad-hoc and poor.
• High risk to quality, cost, and schedule due to delayed feedback on product. The longer the delay, the higher the risk. Will one sprint be enough to complete the remaining work?
• Increased likelihood of team working longer hours to keep up with discovered problems.  Team effectiveness and morale take a hit.
• Left with a poor set of options as problems are discovered: delay release, work longer hours, release with poor quality, etc.
• By misusing scrum, it lessen the teams effectiveness to deliver value, learn, and improve.

Recommendation

Avoid hardening sprints, particularly when the product is actively being developed and part of the long term strategy.  When scrum teams consider work “done” during their sprint, the product backlog items are marked as complete and visibility is lost.  Consequently, tracking the remaining work on those items is difficult and ad-hoc, making it hard to coordinate and complete the work.

The Sprint Backlog of Things

I see this pattern all of the time with organizations that are new to scrum.  The teams decide to add new sprint backlog items to perform the work remaining on product backlog items from a prior sprint.  They are effectively using the sprint backlog to “catch up” on work they couldn’t complete. The difference between this and the hardening sprint is that the team continues new product development by accepting additional product backlog items while closing out work on old ones.  Again we assume the same team is performing the work because they have the knowledge and are responsible for completing the work they started. The result is a sprint backlog that mixes valuable product backlog items, those that are really part of the product, with those that reflect remaining work, or tasks, from previous sprints.

There was no name for this pattern so I made up my own. The sprint backlog of things is fashioned after the pop culture concept, the “internet of things”, because it’s a hodgepodge of work.  It improperly mixes the capabilities of the product with tasks performed to deliver the product.

Pros

• Team continues to use some of their capacity to deliver new product backlog items.
• Allows team to catch up to work they could not complete the previous sprint, without hurting morale or damaging the team’s reputation.  Psychologically, the team feels “safe” to responsibly deliver the remaining work.

Cons

• There is delayed feedback about the quality and effectiveness of the product.  The delay may be less than experienced during a hardening sprint, but still adds additional cost and risk.
• Visibility into progress of incomplete product backlog items is ad-hoc and poor.
• Reduced capacity to deliver new product features (i.e. opportunity cost).
• This is a slippery slope, because the team now starts to think of the product backlog as a set of tasks instead of features that maximize value to customers and stakeholders.  
• Scrum artifacts are being misused and will lessen the overall effectiveness of the framework.

Recommendation

Don’t use this approach.  Visibility into the remaining work and progress is poor because the product backlog items from previous sprints are no longer tracked after they are considered “done”.  Keep the product backlog purely focused on maximizing value added to the product. Don’t taint it with tasks disguised as backlog items. The mindset of the team must be customer first, always considering their needs above those of the team.  This is why teams exist, to serve others. When teams care more about how they are perceived or how they prefer to work than the needs of their customers, bad things happen.

The End to End Flow

Full disclosure, this is my go to move with clients that have a gap between their achievable definition of done and what’s needed to be considered potentially shippable.  Here’s how it works. The entire process to build software, from start to finish is modeled using a kanban board. The board contains all of the product backlog items, regardless of progress made against them.  Each product backlog item moves from left to right along the board until it’s finally deployed to production.

Steps in the process that correspond to the work performed during a sprint are modeled on this board.  While redundant with the sprint backlog, the movement of these product backlog items can be seen from both visualizations.  Many tools will support the accurate representation of the state of the work without having the administrative overhead of moving the backlog items in both locations.

One of the key advantages to using this technique is maintaining visibility of the product backlog items after they leave the sprint.

Work can now be clearly managed, including the timing, without having to occupy the sprint or product backlog.  The visualization provides information about the volume of work and the time it takes to get to production. This information can be used to make decisions about when to start the remaining work and how to optimize it.

Pros

• Easy to identify the progress of the product backlog items, including remaining work.
• Many tools allow you to document the explicit process policies of each step on a kanban board.  These are analogous to having a “definition of done” documented along with the backlog items so you can see current policies.  It helps folks remember what work needs to be completed before the backlog items can progress and identifies opportunities to perform some work earlier in the process.
• Encourage the remaining work to be started at the earliest responsible moment.
• Quickly notice if there are bottlenecks starting or finishing downstream work. These can then be addressed to optimize the delivery flow of backlog items to production.
• Similarly, the extent of the work and delays required to ship can be quantified. This allows both the magnitude, in terms of number of backlog items affected and time on task or time waiting to be measured to assess fitness of the overall system.  Because of these measurements, it’s easier to notice when and where improvement is needed and justify the actions necessary to achieve it.
• Because the work exists outside of the sprint backlog, anyone from the team or outside is available to help complete the work, seamlessly as it leaves the sprint backlog.
• Product backlog and sprint backlog remain focused on additions or changes to the product, ultimately benefiting the customers and stakeholders.  Team focus remains there.

Cons

• People may become so comfortable with this approach that they never expand their definition of done to produce a potentially shippable product increment in the sprint (i.e. complacency).
• Team may still reserve capacity during their sprint to assist with product backlog items as they move downstream to production.
• Feedback on the product may still be delayed resulting in higher cost.

Recommendation

Always do this when you have a gap in your definition of done that you don’t expect to be closed right away.  Focus remains on the delivery of valuable product backlog items and not on the tasks. Additionally, because we can see the product backlog items after they leave the sprint backlog there’s an emphasis on when to responsibly deliver those and what it takes to make that happen.  Bottlenecks are clear and measurable and able to be addressed through organizational improvements. In other words, the transparency supports an empirical process where you can inspect and adapt your way toward improvement.

“So, you’re basically suggesting the use of kanban?”.  Yes, that’s true. I like to use the best tool for the job and not be dogmatic about only using the product backlog and sprint backlog.

“In that case, why not just switch to kanban and abandon scrum?”  Certainly, this is an option, but not one that is palatable to most organizations.  They simply don’t trust their teams to deliver quickly once the timebox is removed. On a more positive note, scrum is founded on empiricism and adopting this approach provides more data that can be used by a scrum team to improve their own process.  In other words, scrum can be used more effectively because of the added transparency.

Comprehensive Definition of Done

“Doctor, it hurts when I do this” says the patient.  The doctor replies “Well, then don’t do that”. Creating a comprehensive definition of done is the equivalent of the doctor’s reply.  It involves expanding the scrum team’s capability to meet a comprehensive definition of done. It is the ultimate condition for a scrum team to maximize value for customers and stakeholders.  Every sprint the team will produce a potentially shippable product increment, providing the organization with regular options to ship. With this option in place, there’s little or no need for any of the previous options.

It sounds easy.  Just make sure the Development Team has all of the skills and tools necessary to perform the tasks that previously couldn’t be performed by them, during a sprint.  No problem. If it were really that easy, teams would be able to start with a comprehensive definition of done that they can achieve.

When we consider the end to end flow we can clearly see the work remaining after backlog items leave the sprint.  Those steps and activities are shown to the right of the corresponding sprint steps. Because it takes time for a scrum team to support a more comprehensive definition of done, I like to introduce the term “shift-left” as a way to get them thinking about what downstream activities can be moved earlier.  These are the targeted improvements.

Shifting left requires overcoming the challenges that impede them from producing a potentially shippable product increment.  They tend to be challenges like:

1. Team lacks the skills to perform the work.  The downstream activities require specialized skills not present on the team, and thus not instantly available.
2. Manual work is being done by the team to perform tasks that could be automated.  This often includes testing and deployment.
3. Team lack the proper tools, data, and environment.

Recommendation

Work towards achieving a comprehensive definition of done.  Teams can use metrics from the end to end board and experiments from their retrospectives to pursue this.  Management can provide proper support by funding tools and environments and encouraging the team to learn how to get better.  

Getting there must be done incrementally by the team, and not “big bang” by another team.  There are a few reasons for this:

1. Because the team currently has an achievable definition of done, it is able to hit its commitments.  Remember this keeps morale high, the team confident, and high trust in the team by those outside it. These conditions allow the same group to make the necessary improvement.
2. Teams that make their own improvement, build the same confidence and morale that they experience by delivering software every sprint.  This makes them more likely to tackle future problems without hesitation or expecting someone else to do it for them. This is hugely beneficial to the organization.
3. When large initiatives are created to solve organizational problems, teams usually go a long time without receiving any benefit.  The teams that perform this work are also decoupled from the problems of the team, so they are less motivated to prove their solutions with actual work from the scrum team.  It has the same problems that exist with delaying a shippable product – cost, schedule, and risk. Instead enlist members of the teams to be part of the initiative or work closely with the teams to deliver them bits of functionality that can benefit them early and often.

As the work shifts left into the scrum team, there will be a combination of process and practice improvements made.  The team may also expand its membership, without exceeding the 9 members of the Development Team, to add specialized skills to the team.  In that case, the team would also look to share that knowledge to avoid dependency on a single person.

At some point, it may no longer be feasible to shift left and the definition of done may be as comprehensive as it can be.  In this case, you’ve likely reached the goal of having a potentially shippable product increment, being just a few hours or days away from being able to ship.  This provides the necessary options for the organization to successful run its operations.

Summary

Recognize that most teams will not immediately be able to create a potentially shippable product increment each sprint.  Despite that acknowledgement, work with the team to allow them to deliver the best quality they can each sprint. Avoid the cliff, retaining visibility of the work after it leaves the sprint backlog.  Resist the temptation of hardening sprints or the sprint backlog of things. Keep the product and sprint backlog clean, focused on maximizing value. Identify opportunities to shift left and work towards that incrementally so the improvements are regularly made over time (i.e. early returns on investment).  Ensure the team takes ownership of these improvements and reward them for doing so. This will help you optimize your process and enable your people to reach their potential. As an added benefit, it fully leverages the scrum framework and starts to create an agile culture, resilient to dealing with future challenges.