(Edit: 17 th august 2009 recap of this post) In this article, you’ll find links to download my burn down/up graphs as xls-sheets also containing formulas for analysis of a given iteration/sprint. It’s been developed in an agile matter, continuously adding new features and improvements as the feature requests and demands arrived.
Measuring performance is important. It helps you keep focus and improve. However, most such measurement methods of productivity, efficiency, story point delivery and so, are destroyed by the very same people requesting them. Say you’re breaking down user stories in to small deliverable tasks which you estimate in ideal hours. If you are measured directly by the numbers of hours you deliver, you’ll start increasing your estimates for each tasks, consciously or unconsciously. That is, the more you overestimate, the higher the reward. Ideally, you should be professional and don’t get affected by this, but that doesn’t fit in the real world. It’s plain and simple psychology.
- Why do we measure?
- What are measurements good for?
- What are my goals with the measurements?
To most, the number one reason is predictability! Having estimates on the size of the backlog and knowing the velocity of the teams eating away at the backlog is invaluable. It enables the product owner to plan and make better decisions.
Predictability stands tall as the reason to utilize a burn down and/or burn up. The other reasons are elements of agile engineering (AE) that are supported or enhanced by the information such measurements provide. Reflect and learn, improve and deliver!
I believe that all developers want to do they’re jobs as good as possible and be the best they can. If you’ve got waste in your process, such as dependencies to unstable legacy systems, this should be reflected in a bad factor (factor = hours worked / tasks delivered (in ideal hours) ). The worse thing you may do is to hide that waste in you’re estimates. However, you need processes to support this, to motivate the developers to continuously improve. Agile and it’s short feedback cycles with iterations and retrospectives is an excellent tool to support such improvements. In the retrospect every team member writes down what he or she feels went good or bad, what’s good practices and so on. Over time (several sprints) the sprint burn down will stabilize and predictability is achieved.
Right… Understand that you may do more harm than good if you’re adapting a technique without understanding the whys.
Finally, here’s examples of both a burn down and a burn up from a completed sprint. (Click twice on the images to view it full-screen)
Preview the xls sheet through the browser http://blog.omaconsulting.no/BurnDown/burndown.htm
To facilitate such smooth burn down graphs, these are keywords:
- many user stories
- able to scope in and out story
- deliverable user stories
- clearly defined DoD (definition of done)
- deliverable tasks
- good enough
- tasks estimated in ideal hours
- minimize the number of variables. Estimate the task only!
- T-shirt sizing tasks(xs, s, m, l) or the “twice as big as” 1,2,4,8
- color themes for tasks or something to visualize unplanned tasks
- planned (those tasks created at sprint planning)
- unplanned (unthoughtof tasks needed to complete a story)
The xls sheet you may find here at omaconsulting.no
Description of the data table to populate the graphs
- First row, the sum of planned tasks.
- Second row, accumulated unplanned tasks. Subtract scoped out or wrongly planned tasks.
- Third row. Delivered tasks. Count them before the daily stand-up for discussion.
- Forth row. Formula showing the remaining task hours to be delivered.
There’s a lot more to the xls sheets. I haven’t provided much explanations or descriptions. I hope to write more later. Ask me if you’ve got questions!
Personal note on the end of this generous post
A good manager, PL or scrum master steps back, encourages the team members to take point, come up with ideas and other initiatives. Sort of like a coach (in business terms). A coachs’ job isn’t come up with the solution, it’s to ask questions so that the client empirically comes to his own understanding. Reflect upon it!