Burn-Down Chart Symptomatics
•Als PPTX, PDF herunterladen•
5 gefällt mir•4,497 views
by dmytro bibikov
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Ähnlich wie Burn-Down Chart Symptomatics
Ähnlich wie Burn-Down Chart Symptomatics (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Burn-Down Chart Symptomatics
- 1. Burn-Down Chart Symptomatycs • May 2015 • Dmytro Bibikov Thinking Session
- 3. 3 Where – Scrum Framework SDLC
- 4. 4 When – Iteration / Release
- 5. 5 Why – Keep Constraints on Track Iron Triangle
- 6. Interpreting
- 7. 7 What:
- 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 interpreting 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
- 10. 10 How Simple and Transperant
- 11. • Story Points 11 Measures of Effort • Items / Tasks • Hours / Ideal Days
- 12. Symptomatics
- 13. 13 No Comments… or ‘Simple Case’
- 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 What to improve? • Restart. From scratch, from training. Do retrospective to figure out why this is happening. 14 Do Your Duties!!!
- 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. What to improve? • Estimate stories/tasks immediately and update your backlog. • Do not forget to start sprint if you use electronic tool. 15 First Sprint in life – Up to the Sky
- 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. What to improve? • Stop the line after see line of 3 days as row. Initiate retrospective immediately. 17 Management is coming!
- 18. • 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. 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 18 Too Early / 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.
- 19. 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 What to improve? • Get additional stories as soon as possible form the next sprint according priorities. 19 Let’s have a rest team
- 20. 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 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. 20 Nice Team
- 21. 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 What to improve? • Grab additional stories from the next sprint you are able to complete in the sprint. 21 Great Team
- 22. 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 What to improve? • Just continue! 22 Ideal Team
- 23. • Scrum Team has Full Authority to admit need for change, define approach, apply solution… Knowledge is the key. 23 Conclusion and Inspiration
- 24. Thank you!
- 25. • http://www.methodsandtools.com/archive/scrumburndown.php • http://www.scrumdesk.com/is-it-your-burn-down-chart/ • http://www.mindtools.com/pages/article/newPPM_54.htm • http://www.ambysoft.com/essays/brokenTriangle.html • https://www.mountaingoatsoftware.com/agile/scrum/release- burndown • http://www.agilenutshell.com/burndown • http://www.clariostechnology.com/productivity/blog/burnupvsburnd ownchart • http://www.slideshare.net/MatthewWarton/burn-down-vs-burn-up- charts 25 References
Hinweis der Redaktion
- 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.