[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.