Understand Sprint burn-down chart, with the below mentioned topics.

 What is sprint burn-down chart?

 How burn-down chart gets generated and what exactly it represents?
 How to read burn down chart?
 Scenarios when we refer our burn down chart to take decision. Read team performance
from burn down chart and define action items.

Scope change from PO

 The team can agree to the story addition to the current sprint. Keep in mind the
skill level individual remaining work. (do we need a new skill set or we have an
existing? Skill set such as dev, tester, tools, knowledge needed).
 We can descope stories low priority story that means removing them from current
sprint to backlog. Keep in mind the remaining time for the sprint. Available band
with for skill to accommodate the new story.
 If the team express, it will be risky to add a new stories on the sprint scope and
advise not to change scope(maybe almost end of sprint or no stories to descope)


Resource going to be out?

 Team can accommodate the unplanned vacation.

 Check skill level bandwidth.
 If the team feels there are potential chances of not completing all the committed stories,
then the team should immediately inform PO and start identifying stories with lesser
priorities so they can be started last.
 

2nd week of sprint and QA raised to many defects that need to be resolved within the sprint
duration.

 Check your DOD about defect closure. If you D? for defects states bugs must close to
make story done
 Do not change AC and requirements once stories are committed.


Read team performance from burndown chart and define actions.

Possible causes:
  Team is not updating remaining task on daily basis.
 Team has not created all task and therefore are unable to change the remaining hours.
 User stories are blocked by some impediments and those are not resolved so the team is
unable to proceed.
 Environmental issues like dev servers are not available for coding or test environment not
available for testing.

Action Points.

 Make sure each and every team member updates the remaining hours of the task they
are working on daily basis.
 During tasking of US don’t take it lightly. Take your time to create task as accurate as
possible.
 If there are blocked stories do not wait on the resolution instead pick up the nest US and
also inform PO.
 Map all dependencies before starting the sprint. Resolve all dependencies before
committing to the US. If dependencies are not properly resolved do not pull them into the
sprint but work on other independent stories.
 Resolve all environmental issues, check availability and accessibility before starting the
sprint.


Actual line touching the ground much before the last date of the sprint.
Possible Cause:

 The team has worked aggressively, burned more hours per day as per the capacity.
 The team under committed than the capacity.
 The team overestimated the task.

Action Points:

 This shows the team is over burning. The team is working too hard but it is always better
to have defined hours of work to be done. Working extra hours may cause negative
effects on the team. Plan your capacity based on the best optimized amount of wok the
team can perform.
 If the team under commits due to the insufficient amount of requirements, PO may not
have enough story ready to commit at the time of planning.
 Disadvantages for using Story points as burn down measurement units.

Actual Line have a sudden spike.

Possible Cause:
 Scope change
  Re-estimated task of US in the sprint.

Action Points:

 Mature up your sprint planning, keep a healthy backlog so that you can fully utilize your capacity
during sprint planning by committing max possible PBI in priority.
 Do a thorough story breakdown so that they do not get re estimated in the sprint.

Actual line and capacity line have too much difference in one day.

Possible Cause
 Unavailability of enough user stories in ready state
 Team not confident to use full capacity.

Action Points:

 Continuous backlog grooming to have a healthy backlog.

 Understand requirements in detail.
 Team members should create, estimate and assign US to them selves
 Continuous planning until team achieves max capacity.
Actual line is outside the ideal line for consistent days and difference is increasing.

Possible Cause:

 The team maybe working but they are not updating the task on the board.
 The team mamy not actually be working.
 Team is blocked.
 Estimated US are low and need more work

Action Points:

 Update everyday.
 Straight line and sudden drop of actual line

Possible Cause:
 Mostly occurs when team use story points as y axis of their burn down.
 Remaining work updates are not happening regularly
 Remaining work updates happen only on the last day of the sprint.

Action Points:
 Start US break down and have the Y axis of your burn down with task hours.
 Update remaining hours on daily basis.
 Disadvantages od using SP as burndown measurement units.
 Hours are the best option for sprint burn down Y axis.
 In the case of SP it is necessary everyday one of the story will get completed even if the team
has worked on it.
 Even if the work has burned down the chart of burndown on SP will now reflect any changes.
 A story with SP can either be completed or not
 Depends on PO acceptance.