In agile software development, it’s widely believed that every Scrum sprint should result in software that is ready to ship. The theory is that the team will be able to stop or suspend development at the end of any sprint and ship the software to the end users. This means that the team is always delivering increasing value to the business.
Sounds good. Difficult to achieve.
Calling a set of stories “done” and ready to ship doesn’t always mean the business community can use the software effectively. Let’s take a simple example.
You’re building a financial application to manage customers that are late with their payments. You’ve completed a set of stories that provide the following functionality for customer agents:
- Search for a customer who is late.
- Display basic information about the customer.
- Review the customer’s payment history.
Obviously, those are essential features. However, before the user community can integrate the software into their business process, they will minimally need a few more features such as:
- Ability for a customer agent to log a contact attempt against the customer’s account.
- Ability to view recent history of contact attempts to avoid duplication of effort.
- Ability to mark a customer’s account as paid in full.
- Ability to block a customer from making any future purchases.
The absence of these features is fine during alpha and beta testing, even during initial pilot runs. But calling the software ready to ship is a stretch.
You could argue that the existing business process and the new software could co-exist for a period of time. While that may be true in principle, in practice, it places an added burden on the agents and added costs on the organization.
Sprints improve software. Releases deliver it.
Rather than think of each sprint as delivering software that is ready to ship, think in terms of a set of sprints comprising a release. Strive to make releases ready to ship.
In addition to easing the pressure of having to be ready to ship at the end of every sprint, the team has the added advantage of doing some additional release planning periodically — not just sprint planning. They can schedule an architecture and design sprint at the beginning of a release. Similarly, they can schedule an integration test sprint at the end of the release cycle.
Clearly, I don’t agree with the premise that each sprint results in a shippable product. But I do agree that the stories within a sprint should be fully baked and ready to be delivered. This is a subtle but significant distinction.
The needs of the technology team don’t always align with the needs of the business team. Find ways to make them align and everyone will be happier and less stressed — you’ll also be more agile.