Nail Your Sprint Review
The Sprint Review. In theory, this is the time when battle-tested developers stride with confidence into the conference room to show the Product Owner all of the incredible work they’ve done in the last two or three weeks, hungrily awaiting the accumulation of story points that are sure to pile off the edge of the Scrum board. They will return, doubtless, like a horde of Vikings hauling their plunder back across the black seas of industrial carpeting to their open-concept offices. Victory is nigh at hand!
Unfortunately, this is rarely the case, to the point where such an expectation borders on delusional. In reality, most of us pile into that conference room completely unsure of ourselves, and hoping beyond hope everything goes well enough to get out before lunch. The good news is that there are steps you and your team can take from the very beginning to help ensure the Scrum Review meeting will at least grant you a modicum of smooth sailing. Based on years of involvement in Sprint Reviews, here are 5 Tips that have made our lives easier.
- Acceptance Criteria
- Playbacks with the Product Owner
- Be Prepared!
- Everyone Loves a Story
- Keep it Positive
Poor Acceptance Criteria Yield Poor Results
A good end begins with a good start, and this is where the Acceptance Criteria, the requirements against which the completion of the user story is judged, can be your greatest asset or your worst enemy. While we think of the User Story description as the requirement in most cases, it’s actually the acceptance criteria that truly define what is to be delivered: the user story itself should serve as commentary on the context, nature, and scope of those criteria. Given that perspective, this is where you should spend most of your time and scrutiny!
While often relegated to the role of the business analyst, it is imperative that technical team members also review the acceptance criteria. Remember the INVEST acronym, to ensure that the user story and its acceptance criteria are implementable and ultimately approvable by the team. It is also generally good practice to write acceptance criteria in the positive voice: what the system should do, rather than what it should not. Make them concise, accurate, and testable, and you’re well on your way to success.
Small, focused User Stories with well-defined Acceptance Criteria are imperative for a successful Sprint – and Project.
Playbacks: The Review Ahead the Review
The Sprint Review should not be the first time the Product Owner is seeing the implemented user story. You’re literally asking for trouble by creating an implicit wall between development and the business. Welcome to the shortest waterfall project ever, where the product owner gets something completely different than they expected and no one is happy. Because Scrum works in short cycles, you only took two weeks to get it completely wrong… but it’s still wrong.
Incorporating playbacks in the development cycle will help get more immediate feedback, and correct any issues, before Judgment Day – I mean, “Sprint Review.” That way, the product owner is already aware of the implemented functionality when they walk into the review, making acceptance a near fait accompli. Getting informal pre-approval pre-disposes the Product Owner to acceptance and greatly speeds up the overall process.
The Sprint Review should never be the first time the Product Owner sees the implemented User Story.
Set up for Success
Preparation is perhaps the biggest non-secret I have to impart with regard to Sprint Reviews. Each review is a mini-demo where you are selling your work! It has to meet their specifications, but you also need to make sure that your demo goes well by ensuring the correct data is set up to smoothly transition from one acceptance criteria to the next, and one user story to the next.
Sit down and make a list of all the User Stories you expect to be showing, then order them in a sequence that will make sense to the end user and not seem to “jump around”. This dramatically reduces the time spent in the review session, most of which is effectively “dead air” while you fumble over what story to show next, and it gives the Product Owner a better sense of the application as a whole as it comes together. This helps you with the next part (Tell a Story), and keeps the review focused on one component of the application at a time – usually within the context of an Epic. Finally, and just as importantly, ensure that all the data you need is ready to execute the acceptance criteria, and know exactly the context under which they will be executed.
Know where to go, what to do, and what pre-conditions must exist.
Tell a Story
With reference to the idea that you are effectively doing a demo for the product owner, do not just trudge through the user stories one after the other in some robotic fashion. (Unless, of course, you’re using robotics!) Your aim should be to tell a story about the actor in the context in question, the person that will be using the application functionality. Make it personal, so that the Product Owner can visualize the impact of these changes on their daily life, and the lives of those around them.
Bad: “Ok, so I click the Apply button and the application screen comes up – that’s AC 1. Are we good with that? [Pause] Ok, I fill in some information, and submit, and… [Pause] it goes to the next screen. So, that’s AC 2. [Pause] [Mild Panic] Oh, wait… I have to show you the error message for the applicant being over 21… let me do that again. Hang on…”
Good: “The applicant grabs a cup of coffee and sits down at their home computer. They log in and are presented with the option to apply, which they select. They are then presented with a screen that allows them to enter information about themselves so that they can complete the application process. Notice that we present an error message if their birth date is less than 21 years from today, per the acceptance criteria. Once complete, the user can proceed to the next step of the application process…”
The difference here is how you’re setting the scene and reflecting on the impact of these changes, and engaging the personal experience of the Product Owner to make the connection between the work you are doing and the work they are doing. That connection is crucial.
Always tell a story from the point of view of the actor in question. Make it personal.
Even the best planned Sprint Reviews can take a turn for the worse, even if you’ve done everything I suggest. No matter what happens, keep your voice and body language positive. I can remember vividly a review where, for a number of reasons not in the team’s control, we didn’t do as well as we had hoped. The Scrum Master’s tone of voice, over the phone no less, was down and apologetic the whole time. We could have crushed that Sprint and still come away feeling like it was perhaps “just ok.” Worse yet was at the end when this person sighed, loudly, and noted, “Well, I guess that’s all we have then.” Ouch! Thus person just threw the entire team under the proverbial bus and was not even aware of it.
Don’t do that. Seriously – don’t. It’s not fair to the team that did the work to under-sell its importance and difficulties through which they may have struggled. Always stay positive, even when making reference to underperforming on the number of expected points. The Scrum Master should have already communicated these issues anyway. A positive approach will subconsciously assure everyone that everything is going well, and if it’s not that there is a way forward – and there should be. Negativity breeds negativity and that’s how a project can go off the rails by perception alone.
Of course, if things are truly not going well, these issues should be discussed and resolved in the Sprint Retrospective!
A positive voice and body language will make for a better Sprint Review.
You and your team work hard to implement User Stories, so don’t sell that work short by a lack of preparation for the Sprint Review. Create a consistent message across the set of User Stories, arranged logically and with the proper data set up to be successful, and you will be surprised at how much better your Sprint Reviews become – and subsequently your entire project. A poor Sprint Review is like being a waiter who gives exceptional service throughout, but leaves the customer waiting too long to pay the check.
It’s the last bit of effort that people remember most.
Colin Campbell is Chief Executive Officer and Principal Consultant at Stratosphere Consulting. His focus is on building enterprise-level Centers of Excellence on the Pega platform. If you are interested in learning more about what Stratosphere can do for you, share your email and we will get back to you in one day.