[Agile & Scrum] Sprint Review Flashcards
In a review Meeting, we inspect the increment and adapt base on what we discover. We have all the necessary people participating: we have the development team, the scrum master/agile coach, the product owner and most importantly the real end users from *** (Client). (YLE, the biggest broadcasting comany in Finland, who are awesome since they joined us in this agile partnership.
The increment we are going to look at is a new and improved table component YLE wants to use to create and edit work orders. And work orders could be anything like grabbing a live signal from satellite feed and transfering it to a news studio to show a reporter line on scene. or an order could be that a memeory card needs to be talken out of a camera and uplaid to a server. That and everything in between. Alright,a that’s enough context. Lets have a look.
the product owner is very excited to show everything the team managed to complete, which is great but hes forgetting to give room for the most important thing of a reveiw meeting: getting feedback!
There’s also big difference between a demo and a review meeting. With demo, you show sometime and that’s it. Done, everybody goes home. While in a review meeting, the demo is only the begging and serves as a trigger for feedback. Another benifits of a review meeting is providing context to the developers. and this is context you can only get by putting developers and end user in the same room.
Everyday, a developer needs to make hundreds of decisions during development. Getting this context from the end user during a reviwe meeting will help them make informed decisions. Compare that to having to figure our what the context is simply based on..what? requirements? made 6 months ago, written down somewhere? guess what? a lot has changed 6 months ago.
In this next fragment, the development team decides NOT to implement a feature from old table compotent, namely a check mark in front of a row, because they don’t understand its use case.
the art of maximazing the amount of work not done
can you imagine the amount of time and energy that would have been wasted optimizing a checkmark feature that is not even going to be used?
timebox!
An important detail is setting a firm timebox. The timebox helps everyone involved to focus on waht is going to give the best possible outcome and waht prevents the participants from falling down a rabbit hole.
Don’t mistake a review meeting for being a good-news show either. More often than not, the most valuable outcome of a review meeting is transparency that is gained on important things that are still missing.
Transparency
the limit set to the table will break the usability. See the PO hashing it out? He’s thinking. “ Ok, so this is much more important than we anticipated. but what will be the impact on the backlog?” and THAT is absolutely the goal of a review meeting, not the demo itself, but giving PO a lot to think about so they can update the product backlog and maximize value for the next iteration.
What do the key stakeholder think?
So how do you know if the review wasn’t a waste of tiem? If it was useful for everyone? You ask. What do the key stakeholders think? Is it useful for you? Having proactive users, like we were luckly to have here with people from YLE, is essential in creating value. The users are the driver of Value. Without their input, their feedback during regular reviews, we would only be able to deliver a fraction of the possible value.
One last benefit
And then I’d like to end by highlignting one last benift of a review meeting and that’s a happy team. Knowing, seeing, hearing and feeling that what you created means something to someone is simply awesome and motivating.
In a real-world setting
- Scrum Master
- Product Owner
- 2 Developers
- 2 Designer
- DIrector of the client team,
- Center Staff, who’s using the system for *** purpose.
Process
After the scrum master has kicked off the meeting, the product owner then reminds everyboday of the sprint goals, this is before the developers proceed to demo each one of the features. The review, in general, will be performed against the user stories agreed durign the sprint review, which is waht you are seeing on the presentation screen over here on the JIRA software that we use to manage all the user stories.
Demo
the developers will then demo the completed features one-by-one according to each one of the user stories and everyone will have the opportunity to give feedback around the table as developers are demoing the features.
PO:” so if this trait doesn’t have subtrait right, all will be affecting..” and here, we can see the product onwer actually giving feedback about the featuer that is being demoed on the screen right now. and the product owner will most likely be the most active as hes sort of resposnisble for the user stories right from the start from the sprint planning. So in the sprint review as well. he will likely be the person who is going to regulate this process. showing each user sotry and determing whether each one of them can be completed with the views from the team.
And next you can see some actions from the other stakeholders, for example here you see one of the designer users actually given feadback on a feature on the screen, discussing in detail how this feature that is shown on the screen should exactyly work. and this is an example of something that is key to the sprint review. A the discussion would lead to decision whether this user story can be completed or not.
As a key task to be performed is actually this, for every single user story, to be evaluated by the team, and looking at each one of the acceptance critiria on the user stories, and determining whether these user stories can be completed.
So this process is usually regulated by the product owner, so he will make the call after assessing all the feedback from the stakeholders. Is there are any changes, then the product owner will actually note it down and use this information for the next sprint planning in the next sprint cycle. and once theres a decide made for every user story, the scrum master will declare the end of the review, and then we will move to the sprint retrospective.
So once the sprint review is done, normally the developement team would stick aroud, while the users and stakeholdes would leave the room for the sprint retrospective to take place.
