Ending a Scrum Project

Any project starts when stakeholders agree to allocate resources to achieve something that has been evaluated to have a satisfactory return on investment. This means the project must be well defined from the beginning, otherwise the stakeholders will not support it.

Is the case also for the Scrum projects: there is a need for a roadmap linked to a release schedule. The more complex the project, the more planning is required before it starts. Releases with set dates and minimum functionality required in each release, should be defined before the project begins. Because of its iterative nature, Scrum projects must be planned flexible enough to allow discovery and adaptation to changing requirements. There should be space in the release roadmap to add or remove functionality as priorities change.

In these cases, the Scrum project, ends when the milestones are met, the roadmap release schedule finishes, the project runs out of money, or a specified deadline arrives, and the product increment has an acceptable defect level. Wi the exception of the last case, all the others are common to other projects also, not only Scrum.

However, the Scrum project could be terminated at any point by the stakeholders, or the product owner. The product owner owns the product backlog, and knows the value each item will add to the final product. Through prioritizing the product backlog, the product owner determines what features will be delivered in each sprint. Though customers can request a feature be added to the product backlog, it does not mean it has sufficient value or high enough priority to make it into a sprint.

The product owner should continually evaluate the return on investment of the items, remaining in the product backlog. Product owners, stakeholders, or customers can negotiate to end the Scrum project if they feel added value of the remaining product backlog items is too low to continue. At the end of any sprint, the product increment will contain the highest value features, and be potentially shippable software complete with documentation. Since each sprint always works on the highest priority task in the product backlog, if a decision to release is made at the end of the sprint, the stakeholders know the most important features are already part of that product increment, which will be deployed as a product. Since the product increment is potentially shippable software, the release process has less complexity than in other methodologies, where the software is not fully integrated, tested, or documented till the end of the project.

However, there are still items that must be performed, to get a product increment ready to be released as a working product. These are completed in a release iteration or release sprint, which is used to prepare the product increment for deployment.

Activities that occur in the release sprint include:

  • ·      Finalizing the documentation, that is in a state of constant changing during the sprints (architecture documents, user manuals, etc.);

·      If multiple Scrum teams are

working on different modules of the same project, system integration and

testing must be completed.

  • ·      Final defects are resolved and a final acceptance review is held with the stakeholders.
  • ·      Physical shippable items like the installation media, manuals, and packaging need to be finalized and produced.
  • ·      If the release is an upgrade, the field may need to upgrade hardware or software applications, or migrate to a new database schema. And end users and support workers need to be trained on the products, new functionality.

There may be several release iterations depending on the complexity of the project, its impact, etc. (a lot of user training may be required, special rollouts have to be handled for some of the users, etc.). Once the final release is shipped and the Scrum project is over, it is often better to move new work to the established team, rather than moving team members to new work. Teams that are already self-organizing and have developed team unity, are one of the major productivity benefits of Scrum. These teams should be kept together to work on the next project whenever feasible.