I have noticed that many teams do not always have a sprint review. This is very alarming to me. When I ask why not, I get all sorts of answers. The one I find most disturbing is, “We had nothing to show.” But how is that possible? The goal of each sprint is to produce an increment of potentially shippable code. At this point, the excuses start to fly hot and heavy: “We are just starting and must build the backend. All we have are ER diagrams. We had an issue that made it impossible to ship. We really don’t have much to show yet.”
These are all smells that let me know something is wrong. Many of these will correct themselves if you simply never skip a sprint review. I tell my teams that, at the end of this sprint, we are having a sprint review. You have two options, show what you completed or explain to the Product Owner and Stakeholders why you have nothing to show. Choice is yours. Once teams know they must produce something they can show, things change. The way you build your software changes. Gone are the days where you spend months dreaming up every possible table, stored procedure, index, trigger, and function your database will every need. Not to mention this is a complete waste of time.
Stop thinking of your software as a cake and start thinking of it as cupcakes. Cupcakes you can eat a batch at a time. You do not have to wait for the entire cake to be done before you eat it. Historically, I get the biggest resistance from the database people. They claim they must model the entire database before we do anything else. Once, I said, “Fine. I will let you take the two months you estimate it will take to model everything first. I only ask one thing. You never change it. It must be perfect. We will not accept any attempt to change the database in any way.” They, of course, said that was unrealistic. So, I replied, “ If we are going to have to change it, why are we wasting this time?”
I always use the standard web application when I am trying to illustrate this point. Imagine we are tasked to build a web application. This will be a site that requires users to log in. If you must show a working piece of software at the end of the sprint, you cannot just create database tables. Nor do you have to create every table of the entire site to show progress. How about you just give me a login page that lands on an empty user profile page. If that is our goal for sprint one, how many tables do I need? One. All we need is a single table with a username and password. In future sprints, we can add additional information to this table as features dictate. The database should be treated like the rest of the application and be refactored as needed.
Remember, the goal is to produce an increment of potentially shippable code. It does not mean you ship at the end of every sprint. However, as soon as the Product Owner sees value, we should be able to ship. This will be long before you reach the bottom of the product backlog, which will be much sooner than in the waterfall world where you would wait until the entire project was complete.
There is another benefit to just creating the login page in this example. To get the login page to work, we would have to get the username and password from the UI, through the middle-tier, into the database, and back again. A working login page is testing the integration of every layer of your application. I am sure we have all been on a project where we built layer by layer just to get to the last layer and realize other layers now must be re-worked because of a bad assumption. Now after sprint 1 you have a proven integration upon which to continue to add value.
Cancelling a sprint review should only happen if you cancel the entire sprint. People will stop accepting invites to meetings that routinely get cancelled. Remember that failure is no excuse to skip a sprint review. I remember one sprint where we accomplished several items we committed to but one slipped. During the review, when one of the stakeholders asked about the missing feature, we shared the reason it was not complete. We were having trouble getting the information we needed from a third-party vendor. One of our stakeholders happened to have a lot of influence over that vendor. After the meeting, they made a call and we started getting the information we needed. Being transparent during that meeting got us the help we needed to clear an impediment that was blocking us. Had we skipped the meeting, we may have struggled for some time trying to get the information we needed.