Sprint Burndown Chart is a unique artifact, which indicates total remaining Product Backlog Item (PBI) towards the end of sprint.
It tells the Dev team and Scrum Master,
- Where they are in the schedule, at the right moment (by day)
- If their original plan is estimated over-granular
It tells the product owner (PO),
- if the original sprint plan is still optimistic, or if any adjustment should be considered
- This sprint last two and half weeks, 13 working days
- Planned work is 50 story points
- Sprint scope goes up on 24th Jul
- No stories completed over two days since 27th Jul
- 60% of work was completed in last 3 days (23% of sprint length)
Maybe you read more out of this chart. But I doubt it
In another hand, take a look the raw data that builds up the burn-down chart above
- Scope change on day 5, day 8 and day 12
- these are not necessarily obvious on burn-down chart. But it could be a topic to discuss about on retrospective meeting
- User story 187 was closed on day 3, and reopened on day 5
- It caused the scope “vomit” on burn-down chart
- Many lower prioritized stories are completed (on day 6), ahead of higher prioritized stories (user stories are prioritized in sequential order)
- Is this how PO wants?
- Is it because top stories are more sized (complicated), so Dev team intentionally chose lower stories to do?
- After 8 working days since sprint kick-off, high priority user stories 151 and 189 are are still open
- They are both 5 story points (relevantly complicated). Could it be the stories are too complicated for team to accomplish?
- Is this how PO wants?
- Is there any dependence blocks the progress?
- Was the team over-optimistic in estimation?
- User story 173 (5 point) was removed and replaced by user story 160 (5 point) after one week since sprint start
- It doesn’t mean we have the whole sprint to accomplish user story 160, as we planned for 173
- All effort spent on 173 (if any) was wasted
- 7 user stories (8.5 points) were completed on day 6 (26th); 12 user stories (32 points) were completed on day 11 & 12
- could they have been resolved and pending for review since earlier? if so, could we bring validation ahead?
You probably could generate more questions than I do. This is why I suggest to keep track of raw data than just few dots on burn-down. It’s always interesting to look into hidden facts within the raw data 🙂