Explore
For Enterprise
Join for Free
Log In

Artes e Humanas
Negócios
Ciência da Computação
Ciência de Dados
Tecnologia da informação
da saúdesaúde
Matemática e Lógica
Desenvolvimento Pessoal
Ciência e Engenharia Física
Ciências Sociais
Línguas
Notas
Certificados

Explore todo o Coursera

Navegar
Pesquisar
For Enterprise
Entrar
Inscreva-se gratuitamente

5.1.2: Sprint Review Meeting

Loading...

Revisões e métricas para melhorias de software

Universidade de AlbertaUniversidade de Alberta

4.6 (956 classificações) | 17K alunos inscritos

Curso 5 de 6 no Gestão de produtos de software Gestão de Produtos de Software Programa de cursos integrados

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.

Visualizar o programa do curso

Habilidades que você aprenderá

Software Metric, Agile Software Development, Software Project Management, Software Metrics

Avaliações

4.6 (956 classificações)

5 stars
696 ratings
4 stars
198 ratings
3 stars
49 ratings
2 stars
9 ratings
1 star
4 ratings

FG

Feb 26, 2016

Everthing is interesting about this specialisation, this is my fifth coruse and I am so glad that I have invested my time in this.

SB

Apr 03, 2018

This course helped a lot in my academics as well as it also improved the level of interest that I have in software engineering.

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.

5.1.2: Sprint Review Meeting10:44

Ministrado por

Kenny Wong
Associate Professor

Transcrição

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

Baixar na App Store

Baixar no Google Play

Coursera
Sobre
Liderança
Carreiras
Lista de cursos
Certificados
Certificados MasterTrack™
Notas
For Enterprise
For Government

Comunidade
Learners
Partners
Developers
Beta Testers
Translators

Conectar
Blog
Facebook
LinkedIn
Twitter
Instagram
YouTube
Tech Blog

Mais
Termos
Privacidade
Ajuda
Acessibilidade
Imprensa
Contato
Diretório
Afiliados