Conduct Sprint Review

(Activity) for Tier: Sprint

PURPOSE

A product review provides a transparent look at the current state of the product at the end of the sprint. This gives an opportunity for the Product Owner, any internal and/or external stakeholders to see the implementation of their product vision and provide course corrections to keep the product development moving in the right direction. Also, allowing everyone with input to the product development effort an opportunity to inspect and adapt what has been built so far. Feedback from this meeting will lead to new or updated Features, User Stories, and Bugs which improve the product and customer/user satisfaction.

WHEN

At the end of a Sprint.

ENTRY CRITERIA

A planned sprint execution has ended.

SUB-ACTIVITIES

  1. Invite Stakeholders

    • Ensure all Team members are invited and can attend the review.
    • Refer to the Stakeholder Involvement section of the Project Plan to ensure the appropriate Sprint Review Participants are invited.
    • Review the sprint goal and invite any additional stakeholders that can provide feedback relevant to the sprint goal or on the working product.
    • Coordinate with stakeholders to determine an acceptable meeting time and send the invite.
  2. Prepare for review

    • Confirm What Sprint work the team asserts is Done (i.e. user story, and/or parent feature).
    • Determine Who and How Sprint work should be demonstrated to ensure team members understand which items they are responsible to speak on and are prepared to demonstrate. It’s acceptable to assign one team member for the whole review or distribute the responsibility to multiple team members.
  3. Conduct the Review

    • Record attendance per the team’s procedure.

    • Review the state of the working product and how the sprint helps achieve stakeholder objectives.

    • Demonstrate the working product.

      • Communicate known issue(s) as they relate to the area being demonstrated.
      • The Product Owner listens to the feedback and decides for each user story, and/or parent feature if the acceptance criteria has been met or needs to be returned to the backlog.
    • For each user story and/or parent feature that the team didn’t assert as done during the sprint, review the Development Teams efforts and the issues they faced.

    • Document any feedback from the review per team’s procedures.

  4. Analyze Feedback

    • Following the sprint review:

      • Analyze the feedback received and update the backlog accordingly. Document any specific analysis performed within the discussion field of the appropriate user story, and/or parent feature.

        • Re-activate user stories not considered “Done”.
        • Create or activate bugs where defects to user stories or the working product are discovered.
        • Create user stories where enhancements are identified.
  5. Update Sprint Review Regular Participants

    • Review the attendee list and feedback received from attendees to update the regular Sprint Review Participants if it would benefit future Sprint Reviews.

OUTPUTS

EXIT CRITERIA

SEE ALSO

Process Guidance Version: 10.4