8. • Make the reality of the project clear.
• Show the impact of decisions.
• Warn you early if things aren't going according to plan.
• Get rid of all the wishful thinking around dates.
8
Why interpret BDC?!
9. • Remaining effort for a given period of time.
9
Simplicity vs Information
Must contain:
• X axis – remaining time
• Y axis – remaining effort
• Ideal effort as a guideline
• Real progress of effort
14. Hey team, this is even
worse. Maybe you
completed something but
completed work is not
visible as a progress!
• See Oh, management is
coming! chart
• Sprint might be still in
progress
14
Do Your Duties!!!
What to improve?
Restart. From scratch,
from training. Do
retrospective to
figure out why this is
happening.
15. • Stories/tasks are added
into backlog constantly.
• More work is added than
completed.
• Tasks are re-estimated
constantly.
• you will never be able to
complete the sprint if you
will not fix it.
15
First Sprint in life – Up to the Sky
What to improve?
Estimate stories/tasks
immediately and update
your backlog.
Do not forget to start
sprint if you use electronic
tool.
16. 16
Bump on the Road
Burn up first, then burn down.
• Stories not estimated at the beginning of sprint
• Stories added till mid of the sprint.
• Appropriate recognition of incorrect situation in the
mid of the sprint. Positive, but late.
What to improve?
• Restart your sprint by planning.
17. Hey team, you are not doing what is necessary!
Where are you going to? How do you know
whether you are able to finish the sprint on time?
• Maybe team is doing a work, but there is
someone adding an amount equal to completed
work.
• Team doesn’t update remaining time regularly.
• Send Scrum Master and team back to training
• Maybe stories were overestimated.
• Product owner doesn’t take care as well.
17
Management is coming!
18. What to improve?
• Stop the line after see line of 3 days as
row. Initiate retrospective immediately.
18
19. • Stories underestimated
• Low commitment of the
team
• Incorrect sprint capacity
calculation
• Stories not grabbed
from the next sprint
• Some team members
do not have tasks
assigned.
19
Too Early
What to improve?
After two or three days
Scrum Master should ask
if there is anything team
can do from the next
sprint. If yes then assign
20. 20
Too Late
“You did not completed
your commitment”. And
you were all the time late.
• Tasks not completed
• Adaptation not done
during the sprint
What to improve?
Check if size of the sprint
backlog is not growing. Stop
the production line as soon
as possible, before the
sprint. Remove low priority
stories from the sprint.
21. This burn down chart indicates
your team is fine to have a time
to rest.
• Team has finished work
earlier than expected, but
could do more.
• Maybe there are not enough
items in sprint backlog
• Maybe team is larger than
expected at the beginning
• Stories might be
overestimated
21
Let’s have a rest team
What to improve?
Get additional stories
as soon as possible
form the next sprint
according priorities.
22. This is typical burn down chart you
can see in many already experienced
team.
• Team committed to goal
• Adapted scope in case of need
• Team improving speed to get
things done
• Team is asking How we are going
to complete the sprint
• At the end they can grab
additional stories from the next
sprint
22
Nice Team
What to improve?
Stop before middle of the
sprint and discuss how to
get back on track.
Something with lower
priority should go out of
your sprint backlog.
23. This is typical burn down
chart you can see in many
already experienced team.
• A team committed to a
goal
• Adapted scope in case
of need
• Team improving speed
to get things done
23
Great Team
What to improve?
Grab additional stories
from the next sprint you
are able to complete in the
sprint.
24. Once you see such burn down
chart congratulate to the
team
• They are doing great job.
• Not over-committing
• Not late
• Not earlier
• On time
• Mastership
24
Ideal Team
What to improve?
Just continue!
25. • Scrum Team has Full Authority to admit
need for change, define approach, apply
solution… Knowledge is the key.
25
Conclusion and Inspiration
The team is non-functional on many levels. The Scrum Master of this team is not able to coach the team why it is necessary to track progress on daily basis. The product owner does not care about development progress either.
To fix this situation the team should restart. Restart from scratch by training and do a retrospective to figure out why this is happening.
The team is probably doing some work, but maybe it does not update its progress accordingly. Another reason might be that the product owner has added the same amount of work that was already completed, therefore the line is straight.
The team is not able to predict the end of the sprint or even to provide the status of the current sprint.
The Scrum Master should improve it Scrum masterships and coach the team on why it is necessary to track the progress and how to track it.
Such team should be stopped after two or three days that shows a flat the line of progress and should immediately apply corrective actions.
The team with such progress has a problem. The problem is either the team committed to less than they are able to complete or the product owner does not provide enough stories for the sprint.
The reason might be also an over-estimation of complexity, which ends up in completion earlier than expected at the beginning of the sprint.
The Scrum Master should identify this problem earlier and ask the product owner to provide the team with more work. Even if stories are over-estimated, the team should at least continue with stories from the next, already preplanned, sprint.
This is a typical progress that can be observed in many experienced agile teams.
The chart says again that the team was able to complete their commitment on time. They adapted the scope or worked harder to complete the sprint. The team is self-reflecting.
The team should discuss change of plan immediately as they see the progress has been slowing down from the beginning of the sprint. Typically it is suggested to move a low priority item from the sprint backlog to the next sprint or back to the product backlog.
Such progress might be observed on charts of experienced teams. The team has completed work on time and met the sprint goal. They also have applied the principle of getting things done, but the most important is they have adapted a scope of the sprint backlog to complete the sprint. At the end the team has a possibility to complete some additional work.
In the retrospective, the team should discuss the reasons of late progress in the first half of the sprint and solve issues so they are better in the next sprint. The team should also consider the capacity that they are able to complete.
Such diagram indicates the great team able to organize itself. It indicates a great product ownerwho understands the reason for a locked sprint backlog and a great Scrum master able to help the team. The team is not over-committing and finished the spring backlog on time. The team is also able to estimate capacity correctly. No corrective action is necessary in such case.