TL;DR
Scrum requires that the event be held at the end of each iteration, even at the beginning of a project. While you might consider shortening it, or shifting the focus slightly towards process rather than deliverables, the event should still be held.
Events Build Cadence
Formally, the Sprint Review is a required event in Scrum. While it's certainly reasonable to keep it short if you have little to demonstrate, it's important to set the tone for reliable cadence early on. This cadence creates:
- Predictability. Stakeholders can rely on having an inspection point available every iteration.
- Transparency. Stakeholders can be confident that they will have clear visibility into the project at every inspection point, not just when there's good news to share.
So even if you have nothing to show for your efforts (and you do, so keep reading) it's worth holding the event.
Additional Value
Even when you don't have something to demonstrate, a short Sprint Review is useful to invite collaboration with stakeholders. The Scrum Guide provides some clear examples of what a Sprint Review should contain aside from demonstrating deliverables:
- The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);
- The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
- Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
- Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.
So, in addition to establishing a cadence, and instilling a sense of confidence in the stakeholders through predictability and transparency, the Sprint Review invites structured collaboration with the Scrum Team!
Things You Can Demo
Granted, you may not be able to demo a product increment. But if you think about it, you can still demo value to the project, especially if you've adopted a test-first agile mindset!
For example, setting up a developer environment or a continuous integration server is demonstrable. Do your developers use an IDE? Grab a projector and demo the heck out of the Intellisense features (or whatever) that will presumably add value to the project through developer efficiency. Keep it short, but explain why it matters!
Did you get continuous integration up and running? I'll bet the team members that did it tested it somehow. Even if they're not pumping product increments through it yet, they must have done something to ensure it's working as expected. Make a visual demo out of that, and explain how this team-facing feature will help deliver the product the stakeholders ultimately care about.
Confessions from the Real World
I'll admit to having cancelled a Sprint Review from time to time, especially at the beginning or end of a project. However, I've always seen doing this as a failure of imagination, or the result of an overly specification-driven (rather than test-driven) approach to the project and its product development methodology.
If you truly can't demonstrate anything, and have nothing that the stakeholders might want to collaborate on, then you certainly don't want to waste everyone's time. In such circumstances, limiting the Sprint Review to just the Scrum Team (including the Product Owner) might make sense. Just be sure to set reasonable expectations about when Sprint Reviews will begin in earnest, and make sure to communicate whatever value your Sprint has delivered to the Product Owner and the stakeholders.
At the front end of a project, even when I haven't held a formal Sprint Review, I've usually still held an informal event to discuss the project's scope, methodology, or approach. This has typically been well-received.
Towards the tail end, there's usually more to show product-wise. However, sometimes stakeholders are less interested in the small, incremental changes at that stage of the project. In those cases, I've sometimes substituted shorter stakeholder meetings for the formal Sprint Review. There, we often talk about schedules, shipping dates, or project close-out topics.
I don't claim that it's a best practice, and certainly don't claim that it's Scrum. However, it's certainly an option if strict framework adherence isn't desired, or when process immaturity or stakeholder apathy make starting (or maintaining) the cadence is impractical.
My real-world experience is that shortening the event, or shifting the focus slightly towards process, can be beneficial in some circumstances. Skipping the event entirely has almost always been a project smell for me, though. I don't recommend it, but your mileage may vary.
