After sitting in a number of different sprint review meetings, with a number of teams, I’ve noticed that not all teams have a formal way of capturing feedback obtained in sprint review. Feedback can be any of the following:
- A defect noticed by anyone in the room during the demonstration of the software developed during the sprint
- Enhancement request ideas by anyone in the room for the product backlog based on what’s being shown during the review
- Feedback from the product owner on something that needs to be changed for the story to be accepted the story isn’t done until this change is made
That feedback should be captured and managed. In theory:
- Defects get tracked and managed: Different teams handle defects requests in different ways. For some, they become backlog items, for others they story isn’t done until they are fixed, and for others they get tracked as part of a release.
- Enhancement requests are captured and managed: Enhancement requests are almost always handled as backlog items. They get reviewed and prioritized along with all the other stories.
- Acceptance feedback is addressed before the sprint “officially” ends. It might be tracked as a new “task” for the story before it’s completed.
In practice, no one tracks any of these. Nothing gets written down, and two hours after sprint review all the feedback is either completely forgotten or is just hearsay.
Don’t let this happen to you.
One way to address this is to have someone in the sprint review meeting enter stories, defects, and tasks as they come up. Have them do this using the same tools you always use note cards, JIRA, whatever… At the end of the sprint review, have that person review everything they captured to ensure they captured it all. Regardless of what processes you use to actually address these issues, you now have the ability to because you’ve captured this information.