The Sprint Review has already been the subject of a few posts on this blog, as in What is the Sprint Review meeting? – FAQ Scrum. The reason for that is, although sometimes this meeting is not given the ideal attention, it is in fact one of the most important points of inspection and adaptation of the Scrum cicle, especially concerning the product itself.
One of the reasons of this undervaluation is because, in some cases, people think that the Sprint Review exists so we can test the product generated during the Sprint and, indeed, this can be done by the product testers, without the need of a meeting with stakeholders, PO and development team together. However, the mistake here is to assume that the Sprint Review meeting is only to test what's being delivered. And it is to desmistify this belief that we're going to see why this meeting is so important.
#1: It is time to check what was done and see if it suits and pleases you!
The main goal of the Sprint Review is to show the stakeholders and the PO what has been done during the Sprint development, not to initially test the release. When a product backlog item is put in the Sprint Backlog, there is a expectation that, by the end of the Sprint, that problem will be solved and accordingly to the wanted quality levels. It is why during a Sprint Review the PO has the power to approve and disapprove the itens of the Sprint Backlog. He needs to evaluate if the expectated value has been achieved and delivered. If yes, he approves the item. If not, disapproves.
#2: Ok. We are pleased with the Sprint results. But is this the path we want the product to follow?
The Sprint Review meeting also is the moment where you reunite PO, development team and stakeholders so that everyone can see what the product is like now and discuss whether it is on the right path. The planning of the next Sprint will be done at another moment, but it is during the Sprint Review meetings that new suggestions to the Product Backlog come up and it is good that they do. It just shows that everybody is involved with the project, looking for the product's success and talking about the best direction for it.
#3: Nah… not pleased, no. We have to change some things around here.
Well, not everything is just happiness. Sometimes some itens of the Sprint Backlog are going to disapproved, but it is not because they are unfinished or have bugs, for example. They are going to be disapproved just because the PO didn't accept them. And it is important that this is done in person, during the meeting, so that the development team can really understand why that item wasn't approved and what needs to change so that it won't happen again.
#4: Fine… it is also the first opportunity to test the product.
Ok, it is possible to run initial testes during the Sprint Review meeting, but it is important to know that it is not the goal of the meeting and that, in fact, the tests there are going to an evaluation of the requirements. Testing how it is functioning is going to be really superficial.
If we take a look at Agile Testing book, we'll see that this evaluation fits the quadrant number 3 of Agile Testing Quadrants, as we can see below.
These quadrants are there to represent the different ways of testing a feature in an agile way. In the case of Review meetings' tests, our goal is to criticise the product from the business point of view. Thus, our tests during the Review meetings will criticise different scenarios, usability, user acceptance, validating the product and the business and not how the requirement is functioning.
#5: And also a time for learning…
Another advantage of the Sprint Review meeting is that it is an opportunity to show how to use the new feature and to explain, step by step, the actions necessary to execute it. This avoids noise in the communication and false bug alarms, and also it is the first evaluation of the usability of the feature. If there's no doubt in how to use it, probably the usability is ok and it will be easy to understand how to use it. If any doubts come up, it's worth considering an adaptation of the feature.
#6: For the end of surprises, disappointments and frustations!
Last but not least, the Sprint Review meeting prevents that stakeholders end up having unpleasant surprises with the direction that the product ended up going. If the project is being reviewed all along, by the end of it the product generated will be just like it was wanted to, delivering the expected value and we'll prevent that cases where after years of development the product is just set aside, because it not attends the necessities to what it was created.
What about the project you participate in? How do your team see the Sprint Review? Share with us your thoughts and experiences!
References:
