This course covers techniques for monitoring your projects in order to align client needs, project plans, and software production. It focuses on metrics and reviews to track and improve project progress and software quality.
5.1.2: Sprint Review Meeting
Loading...
Do curso por University of Alberta
Reviews & Metrics for Software Improvements
871 classificações
University of Alberta
871 classificações
Curso 5 de 6 em Specialization Gestão de Produtos de Software
Na lição
Module 1: Right Product
Welcome to the first module! This module is all about creating the “right product”. You will examine various ways of ensuring that you are creating the right product for both your client and your users. You will learn how to conduct a sprint review meeting and why they are an important step for delivering the right product. Then you will look at user studies. You will learn about several techniques for determining the needs of your users. The module concludes by examining how some of the big companies in the industry ensure that they are delivering the right product to their users.
Conheça os instrutores
Kenny WongAssociate Professor
Computing Science, Faculty of Science
[MUSIC]
This module is all about delivering the right product.
One very important way to determine if this has been achieved
is the sprint review meeting.
A sprint review meeting is a meeting that is held at the end of a sprint.
It is an opportunity for the development team to demonstrate their product.
Before we get into the details,
I want to review Agile terminology that we'll be using in this lesson.
A sprint review meeting is a common scrum event.
The term scrum master is used to describe the role responsible for
facilitating scrum practices.
Product owner is used to describe the role that is responsible for
the product backlog.
Sprints will describe iterations.
There are two distinct scrum events that occur at the end of a sprint,
the sprint review meeting, and the spring retrospective meeting.
In simple terms, a sprint review meeting is where the product is demonstrated.
And the sprint retrospective meeting is where the team's process is reevaluated
and discussed.
You will learn about the sprint retrospective meeting in the last module
of this course.
The sprint review meeting occurs prior to the sprint retrospective meeting.
Let's jump into more detail now.
We covered scrum events in the lesson on scrum
from the course on Software Processes and Agile practices.
Scrum events occur throughout the development process.
Sprints, daily stand ups, sprint review meetings, and
sprint retrospective meetings are all examples of scrum events.
Other than a sprint, the scrum events are a formal opportunity to gain feedback and
evaluate progress.
Scrum events are all time boxed,
meaning they cannot exceed a predetermined amount of time.
The suggested amount of time that you should allot for
your sprint review meeting is one hour for each week of the sprint.
Therefore, if you have two week sprints,
you should box your sprint review meeting at two hours.
If your sprints are a month long,
your sprint review meetings should be allotted four hours.
You are scheduling the sprint review meeting for your development team.
Your team has just finished a three week sprint, and
they are eager to demonstrate their progress.
What's the maximum time that this meeting should last?
A. One hour.
B. One hour at the end of each week.
C. Three hours.
D. However long it should take.
You should time box your sprint meetings to be one hour for
each week of the sprint.
Since your team works in three week long sprints,
you should schedule three hours for this meeting.
Your meeting should not exceed three hours, therefore C is the correct answer.
Let's now talk about who gets invited to the sprint review meeting.
The answer is simple.
Anyone who has any interest in the product is invited.
Or using terms from the specialization,
all stakeholders are invited to the meeting.
Typically the meeting will consist of the scrum master, the product owner,
the scrum team, management, some customers and users, and
maybe developers from other projects.
The meeting is intended to be informal.
This means no slide presentations and minimal preparation.
Since the meeting is all about demonstrating the product,
the only preparation needed is to develop the product into working software.
Which is what the development team should be doing during the sprint.
There is very little prep for these meetings because the sprint review meeting
should not be a distraction for the development team.
Let's talk about some of the roles in a sprint review meeting.
As I mentioned, the scrum master is there to facilitate the meeting.
This means that they are there to make sure that it stays within
the scheduled time box.
The scrum master will make sure that conversations stay on track,
the people are voicing relevant comments, and that people are asking questions and
providing feedback appropriately.
Although the scrum master is the one facilitating the meeting,
the development team will usually run the meeting.
Everyone in the development team should have some input into the meeting,
since they all played a part.
The product owner is there to approve the features, and
make sure that the scrum team is following the overall product vision.
The other stakeholders will have an opportunity at the end of the meeting to
suggest feedback and improvements.
You are the scrum master at the sprint review meeting.
As the development team is demoing the product,
one of the stakeholders offers a suggestion for a new feature.
The development team, product owner, and
the stakeholder start discussing this new feature.
As the scrum master, what should you do?
A. Join the discussion.
B. Add the feature to the backlog.
C. Let them finish their discussion.
Or D. Ask that they save future suggestions until the end of the meeting.
As the scrum master you are responsible for facilitating the meeting.
This means keeping it on track.
You want to save future suggestions for the end of the meeting.
This allows the development team to completely demo their product
without distractions.
If conversations start to get off topic, you want to direct them back on track, or
else you risk exceeding your time box.
Therefore, D is the correct answer.
Let's talk about what happens in the meeting.
The scrum master should start by introducing guidelines for the meeting.
These could be guidelines such as when people are allowed to talk or
make suggestions.
Following that, the scrum team should go over the sprint goal.
Once the sprint goal is recapped,
there are three main events that occur in a sprint review meeting.
One, the product demonstration, two, the product owner approval, and three,
stakeholder feedback.
First the scrum team demos the product.
The demo should be as realistic as possible, using an appropriate platform.
For example, if the team is creating a mobile app,
they should demonstrate it using a mobile device.
The demo should also be authentic.
This means that features are not hard coded to work only for the demonstration.
It should be a live demo of ready and fully completed features.
Features should only be demonstrated when they have met the team's
definition of done.
Save incomplete features for future sprint review meetings, when they are done.
For example, the product demo only includes features that are coded, tested,
documented, usable, and ready to be released.
In the current sprint,
the development team had four features that were scheduled to be built.
Let's call them user stories A, B, C, and D.
User stories A and B met the team's definition of done.
User story C is done and works, but has not yet been fully tested.
User story D is pretty far from being complete, but
the developers could hard code it to make it look like it works for the demo.
Which user stories, if any,
should the development team demo at the sprint review meeting?
A. user story A?
B. user story B?
C. user story C, and/or D. user story D?
Your development team should only demo
user stories that have met the scrum team's definition of done.
This normally means that they are coded, testable and usable.
Only user stories A and B meet this criterion.
User story C still needs to be tested before it can be demonstrated.
This is important to make sure that the product functions as expected.
You should never hard code features for a demo, therefore answers A and
B are the correct answers.
Following the product demonstration,
the product owner then approves completed features from the product backlog.
Once the product owner approves a feature,
it is then removed from the product backlog.
The team may choose to have this happen at the meeting, or the product owner
can approve the feature after spending additional time to evaluate the product.
After the approvals, the scrum master opens the floor to stakeholders.
This is an opportunity for
the stakeholders to ask questions, suggest features, and give feedback.
Generally, feedback takes one of three forms.
It could be praise that the product or feature is on the right track.
It could also suggest areas for change or improvement, or the feedback could
identify areas that lead to questions, new problems, or revisiting assumptions.
Since the backlog is maintained and prioritized by the product owner,
stake holders are free to suggest as many features as they want.
It is up to the product owner to determine if or when these features get developed.
This would also be where the product owner can suggest features for the backlog.
We mentioned earlier that suggestions should not be added to the sprint backlog
in the middle of a sprint.
This would be an appropriate time for them to add their suggestions.
In the sprint review meeting, you have reached the third stage
that opens the meeting up for suggestions and feedback.
Who can suggest additional features at this time?
A. The product owner.
B. The stakeholders.
C. The development team.
And or D. The scrum master.
At this point in the meeting,
anyone can suggest features to be added to the backlog.
The product owner prioritizes the backlog, and
chooses when and if features get built.
There is no harm in having anyone suggest features.
Therefore, answers A, B, C, and D are all correct answers.
Sprint review meetings are a great opportunity to demonstrate the hard work
of the scrum team, increase transparency and gain valuable feedback.
They also give the Scrum team something to work towards, and
encourage them to produce working software.
In the next lesson,
we are going to continue to talk about ways to deliver the right product.
We are going to go over user studies, and
how they can be used when developing a software product.
Explore nosso catálogo
Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.
O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.
© 2019 Coursera Inc. Todos os direitos reservados.
