We are now up to myth nine, and this time we are going to rapidly dispel a common Sprint Review myth that we see next page. This is the belief that the Sprint Review is the event to engage with the Product Owner to discuss, demonstrate and validate the output of the current Sprint. This myth harkens back to ‘ye olde days’ when Scrum first burst onto the scene back in the early 1990s. If you check out the original famed Sutherland and Beedle ‘black book’ you’ll see it clearly and categorically stated that a Sprint should be 30 days (no more, no less) and at the very end of those 30 days, a Sprint Review would be held to engage with the team’s Product Owner (PO).
Back then this was revolutionary: “What! You mean I get to see something after 30 days instead of waiting 12 months!?” was the common exclamation made by highly-excited POs. Of course since those early years, Scrum has incrementally evolved and nowadays I don’t know any teams that still run with long-winded 30-day Sprints. One-week or two-week Sprints are now the norm. Further, even waiting until the end of one of these shorter Sprints to validate with a PO isn’t ‘Agile’ enough anymore due to the super fast-paced, rapidly fluctuating environments that we now find ourselves in.
We expect Product Owners to be closing feedback loops frequently and on a day-to-day basis rather than on a Sprint-to-Sprint basis. So, these days, the primary aim of the Sprint Review is to engage with the broader stakeholder community, who, unlike the Product Owner isn’t involved on a daily basis with the Scrum team. Further, there should be no surprises for the PO in the Review as he or she should have seen any complete Product Backlog Items as soon as they were completed via a practice commonly known as a ‘Walkthrough’.
Now, while a Walkthrough is not yet regarded as a core Sprint activity, it has certainly become a generally accepted Scrum practice or GASP as Mike Cohn would put it. Think about Walkthroughs as mini-progressive Reviews that occur within Sprints, whenever a Product Backlog Item is deemed to be ‘Done’, ensuring that feedback loops are closed as soon as possible.
However, there is certainly a risk with this heightened visibility and validation, and that is the situation that occurs when the Product Owner, after enjoying a “taste test” during a nice early Walkthrough, decides that he or she wants to adjust the “flavour” of the requirement so to speak, (and I’m not just talking about a pinch of salt either!). This will naturally occur and should be expected. As such, it is important (especially in the early days of a Scrum team’s initial implementation) to include the ScrumMaster during the Walkthrough to adjudicate in case the intent of the planned, protected Sprint, is subverted, but still allow provision for minor tweaks to be absorbed by the developers. Bottom line is that although minor adjustments to the intended scope should be accepted and expected, significantly changing the requirements of a requirement due to its early visibility should be avoided unless absolutely necessary so that focus is maintained and disruptions avoided.
So we will leave it at that for 2015 and wrap up this epic journey in 2016. Thanks for following along and please have a very safe and relaxing break everyone 🙂
If you liked this article, you can:
Subscribe to this RSS feed!