Agile Reporting: In Defense of the Sprint Review Meeting
Once, in a project management role with a tech startup in NYC, I led the dev team into adopting Scrum. We had daily standups as well as sprint retrospective and planning meetings at the close of each sprint. A point of contention, though, was around ‘release notes.’
In standard waterfall development it is common to have release notes go out whenever a new product or an update to the product ships. This makes a great deal of sense given the amount of time that went into making the finishing product, with well-defined requirements from the outset. In Agile, however, the idea is to be…well…agile. When a sprint concludes there typically will not be a finished product, neatly wrapped up with a bow on top. What is delivered is a potentially shippable product increment.
Here’s a very rough outline of how an Agile approach should work, as I see it:
- User stories are written, covering what is believed to be needed for the product. These follow the pattern of “As [user/role] I want [function, request, etc] so that [outcome].”
- User stories are placed in a backlog, groomed by the product owner and prioritized.
- At the sprint planning meeting, the scrum team reviews the backlog, providing story points or some other arbitrary measure of a user story’s effort (not time) and selecting out what items will go into the sprint backlog.
- The scrum team formally commits to do the work required to complete what they have selected for the sprint backlog.
- Development begins, and runs for however long the team has decided sprints should last (a week, two weeks, a month or perhaps more).
- At the conclusion of the sprint, the team presents the work completed in a meeting open to any and all stakeholders. There is no formal powerpoint presentation, but rather a demonstration of the product increment. This is the sprint review.
- After the sprint review, the team gathers for a retrospective and then a fresh sprint planning meeting.
The sprint review meeting is key to Agile success. The heart of Agile is ‘inspect and adapt,’ and it’s in the sprint review meeting that the scrum team can learn whether it is on the right track, per stakeholder evaluation, and also whether they should change course.
Consider two scenarios:
- The scrum team concludes a two-week sprint, gathers stakeholders and demos the product increment. The stakeholders notice some departures from what they had in mind. This could be due to a communication failure in the form of poorly-written or incomplete user stories or because the scrum team misinterpreted. All is not lost! It’s better they hear they are off-track now and make adjustments in the next sprint, than to have gone the waterfall route and possibly only found out they were mistaken when the product was ‘done.’
- The scrum team concludes a two week sprint, gathers stakeholders and demos the product increment. However, now that the stakeholders see it in practice they realize that it’s not quite going to serve their needs or interests. This could mean a few tweaks or an entirely new course based on their fresh evaluation. In response, user stories are written to serve this purpose and the team takes this new direction into sprint planning.
Release notes are all well and good, but of little practical value in a truly Agile organization. The sprint review meeting, however, can make all the difference.