[vc_row full_width_row=”true”][vc_column][vc_single_image image=”2566″ img_size=”full”][/vc_column][/vc_row][vc_row full_width_row=”true”][vc_column][vc_raw_js]JTNDJTIxLS0lMjBHb29nbGUlMjBUYWclMjBNYW5hZ2VyJTIwJTI4bm9zY3JpcHQlMjklMjAtLSUzRSUwQSUzQ25vc2NyaXB0JTNFJTNDaWZyYW1lJTIwc3JjJTNEJTIyaHR0cHMlM0ElMkYlMkZ3d3cuZ29vZ2xldGFnbWFuYWdlci5jb20lMkZucy5odG1sJTNGaWQlM0RHVE0tVDRWNVA0TSUyMiUwQWhlaWdodCUzRCUyMjAlMjIlMjB3aWR0aCUzRCUyMjAlMjIlMjBzdHlsZSUzRCUyMmRpc3BsYXklM0Fub25lJTNCdmlzaWJpbGl0eSUzQWhpZGRlbiUyMiUzRSUzQyUyRmlmcmFtZSUzRSUzQyUyRm5vc2NyaXB0JTNFJTBBJTNDJTIxLS0lMjBFbmQlMjBHb29nbGUlMjBUYWclMjBNYW5hZ2VyJTIwJTI4bm9zY3JpcHQlMjklMjAtLSUzRSUwQSUwQSUzQ3NjcmlwdCUyMHR5cGUlM0QlMjJ0ZXh0JTJGamF2YXNjcmlwdCUyMiUyMHNyYyUzRCUyMmh0dHBzJTNBJTJGJTJGY2RuLnl3eGkubmV0JTJGanMlMkYxLmpzJTIyJTIwYXN5bmMlM0UlM0MlMkZzY3JpcHQlM0U=[/vc_raw_js][vc_column_text][ps2id id=’WHAT’ target=”/A][/vc_column_text][/vc_column][/vc_row][vc_row type=”vc_default” content_placement=”middle” full_width_row=”true” bg_type=”grad” bg_grad=”background: -webkit-gradient(linear, left top, left bottom, color-stop(0%, #5E575E), color-stop(100%, #D6D6D6));background: -moz-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: -webkit-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: -o-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: -ms-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: linear-gradient(left,#5E575E 0%,#D6D6D6 100%);”][vc_column][vc_column_text]

What is Burn down chart

[/vc_column_text][/vc_column][/vc_row][vc_row full_width=”stretch_row_content_no_spaces” content_placement=”middle”][vc_column][vc_column_text]Agile team use Burndown chart to track remaining work, It can be scale to different level like Epic Burn Down, Release Burndown, Sprint Burndown etc.

This article is on only [dt_highlight color=”” text_color=”” bg_color=””]Sprint Burndown [/dt_highlight]chart. Sprint Burndown chart is a visual representation of remaining works for the scrum team of a specific sprint. Burn-down charts represents the real time total amount of work as pending for the sprint of any team, amount of work can be measured as remaining effort hours, or story points. Using the unit as “task hours” rather than “story points” is always better for burn-down chart. I personally suggest to use task hours to plot the burn-down chart.

In this article we will learn details about burn-down chart, with the below mentioned points[/vc_column_text][/vc_column][/vc_row][vc_row full_width=”stretch_row_content_no_spaces” content_placement=”middle”][vc_column][vc_raw_html]JTNDZGl2JTIwY2xhc3MlMjAlM0QlMjAlMjJteVBhcmVudERpdiUyMiUzRSUwQSUzQ2RpdiUyMGNsYXNzJTIwJTNEJTIwJTIybXlEaXYlMjIlM0UlMEElM0NidXR0b24lMjBjbGFzcyUzRCUyMmJ1dHRvbiUyMiUyMG9uY2xpY2slM0QlMjJ3aW5kb3cubG9jYXRpb24uaHJlZiUzRCUyNyUyM0hPVyUyNyUyMiUzRUhvdyUyMGJ1cm4tZG93biUyMGNoYXJ0JTIwZ2V0cyUyMGdlbmVyYXRlZCUyMGFuZCUyMHdoYXQlMjBleGFjdGx5JTIwaXQlMjByZXByZXNlbnRzJTNGJTNDJTJGYnV0dG9uJTNFJTBBJTNDYnV0dG9uJTIwY2xhc3MlM0QlMjJidXR0b24lMjIlMjBvbmNsaWNrJTNEJTIyd2luZG93LmxvY2F0aW9uLmhyZWYlM0QlMjclMjNSRUFEJTI3JTIyJTNFSG93JTIwdG8lMjByZWFkJTIwYnVybiUyMGRvd24lMjBjaGFydCUzRiUzQyUyRmJ1dHRvbiUzRSUwQSUzQ2J1dHRvbiUyMGNsYXNzJTNEJTIyYnV0dG9uJTIyJTIwb25jbGljayUzRCUyMndpbmRvdy5sb2NhdGlvbi5ocmVmJTNEJTI3JTIzU0NFTkFSSU9TJTI3JTIyJTNFU2NlbmFyaW9zJTIwd2hlbiUyMHdlJTIwcmVmZXIlMjBvdXIlMjBidXJuJTIwZG93biUyMGNoYXJ0JTIwdG8lMjB0YWtlJTIwZGVjaXNpb24uJTNDJTJGYnV0dG9uJTNFJTBBJTNDYnV0dG9uJTIwY2xhc3MlM0QlMjJidXR0b24lMjIlMjBvbmNsaWNrJTNEJTIyd2luZG93LmxvY2F0aW9uLmhyZWYlM0QlMjclMjNQRVJGT1JNQU5DRSUyNyUyMiUzRVJlYWQlMjB0ZWFtJTIwcGVyZm9ybWFuY2UlMjBmcm9tJTIwYnVybiUyMGRvd24lMjBjaGFydCUyMGFuZCUyMGRlZmluZSUyMGFjdGlvbiUyMGl0ZW1zLiUzQyUyRmJ1dHRvbiUzRSUwQSUzQ2J1dHRvbiUyMGNsYXNzJTNEJTIyYnV0dG9uJTIyJTIwb25jbGljayUzRCUyMndpbmRvdy5sb2NhdGlvbi5ocmVmJTNEJTI3JTIzRElTQURWQU5UQUdFUyUyNyUyMiUzRURpc2FkdmFudGFnZXMlMjBmb3IlMjB1c2luZyUyMFN0b3J5JTIwcG9pbnRzJTIwYXMlMjBidXJuJTIwZG93biUyMG1lYXN1cmVtZW50JTIwdW5pdHMuJTNDJTJGYnV0dG9uJTNFJTBBJTNDJTJGZGl2JTNFJTBBJTNDJTJGZGl2JTNF[/vc_raw_html][vc_column_text][ps2id id=’HOW’ target=”/A][/vc_column_text][/vc_column][/vc_row][vc_row type=”vc_default” content_placement=”middle” full_width_row=”true” bg_type=”grad” bg_grad=”background: -webkit-gradient(linear, left top, left bottom, color-stop(0%, #5E575E), color-stop(100%, #D6D6D6));background: -moz-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: -webkit-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: -o-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: -ms-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: linear-gradient(left,#5E575E 0%,#D6D6D6 100%);”][vc_column][vc_column_text]

How burn-down chart gets generated and what exactly it represents?

[/vc_column_text][/vc_column][/vc_row][vc_row full_width=”stretch_row_content_no_spaces” content_placement=”middle”][vc_column][vc_column_text]Burn-down Chart is a sprint artifact, every sprint has their individual burn-down chart, ALM tools generate the burn-down chart for each sprint right after sprint planning or when the any sprint starts. If you are not using any ALM tool, then you need to manually create your burn-down chart on excel or white board based on your convenience.

A burn-down chart have two major value area, X axis and Y axis, X axis represents the number of days for the sprint, where the Y axis represents the amount of work. The value with in the graph is remaining work (lets take it as hours) for any specific day with in the sprint duration.

To understand this it in more details, refer the below image followed by the explanation of the picture.[/vc_column_text][vc_single_image image=”2585″ img_size=”large” alignment=”center” onclick=”link_image” lazy_loading=”true”][vc_column_text]If you look into the above picture, we can notice the team has a product backlog, and during sprint backlog the team has committed few user stories, and later the team members have distributed the task, each member will work on with an estimated effort hours for each task. So far we have committed stories for the sprint, Each stories have some tasks with estimated hours, and each task is assigned to respected team members.

(We are not talking about story point here, as this article will talk about burn-down chart with Task hours.)

If you total the task hours it will be some where at 110 hours. lets assume the team have a capacity of 130 hours, which we will bring into the picture little later.

Lets see the other important are of the sprint, we have a sprint start date that is 10th Dec and it is ending on 21st of Dec, which means its a two week sprint, and the sprint duration is 10 days.

So from all those information, we will pick or the ALM toll will pick two major values (as below) to plot the burn-down chart for the first time

  1. Total Days of the sprint = 10 days
  2. Total committed & estimated task hours for the team = 110 Hours

If we divide the total hours by the total days means (110 /10 ) = 11 hours.

Which says, if the team complete 11 hours of work daily, then by end of the last day of the sprint , the team will be able to complete all the work they have committed.

refer the picture below followed by the instruction to understand it better.[/vc_column_text][vc_single_image image=”2587″ img_size=”large” alignment=”center” onclick=”link_image” lazy_loading=”true”][vc_single_image image=”13808″ img_size=”full” alignment=”center” onclick=”custom_link” lazy_loading=”true” link=”https://alumni.agiledigest.com/product/safe-scrum-master-certification-workshop/”][vc_column_text]As we learned, that based on the example of current sprint, the team needs to work on 11 hours per day. By end of the first day the team will be able to complete 11 hours of work from 110 total hours. so remaining total hours will be 110 – 11 = 99 hours by end of first day. And similarly by end of 2nd day the remaining hours of work will be 99 – 11 = 88 hours. In this fashion by end of last day the remaining hours of work will be zero.

This is the future prediction, where the ALM tool or your excel predicts that the team will be able to work on 11 hours every day and all that 11 hours will be reduce the remaining hours accordingly, the line on the predicted value on each day is called [dt_highlight color=”” text_color=”” bg_color=””]Ideal line of burn-down chart[/dt_highlight]. Which get plotted on the chart on the first day of the sprint, the lines starts from day one to end of last day.

But in reality the remaining hours at end of every day will not be same as predicted, because of the following reason.

  1. Even after working 11 hours or more, its not necessary the remaining hours will reduce by 11 hours, because 11 hours was just the estimation, once the team start working on the real construction, the actual hours may differ than the estimate. In agile what is important is, we don’t care about how much work we have done, we care about how much amount of work is pending or remaining. keeping that mantra in mind, every one update the remaining hours for each task they have worked on. Now the system (ALM tool or your Excel) will calculate the total of remaining hours by end of the date, and get the out of total estimated hours, how much is burned down. If the total remaining hours at the day one is lets say 105 hours, so the total burn down on day one is 110 – 105 = 5 hours. where in Ideal line it was 11 Hours.
  2. There are possibilities of Scope creep due to product owners critical priority change. which will increase or decrease the remaining hours suddenly, result to sudden rise or fall of the actual line.
  3. team members fall sick, that day the tasks assigned to the member may not be burned down
  4. Impediments, the blocker like external dependencies, development environment etc may slow down the predicted momentum of burn down.
  5. and many other reasons.

So the system calculate the actual remaining hours up to the current date or sprint last date (which ever is smaller), and plot a line which is called [dt_highlight color=”” text_color=”” bg_color=””]Actual burn down line[/dt_highlight]

refer the below picture to understand how actual burn-down lines flows on burn-down chart[/vc_column_text][vc_row_inner][vc_column_inner width=”1/3″][vc_column_text]

Actual burn-down line on Day 3

[/vc_column_text][vc_single_image image=”2590″ img_size=”medium” alignment=”center” onclick=”link_image” lazy_loading=”true”][/vc_column_inner][vc_column_inner width=”1/3″][vc_column_text]

Actual burn-down line on Day 6

[/vc_column_text][vc_single_image image=”2591″ img_size=”medium” alignment=”center” onclick=”link_image” lazy_loading=”true”][/vc_column_inner][vc_column_inner width=”1/3″][vc_column_text]

Actual burn-down line on Last day 

[/vc_column_text][vc_single_image image=”2592″ img_size=”medium” alignment=”center” onclick=”link_image” lazy_loading=”true”][/vc_column_inner][/vc_row_inner][vc_column_text]There is one more line which is very useful if you have it on your burn-down chart. That is called [dt_highlight color=”” text_color=”” bg_color=””]Capacity burn-down line[/dt_highlight]. So if we talk about the above example, the team has committed total of 110 hours of work for a 10 days sprint, where lets assume the team had a capacity of 130 hours.

The Ideal line was plotted based the commitment of 110 hours ( 11 Hours burn down every day). For capacity burn down we can plot another smooth line based on the available capacity of 130 hours (13 hours burn down every day).

This line is very important, will learn its importance later in this article, So far Rally or Jira does not provide this line on their burn down, however the burndown chart in TFS  have the capacity line.

Refer the below picture to get a visual of capacity burn down line.[/vc_column_text][vc_row_inner][vc_column_inner width=”1/2″][vc_column_text]

Understanding Capacity Line 

[/vc_column_text][vc_single_image image=”2594″ img_size=”medium” alignment=”center” onclick=”link_image” lazy_loading=”true”][/vc_column_inner][vc_column_inner width=”1/2″][vc_column_text]

A Complete burn down chart with capacity line.

[/vc_column_text][vc_single_image image=”2595″ img_size=”medium” alignment=”center” onclick=”link_image” lazy_loading=”true”][/vc_column_inner][/vc_row_inner][vc_column_text][ps2id id=’READ’ target=”/A][/vc_column_text][vc_single_image image=”13807″ img_size=”full” alignment=”center” onclick=”custom_link” lazy_loading=”true” link=”https://alumni.agiledigest.com/product/safe-advanced-scrum-master-certification-workshop/”][/vc_column][/vc_row][vc_row type=”vc_default” content_placement=”middle” full_width_row=”true” bg_type=”grad” bg_grad=”background: -webkit-gradient(linear, left top, left bottom, color-stop(0%, #5E575E), color-stop(100%, #D6D6D6));background: -moz-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: -webkit-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: -o-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: -ms-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: linear-gradient(left,#5E575E 0%,#D6D6D6 100%);”][vc_column][vc_column_text]

How to read Burn-down Chart ?

[/vc_column_text][/vc_column][/vc_row][vc_row full_width=”stretch_row_content_no_spaces” content_placement=”middle”][vc_column][vc_column_text]I believe you all already aware of sprint burn-down chart, and referring it to track the progress and remaining work in the rest of the sprint sprint days. Here I will explain  few of the areas to understand how to read the burn-down chart. If you are new to agile or want to know more about burn-down, you may find it helpful.

As we know our burn-down chart has an ideal line and an actual line. you may have another line for capacity line.

When ever we refer our burn down we check our actual line as of today, and compare it with the ideal line.

  1. If the actual line ending anywhere above the ideal line, it means there is a risk to complete all the stories with in the sprint duration. How big the risk is depends upon vertical distance between the actual line end point and the ideal line.
    The higher the distance is bigger the risk, because as per the commitment the remaining hours on that day is actually more than what is supposed to be.
    There can be many reasons for that and needs to take corrective action, as proactive measure. reasons like
    a.) The team is not able to give enough time to the sprint commitment.
    b.) The team has under estimated the tasks.
    c.) The team is not properly updating the remaining hours.
    d.) The team is getting new stories after the sprint start date.
    e.) The team is re-estimating the tasks hours, by increasing the remaining hours
    At the same time you need to check how many days in the sprint is remaining to recover the delay. If this situation appears during early sprint days, the team still have a chance to recover it, however during the last days of the sprints its very difficult to adjust the delay.

The below two diagram represents two different cases where one diagram says the risk is minimal, and another one represents high risks.[/vc_column_text][vc_row_inner][vc_column_inner width=”1/3″][vc_single_image image=”2608″ img_size=”medium” alignment=”center” onclick=”link_image” lazy_loading=”true”][/vc_column_inner][vc_column_inner width=”1/3″][vc_single_image image=”2607″ img_size=”medium” alignment=”center” onclick=”link_image” lazy_loading=”true”][/vc_column_inner][vc_column_inner width=”1/3″][vc_single_image image=”2610″ img_size=”medium” alignment=”center” onclick=”link_image” lazy_loading=”true”][/vc_column_inner][/vc_row_inner][vc_column_text]The rectangular box will not be there in your burn down. I sketched it here for better understanding, the light orange rectangle is the size of risk.

If you have the capacity line with your burn-down, you can get better visibility to identify the probability of resolving the risk. Even if the actual line is above the ideal line, but its below the capacity line, that means the team will be able to complete the tasks, as it is still under their capacity.

The below two diagram represents two burn-down chart one is at risk zone another is not risk on that particular day[/vc_column_text][vc_row_inner][vc_column_inner width=”1/2″][vc_single_image image=”2613″ img_size=”medium” alignment=”center” onclick=”link_image” lazy_loading=”true”][/vc_column_inner][vc_column_inner width=”1/2″][vc_single_image image=”2612″ img_size=”medium” alignment=”center” onclick=”link_image” lazy_loading=”true”][/vc_column_inner][/vc_row_inner][vc_column_text]2. Now Lets talk about another situation, when the actual line is always under the ideal line. Its a good sign, but if it is too low, then the team might have over estimated, and capable to work on more work for the sprint duration. Look at the situation. a good mature actual line should be close to the ideal line, if it is not the there is some thing needs intervention.

3. If you notice a sudden spike up or done on your burn down, then its means the team is getting too much of scope creep.

This is how you will read your burndown chart, during our next section will see how we can read our burndown chart on different scenarios.[/vc_column_text][vc_column_text][ps2id id=’SCENARIOS’ target=”/A][/vc_column_text][vc_single_image image=”13806″ img_size=”full” alignment=”center” onclick=”custom_link” lazy_loading=”true” link=”https://alumni.agiledigest.com/product/leading-safe-sa-certification-workshop/”][/vc_column][/vc_row][vc_row type=”vc_default” content_placement=”middle” full_width_row=”true” bg_type=”grad” bg_grad=”background: -webkit-gradient(linear, left top, left bottom, color-stop(0%, #5E575E), color-stop(100%, #D6D6D6));background: -moz-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: -webkit-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: -o-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: -ms-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: linear-gradient(left,#5E575E 0%,#D6D6D6 100%);”][vc_column][vc_column_text]

Scenarios when we refer our burn down chart to take decision

[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_row_inner][vc_column_inner width=”1/2″][vc_column_text]

Scenario 1 : Product Owner asked to add one story as it is on high priority, and the functionality of this story is very critical to deliver by this sprint end.

[/vc_column_text][vc_column_text]In this case, the team needs to check the current burn down chart and the actual line. How much additional bandwidth they have as of that specific day. There can be 3 scenarios :

  1. The Team can straight way agreed to the story addition to the current sprint

If the actual line ending much below the ideal line or capacity line, means have enough bandwidth available to finish the job with in sprint duration.

Keeping in mind individual capacity from tester and development prospective. Means even if the as a whole team there are lots of bandwidth available, but individual tester level there are not much bandwidth available, so in this case, you might refer to option 2 below.

So you will first look into your burn down, if it says you can commit more stories, check for other constraints and take the decision.

  1. Or the Team can ask the PO to descope some low priority story, means remove from the current sprint and move it back to backlog

If the team finds in burn down the actual line is close to the capacity line or ideal line, then the team checks the similar size of already committed stories which are not yet started development, ask the product owner to agree on de-scoping any(one or more) of those stories, to accommodate new critical stories.

Keep in mind, the time remaining in sprint, skill set required for the new story, and available bandwidth of those skilled team members.

  1. The team express it will be risky to add new stories on the sprint scope, and advice not to change scope. 

If the team reach to a end of the sprint there are only two to three days left, the actual line is very stable, few stories are already completed, few are in progress. In that case taking new stories may be risky, the team can explain to the product owner and suggest to wait for few more days to start the next sprint, and the team will complete this story as first priority, make it deploy ready as soon as possible.

However even if it is the last few days of the sprint duration, and all the stories of current are completed and accepted. The actual line already touched the ground. Then the team can quickly estimate and commit the story[/vc_column_text][/vc_column_inner][vc_column_inner width=”1/2″][vc_column_text]

Scenario 2 : One of the resource needs to go on sick leave for medical emergency for couple of days.

[/vc_column_text][vc_column_text]In this case check the burndown chart and analyze the position of actual line end point. if it is ending long under the ideal line, You may accommodate the unplanned vacation.

Check on individual level also total hours of pending work the resource has, and total number of days remaining for the sprint.

Check any other member of same skill member has enough bandwidth to supplement the gap.

If the team feels there are potential chance of not completing all the committed stories, Then the team should immediately inform PO, and reach to a conclusion like, identify less priority story to start last thing of the sprint etc.[/vc_column_text][vc_column_text]

Scenario 3 : During 2nd week of the sprint testing team raised too many bugs, that needs to be resolved with in the sprint duration.

[/vc_column_text][vc_column_text]If the tester is raising too many bugs during the testing of user stories, which is not a good sign of mature development, but even it happens. Check you actual line and capacity line difference. How comfortable the team is able to fix the bugs, along with the pending committed development work. The tester needs to re-test the big fix along with committed testing work.

The burn down should have enough bandwidth, means actual line should end much lower than the capacity line, to work on all the fixes. If Not, then next sprint onward, keep enough buffer as focus factor during your capacity planning.

Check your definition of done (DOD) about Defect closure, If it says All P1 and P2 bugs must close to make a story done. Check the number of P1/P2 bugs, the additional time to fix them, and bandwidth available in your burn down.

Consider talking with your PO, to act out the worst case scenario, and identify the most low priority story and most critical stories.

Burn down chart is the first place to decide whether you should talk to your PO now? or you need to further drill down the possible other constraints.[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_column_text]There can be many other scenarios on your work, and you may find burndown chart is helpful to take decisions on those situations.[/vc_column_text][vc_column_text][ps2id id=’PERFORMANCE’ target=”/A][/vc_column_text][vc_single_image image=”13805″ img_size=”full” alignment=”center” onclick=”custom_link” lazy_loading=”true” link=”https://alumni.agiledigest.com/product/safepopm/”][/vc_column][/vc_row][vc_row type=”vc_default” content_placement=”middle” full_width_row=”true” bg_type=”grad” bg_grad=”background: -webkit-gradient(linear, left top, left bottom, color-stop(0%, #5E575E), color-stop(100%, #D6D6D6));background: -moz-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: -webkit-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: -o-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: -ms-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: linear-gradient(left,#5E575E 0%,#D6D6D6 100%);”][vc_column][vc_column_text]

Read team performance from burn down chart and define action items

[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_custom_heading text=”There are many trend of sprint burndown charts actual line. Explain few typical unusual case of sprint burndown chart, and explained what does that cause and corrective actions.” font_container=”tag:h3|font_size:24|text_align:center” google_fonts=”font_family:Abel%3Aregular|font_style:400%20regular%3A400%3Anormal”][/vc_column][/vc_row][vc_row][vc_column][vc_separator][/vc_column][/vc_row][vc_row][vc_column width=”1/2″][vc_custom_heading text=”Straight Actual Line” font_container=”tag:h4|font_size:20|text_align:center” google_fonts=”font_family:Abel%3Aregular|font_style:400%20regular%3A400%3Anormal”][vc_single_image image=”2622″ img_size=”large” alignment=”center” onclick=”link_image” lazy_loading=”true”][/vc_column][vc_column width=”1/2″][vc_column_text]You might have encountered your team sprint burndown have straight lines for couple of days. That can caused by one or more of the following reasons

  1. Team is not updating the remaining task hour on daily basis
  2. Team has not created all the tasks, so not able to change the remaining hours
  3. Task estimation was underestimated, so remaining hour are not changing
  4. user stories are blocked by some impediments and those are not resolved, so the team is unable to proceed
  5. Environmental issue like development server not available to do coding or test environment not accessible for testing

How to resolve them ?

  1. Make sure each and every team member update the remaining hours of the task they are working on daily basis.
  2. During Tasking of user story, don’t take it lightly, take your time to create and estimate tasks as accurate as possible.
  3. Try to resolve the impediments, as soon as possible, if some stories are blocked, don’t wait for its resolution, start working on the stories, if all the stories are blocked and that may take couple of days to resolve, inform Product Owner and act accordingly.
  4. Before starting the sprint map all your dependencies, resolve the dependencies first then commit the story, till the time the dependencies are not resolved work on independent stories.
  5. Resolve all environmental issue, check availability and accessibility before starting the sprint.

[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_separator][/vc_column][/vc_row][vc_row][vc_column width=”1/2″][vc_custom_heading text=”Actual line touching the ground much before the last date of the sprint” font_container=”tag:h4|font_size:20|text_align:center” google_fonts=”font_family:Abel%3Aregular|font_style:400%20regular%3A400%3Anormal”][vc_single_image image=”2630″ img_size=”large” alignment=”center” onclick=”link_image” lazy_loading=”true”][/vc_column][vc_column width=”1/2″][vc_column_text]If you notice that the actual line is touching the ground much before the ideal line, that means one or more of these.

  1. The team has worked aggressively, burned more hours per day as per the capacity
  2. The Team has committed less than the capacity
  3. The team has over estimated the task.

Resolution.

  1. If the team willingly work hard, its good, but its always better to have defined hours of work to be done. working extra hours every day may cause other negative effects. Plan your capacity based on the best optimized amount of work the team can perform.
  2. If the team commits less than the capacity, that happened because most of the time because of insufficient amount of requirement, Product Owner may not have enough story ready to commit at the time of planning. Work on frequent and regular grooming to have your backlog healthy.
  3. Estimate fare, make it as accurate as possible

[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_separator][vc_single_image image=”13804″ img_size=”full” alignment=”center” onclick=”custom_link” lazy_loading=”true” link=”https://alumni.agiledigest.com/product/mastering-jira-software-jira-training/”][/vc_column][/vc_row][vc_row][vc_column width=”1/2″][vc_custom_heading text=”Actual line have Sudden Spike” font_container=”tag:h4|font_size:20|text_align:center” google_fonts=”font_family:Abel%3Aregular|font_style:400%20regular%3A400%3Anormal”][vc_single_image image=”2629″ img_size=”large” alignment=”center” onclick=”link_image” lazy_loading=”true”][/vc_column][vc_column width=”1/2″][vc_column_text]If you notice that your actual burn down line has a sudden spike upward, its means there are

  1. change on scope (Scope Increased between sprint duration), You PO may have asked to add one or few stories to the current sprint.
  2. Or the team has re-estimated the task to increase the remaining work.

Resolution

  1. Mature up your Sprint Planning, Have your backlog healthy so that you can fully utilize your capacity during sprint planning, by committing max possible product backlog item in priority.
  2. Do a task breakdown thoroughly, create all the possible tasks created, estimated and assigned. so that you don’t need to re-estimate during sprint duration.

[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_separator][/vc_column][/vc_row][vc_row][vc_column width=”1/2″][vc_custom_heading text=”Ideal line and capacity line have too much difference on day 1″ font_container=”tag:h4|font_size:20|text_align:center” google_fonts=”font_family:Abel%3Aregular|font_style:400%20regular%3A400%3Anormal”][vc_single_image image=”2628″ img_size=”large” alignment=”center” onclick=”link_image” lazy_loading=”true”][/vc_column][vc_column width=”1/2″][vc_column_text]If your ideal line and capacity line have a big distance means, The team has not committed their full capacity. because of

  1. Unavailability of enough user stories in ready state, so team has ended up the sprint planning with
  2. or Team is not confident to utilize the full capacity, hence only partial capacity.

How to resolve this situations for future sprints.

  1. Again Continuous backlog grooming to have healthy backlog of ready to work on Items.
  2. Understand the requirement in details covering all aspects. Then only  commit the user story during sprint planning. Let individual team member create, estimate and assigned tasks for them. continue the planning till the max capacity utilized.

[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_separator][/vc_column][/vc_row][vc_row][vc_column width=”1/2″][vc_custom_heading text=”Actual line is out side the ideal line for consistence days and difference in increasing.” font_container=”tag:h4|font_size:20|text_align:center” google_fonts=”font_family:Abel%3Aregular|font_style:400%20regular%3A400%3Anormal”][vc_single_image image=”2627″ img_size=”large” alignment=”center” onclick=”link_image” lazy_loading=”true”][/vc_column][vc_column width=”1/2″][vc_column_text]This state is very risky, and a clear indication that the team will not be able to complete all the committed work item by end of the sprint. This cause because of many reason like

  1. Even the team is working as expected, but they are not updating the remaining hours.
  2. The Team is actually not working
  3. The Team is blocked or impeded.
  4. The team has found estimated task hours are too low, need to work more, insted of re-estimating the task, they are not updating the remaining hours, working to bring the remaining hours as per burn down.

How to resolve this case, for this sprint or Future sprint.

  1. Please update the remaining hours every day, it may bring some spike, it will depict the real picture.
  2. Rest of the cases resolution varies from team to team, analyze it and take a best suited corrective action.

[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_separator][/vc_column][/vc_row][vc_row][vc_column width=”1/2″][vc_custom_heading text=”Straight lines and Sudden drop of actual line” font_container=”tag:h4|font_size:20|text_align:center” google_fonts=”font_family:Abel%3Aregular|font_style:400%20regular%3A400%3Anormal”][vc_single_image image=”2626″ img_size=”large” alignment=”center” onclick=”link_image” lazy_loading=”true”][vc_single_image image=”2625″ img_size=”large” alignment=”center” onclick=”link_image” lazy_loading=”true”][vc_column_text][ps2id id=’DISADVANTAGES’ target=”/A][/vc_column_text][/vc_column][vc_column width=”1/2″][vc_column_text]This is the typical case, you might have encountered, The reason behind this can be because any of these reasons

  1. Mostly occurs, when team use story points as y axis of their burn down.
  2. remaining work updates are not happening, regularly.
  3. remaining work updates happen only on last date of the sprint as a formality.

How to work on this

  1. Start task breakdown, and have the Y axis of your burndown with task hours.
  2. Update Remaining hours on daily basis.

Will talk about why we should not use story point as Y axis of our Sprint burndown on the following section

[/vc_column_text][/vc_column][/vc_row][vc_row type=”vc_default” content_placement=”middle” full_width_row=”true” bg_type=”grad” bg_grad=”background: -webkit-gradient(linear, left top, left bottom, color-stop(0%, #5E575E), color-stop(100%, #D6D6D6));background: -moz-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: -webkit-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: -o-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: -ms-linear-gradient(left,#5E575E 0%,#D6D6D6 100%);background: linear-gradient(left,#5E575E 0%,#D6D6D6 100%);”][vc_column][vc_column_text]

Disadvantages for using Story points as burn down measurement units.

[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_single_image image=”13801″ img_size=”full” alignment=”center” onclick=”custom_link” lazy_loading=”true” link=”https://alumni.agiledigest.com/product/4-stages-to-scrum-master/”][vc_column_text]The purpose of Sprint Burndown Chart is to track the remaining amount of work, It has to be referred every day, and the team make the strategy of the work they will perform for the day. So every day it has to burn down.

In case of Story Points, its not necessary every day one story will get completed, even the team has already worked on it and burned some work. So even the work has burned down, the chart of burndown on story point will now reflect any changes. A story with any story point lets say 5 SP can either be completed or not completed, it will not burn as 5 to 3 to 2 to 1. Once the story is completed the the story point will remain same as 5, only the state will change to done. So you will see a zigzag burndown instead of real reaming amount of work as of that specific day.

The Stories are counted as completed when it is verified and accepted by the Product Owner. many times a development and testing completed story not gets verified by product owner, as Product Owner along with development team have not started working as team and PO gives priority to other activity, which created delay on story acceptance. and results become visible on your Sprint burndown chart.

Remember this article is only on Sprint Burn Down chart. The Epic and Release burn down can be plotted using Story Points.

Below mentioned three sample sprint burndown chart, to refer and compare difference between sprint burndown on Hours and Story Points.[/vc_column_text][vc_row_inner][vc_column_inner width=”1/3″][vc_single_image image=”2636″ img_size=”large” alignment=”center” onclick=”link_image” lazy_loading=”true”][/vc_column_inner][vc_column_inner width=”1/3″][vc_single_image image=”2638″ img_size=”large” alignment=”center” onclick=”link_image” lazy_loading=”true”][/vc_column_inner][vc_column_inner width=”1/3″][vc_single_image image=”2637″ img_size=”large” alignment=”center” onclick=”link_image” lazy_loading=”true”][/vc_column_inner][/vc_row_inner][/vc_column][/vc_row][vc_row][vc_column][vc_column_text][ps2id id=’VIDEO’ target=”/A]

Videos 

[dt_divider style=”thin” /]

[/vc_column_text][vc_empty_space][vc_row_inner content_placement=”middle”][vc_column_inner width=”1/2″][vc_video link=”https://youtu.be/Lr45NwjFVdw”][/vc_column_inner][vc_column_inner width=”1/2″][vc_single_image image=”1612″ img_size=”full” alignment=”center” onclick=”custom_link” img_link_target=”_blank” link=”https://www.youtube.com/c/agiledigest”][vc_column_text]

Subscribe to our youtube channel to get notified.

[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_separator][/vc_column][/vc_row][vc_row][vc_column][vc_message message_box_style=”3d” style=”square” message_box_color=”green” icon_type=”openiconic” icon_openiconic=”vc-oi vc-oi-info”]Hope this page was able to provide the information you were looking for, In case we missed something, feel free to leave your comments, feedback and suggestions, at bottom of the page’s comment section.[/vc_message][/vc_column][/vc_row][vc_row type=”1″ full_width=”stretch_row_content”][vc_column][vc_empty_space][vc_column_text]

Author(s) of this article

[/vc_column_text][vc_row_inner][vc_column_inner width=”1/4″][vc_raw_html]JTNDZGl2JTIwY2xhc3MlM0QlMjJMSS1wcm9maWxlLWJhZGdlJTIyJTIwJTIwZGF0YS12ZXJzaW9uJTNEJTIydjElMjIlMjBkYXRhLXNpemUlM0QlMjJtZWRpdW0lMjIlMjBkYXRhLWxvY2FsZSUzRCUyMmVuX1VTJTIyJTIwZGF0YS10eXBlJTNEJTIyaG9yaXpvbnRhbCUyMiUyMGRhdGEtdGhlbWUlM0QlMjJsaWdodCUyMiUyMGRhdGEtdmFuaXR5JTNEJTIybmlsYWRyaS1tYWhhcGF0cmEtMzA2OGExNSUyMiUzRSUzQ2ElMjBjbGFzcyUzRCUyMkxJLXNpbXBsZS1saW5rJTIyJTIwaHJlZiUzRCUyN2h0dHBzJTNBJTJGJTJGaW4ubGlua2VkaW4uY29tJTJGaW4lMkZuaWxhZHJpLW1haGFwYXRyYS0zMDY4YTE1JTNGdHJrJTNEcHJvZmlsZS1iYWRnZSUyNyUzRU5pbGFkcmklMjBNYWhhcGF0cmElM0MlMkZhJTNFJTNDJTJGZGl2JTNF[/vc_raw_html][/vc_column_inner][vc_column_inner width=”1/4″][/vc_column_inner][vc_column_inner width=”1/4″][/vc_column_inner][vc_column_inner width=”1/4″][/vc_column_inner][/vc_row_inner][/vc_column][/vc_row]

Leave a Reply

Scroll to Top