According to the scrum guide, Sprint Reviews are held at the end of each Sprint with the objective to inspect the software increment and adapt the product backlog if needed. The session is for the Product Owner to explain what product backlog items have been ‘done’ and for the development team to demonstrate the work that it has ‘done’. And in theory, each Sprint delivers a potentially releasable product Increment. So, how do we know when something is ‘done’? How do we assure overall quality? In addition, releasing software to production requires usually rigorous user acceptance testing and approval from various departments and stakeholders.

The Scrum guide provides no answer on when and how to accept a user story. This means that it’s up to the Product Owner and Development team to customise this to their preference, taking organisational constraints or governance processes into consideration. Usually, User Stories could be accepted:

  1. As soon as possible – during a Sprint
    It is completely fine for the Product Owner to accept stories during a Sprint. By doing so, both the Product Owner and Developer validate the product as soon as possible, allowing time for any improvements or defect fixing. If a user story is rejected by the Product Owner then a discussion should clarify whether or not an updated User Story can be completed in the current Sprint or that it should go back to the Product Backlog for a future sprint. Having many individual acceptance or test sessions may not be an efficient use of development time. However, many acceptance discussions between Product Owner and developer might be disruptive to the development process.
  2. At the end of a Sprint – during Sprint review
    User Stories may also be accepted at the end of a Sprint during the Sprint Review meeting. When the development team is demonstrating their User Stories completed, the Product Owner could accept the User Story there and then, or may provide feedback which then results in an amended or new User Story. As this is the end of the Sprint, any User Stories not completed go back into the Product Backlog. During the next Sprint Planning the Product Owner and Development team collaboratively agree on the next Sprints Definition of Done. Note that any story that is rejected by the Product Owner should be discussed at the Sprint Retrospective to determine why the User Story was rejected and what can be done in the future to ensure User Story development meet the Product Owners expectations.

In more complex project it may be more difficult to fully accept functionality. For example, testing integration with legacy systems may be limited by test systems and data availability. In addition, with new cloud based technology the development team may produce such an amount of functionality that the Product Owner cannot keep up. Traditionally, functional and acceptance testing were also used to get business buy in and act as knowledge build up.

  1. Additional testing – outside Sprints
    These key benefits may be achieved by adding a parallel test stream next to the Sprint development cycle. This means that after unit testing (by developer or development QA team) and Product Owner review, a Quality Assurance team could then perform additional testing such as Functional Testing, System Integration Testing, Performance Testing, Security & Penetration Testing, Usability Testing, User Acceptance Testing or Production Readiness Testing.Testing

While testing outside Sprints may not be in line with Scrum, it is in line with agile principles of releasing early and often by testing as early as you can. In addition, testing outside a sprint by another team does provide additional quality assurance and may meet internal governance guidelines. The reason for pulling Functional Testing forward, right after the first Sprint, is to enable the organisation to get organised, start getting into the habit of writing test scripts and get other logistics in place. This then reduces time for the User Acceptance Test as well as de-risks any Go Live delays.