Skip to main content

The Burn Up Charts In Scrum By: Namrata Parik

I would like to propose a less-taken path in my maiden article to track the progress in scrum. We usually do it using the burn down chart which is relatively easier to understand as compared to the burn up chart. These charts help the team and stakeholders to see and track the progress at any point in the release process or sprint.
Burn-down chart provides us the information showing the progress based on the remaining hours or story points from top to bottom. (The burn-down chart can be plotted using story points, task count or the remaining effort) This chart is a plot of expected remaining and actual remaining, this is the most used chart in scrum and since it has only two lines it is considered to be a simple chart. It does not cover the scope creep.
So sometimes what might look like ‘no work ‘ done by the team may actually be a result of scope creep.
The chart below reflects that the team has not done any progress in Sprint 5 and 6 as the story points remain the same.
Image source : https://stayrelevant.globant.com
Now coming to the burn-up chart. This chart is a plot of three parameters: scope, expected progress and actual progress.
In the chart below we can see that the real reason was a scope creep as shown by the scope plot

Image source : https://stayrelevant.globant.com
The actual sprint points ( in red) and the estimation at completion cover the scope creep and hence a more clear analysis on the team performance can be made

Image source : https://stayrelevant.globant.com
Burn-up charts allows to divide the scope and the progress which cannot be done in Burn-down as it plots only the expected remaining and actual remaining.
Therefore in teams where tasks of more importance (which cannot be neglected) keep on coming in between the sprint duration, burn up chart can be used to see the real picture.
That being said, in some teams when a new tasks comes, it is added to the sprint and the entire estimation and the burn down chart goes wayward.
That might not be the best practice but still can be a metric for monitoring the progress of the team in real terms.
In the chart below the team started with an estimate of 70 SP and there were a scope creeps which appear as spikes in the graph which can ALSO give an idea on the scope creep in a sprint, but not in the best possible manner

Image source: Google Images
References
  • https://stayrelevant.globant.com
  • https://www.scrumalliance.org

Comments

Post a Comment

Popular posts from this blog

Scrum Framework - 5 Events in Scrum Framework - By Ankur Mistry

In my previous articles, we have discussed  3 Roles  and  3 Artifacts  in Scrum. In this article, we are going to discuss 5 events in the Scrum Framework. There are Five events in Agile Scrum Framework. Sprint Planning Daily Scrum Sprint Review Sprint Retrospective The Sprint ( Figure: Life cycle of Scrum from  http://www.agiletroop.com/product/life-cycle-of-scrum/ ) Sprint Planning  is the event in which the Product Owner presents the ordered product backlog to the development team. As the word suggests, 'Sprint Planning' means we are going to plan the work to be done in the Sprint. There are two main parts - 'What' and 'How'. 'What' can be done in this Sprint? 'How' will the selected work get done? What can be done in the Sprint - In this part, the Product Owner presents the product backlog items with high business value tasks as a first priority to the development team. All team members collaborate to understand ...
1 comment
Read more

Scrum Framework - Three Artifacts - By Ankur Mistry

In this article, we will discuss three artifacts in Scrum Frameworks. There are three artifacts in Agile Scrum Framework. Product Backlog Sprint Backlog Working Product (Figure: Scrum Process from : https://commons.wikimedia.org/wiki/File:Scrum_process.svg) Product Backlog is an ordered list of tasks or features that need to be done within the project. It may have short descriptions of all functionality desired in the product. Product Backlog is owned by the Product Owner. It is an ordered list of features for the product. Each product item has an Order, Value, Description, and Estimation. Generally, tasks which have more business values are the top priority. Product Owner owns the product backlog. Product Owner makes sure that the product backlog is clear and transparent to the team. Anyone from the team can add an idea in the product backlog but it's product owner who decides which one stays there. There is one Product Backlog for one product, multiple...
Post a Comment
Read more

What is User Story ?

A User Story is a short description of something that your customer will do when they come to your website or use your application/software,  focused on the value or result they get from doing this thing. User stories are: written from the point of view of a person using your website or application written in the language that your customers would use. Three C’s of the user story: Card – stories are traditionally written on note cards, and these cards can be annotated with extra details Conversation – details behind the story come out through conversations with the Product Owner Confirmation – acceptance tests confirm the story is finished and working as intended. Template for User Stories : A user story template often uses the following type of format: As a <role> , I want <feature> so that <reason> . Examples of user stories are: As a  user , I want  to upload photos  so that  I can share photos with others . A...
1 comment
Read more