5.3.3: Release Burndown Chart

Loading...

Del curso dictado por University of Alberta

Reviews & Metrics for Software Improvements

816 calificaciones

Explore Related Videos

At Coursera, you will find the best lectures in the world. Here are some of our personalized recommendations for you

University of Alberta

Reviews & Metrics for Software Improvements

816 calificaciones

Curso 5 de 6 en SpecializationSoftware Product Management

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.

De la lección

Module 3: Managed Right

This third module examines the concept of managing your project right. You will learn some important and popular project management techniques. The module starts off by introducing you to the Daily Scrum meeting. You will learn ways to implement daily scrums with the teams that you work with as well as techniques to improve the meetings if they are not working well. Then we will cover the concept of Velocity in more detail which will prepare you for learning about burndown charts. This module covers both Release Burndowns, as well as Iteration Burndowns. We show you how to create, read, and use these useful tracking tools with the teams you work with. Together, these lessons will teach you how to ensure your projects are “managed right”.

5.3.3: Release Burndown Chart9:11

5.3.3A: Release Burndown Chart - Changing Requirements7:34

Conoce a los instructores

Kenny Wong
Associate Professor
Computing Science, Faculty of Science

[MUSIC]

A release burndown chart is a visual monitoring tool that is very common

in the scrum methodology.

A release burndown chart will show you how much work

the development team has completed, how much is left to complete.

The team's velocity in each sprint, and

when you should expect to finish the product.

As you can imagine, it's an excellent tool for

ensuring your project is managed right.

Since, a release burndown chart can show you all that information,

I bet you're picturing a pretty complicated chart, but

that's the beauty of a release burndown, it's a simple concept.

Let's take a look at a basic release burndown chart.

As you can see, we have our sprints listed horizontally.

This project depicted has six sprints.

Vertically, we have the total effort, this would be described with

whatever measure your team has chosen to size your requirements.

We're going to use story points in our examples.

Each bar in the graph that corresponds with the sprint represents the total

number of story points that are still remaining at the beginning of the sprint.

Naturally, at the beginning of sprint one, we have all the story points remaining

because we have not started completing them yet.

This would represent your total effort,

your total effort is the combined total of the story points for

all the user stories that you intend to complete in the project.

As you complete requirements,

you remove their story points from the burndown chart.

Your development team is about to start their sixth and final sprint.

This is the release burndown chart for the project.

How many story points has your team completed, and

how many do they have remaining?

A. 100 story points completed, 15 story points remaining.

B. 100 story points completed, zero story points remaining.

C. 85 story points completed, 15 story points remaining.

Or D. 85 story points completed, zero story points remaining.

In this project, there were 100 total story points,

we know this because there were 100 story points at the beginning of sprint one.

At the beginning of sprint six,

which is the last sprint of the project, there are 15 story points remaining.

Since, we started with 100 story points and have 15 remaining, that means

that the team has completed 85 story points, therefore C is the correct answer.

Let's say that our total effort was 90 story points and

we completed 15 story points in the first sprint.

From the release burndown, we can see that our velocity for

the sprint was 15 points.

We can also see that the work remaining is 75 points. We

also know that we are starting from sprint two with 75 story points remaining.

If we wanted to predict how many sprints this product will take to complete, we can

draw a line through the bars to predict that. We call this line the prediction line.

Since, we're basing this of, of one sprint with a velocity,

You're going to make our predictions of that value.

Based on our prediction line, it says that it should take six sprints.

You may be thinking that the line is pointing to seven sprints but

remember that the release burn down is based on how many story points remain

at the beginning of each sprint.

That means that there would be no story points to complete at the beginning of

sprint seven, which means that you wouldn't need that sprint.

You can also use the prediction line to see if you are on track with development.

Let's say we have just completed sprint four, and

our release burndown chart looks like this.

In the first sprint, we completed 15 story points.

We wanted to maintain that pace, so that is the prediction line.

However, in sprint two, we only completed 5 story points,

as you can see, our bar for sprint three is now above the prediction line.

In sprint three we completed 15 story points.

We got our velocity back to the initial value, but

we are still behind schedule because of sprint two.

At the beginning of sprint four we should have completed 45 story

points all together and be halfway through development.

But as you can see, our bar for sprint four is above the prediction line.

We're behind 10 story points from where we wanted to be.

Let's now say that at the beginning of sprint four,

we hired two more developers because we saw that our project was behind schedule.

In sprint four,

we completed 25 story points, this put our project back on schedule.

In sprint five we completed 25 story points again,

this now put our project ahead of schedule.

As you can see, our bar for

the beginning of sprint six is now below the prediction line.

This means that your team might be able to complete a few more requirements

for the product.

In reality, it would be extremely rare that your release burndown looks like this.

It is much more common that you release burndown looks something like this.

Consider this release burndown chart, you have completed your first sprint,

if you maintain the initial velocity from this sprint,

how many sprints do you expect to need to finish the work?

A. Five sprints?

B. Six sprints?

C. Seven sprints?

D. Eight sprints?

Or E. You need more information.

If you maintain this velocity, your prediction line indicates that you will

have no story points to complete at the beginning of sprint six.

This means that you will have completed the project in five sprints,

therefore A is the correct answer.

Since our release burndown chart is measuring completed story points

you can imagine your team's definition of done, is very important.

In Agile, we measure progress on working software, so in order to mark

story points as complete, that requirement must meet your team's definition of done.

I've worked on teams that were not focused on working software.

We were developing a product that had a database connection,

half of our team was working on developing the database and

the other half was working on developing the product's user interface.

Even though many of the features were programmed for the interface and

the database was being developed,

we could not mark any of our requirements as done because we were waiting for

the database to be developed and connected to the application.

Our burndown chart ended up looking something like this.

As you can see from our burndown chart it looks as if we did nothing for

three sprints and then worked really hard in sprint four.

We knew that wasn't the case, but our burndown chart will show if your team is

working towards completing features entirely before moving on to new ones.

Otherwise, a burn chart is not a good representation of a product's progress.

You are working on a team that is developing a mobile application,

you have just completed your third sprint.

Your team's definition of done includes only features that are programmed,

documented and tested and ready for market.

Which of the following features should be counted as completed and

have its points deducted within the release burndown for the sprint?

A. A feature that was developed and documented but failed testing in the last

sprint has now received a minor fix and has passed tests in the current sprint.

B. A feature that you did not have time to test but you are sure that it works.

C. An interface feature that is programmed, documented, and

tested but has not been connected to the database yet.

And or D. A feature that works perfectly,

has passed all its tests in this spring, and is properly documented.

Only features that have met the team's definition of done

can be marked as complete for the release burndown.

Answers B and C are both features that have not met the definition of done,

therefore must not be marked as complete for the release burndown.

Answer A demonstrates a feature that did not meet the definition of done

last sprint but now does.

So, it can be marked as complete on this sprint for the release burndown.

Answer D also meets the team's definition of done, therefore,

it can be marked as completed for the release burndown.

A and D are the correct answers.

Explora nuestro catálogo

Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.

Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.

© 2019 Coursera Inc. Todos los derechos reservados.

Descargar en la App Store

Consíguelo en Google Play