Burn down or burn up – which is best?

Well it kinda depends on what you want to show to your stakeholders:

Burn down charts are great for showing progress in a sprint.  you can show Work in Progress (WIP), the actual burn and the ideal burn.  These three will give stakeholders and team members a snapshot of where you are in your build.  You can use it to give focus to certain areas to close the gap between ‘actual’ and ‘ideal’.  Burn up charts show the amount of work remaining on a project and a projection of work completed based on the current velocity of the team.

Burn-down charts have the advantage that they’re simpler — they only show one line.  However if you can stand a little complexity then I’d recommend burn-up charts as the more useful option for release management and stakeholder management.

Burn Down Charts

A burn down chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. That is, it is a run chart of outstanding work. It is useful for predicting when all of the work will be completed.   The Scrum Master updates the values for WIP and actual burn after the daily standup.

Burndown

Burn Up Charts

A burn-up chart tracks how much work remains on your project and whether you’ll hit your deadline. The vertical axis measures work remaining. The horizontal axis marks your iterations, and you should mark which iteration is your target end date for the project. After each iteration you mark your progress on the chart and you can project forward to see whether or not you’ll hit your target end date.

burnup

 

You can make burn up charts more sophisticated, showing  several scope lines, one for each release milestone. This way the team and the stakeholders can see the effects of, say, moving scope from one release to another.

complexBurnUp

Advertisements

Story Points – How? Why?

Scrum tells us that it doesn’t matter what a story point is, only that it exists in some way.  Try explaining that to your stakeholders and see how long you last 🙂

Every stakeholder and product owner wants to know two things… “How much will it cost?” and “How long will it take..?” and no amount of wriggling will get you off the hook.

So for this you need to know a couple of things:
Total # of Story Points
Velocity

How big is a story point? And how do I know what the velocity is?

Think about something non technical, like digging dirt out of the garden…It’s an example that has been used time and time again I’m not sure who came up with it first but it works so well

If I was to move 100 kg of dirt at 10 kg per hour  it would take me 10 hours.

So that would equate to:

100 Story Points (100kg of dirt) / 10 Story Points per Sprint (Moving 10kg per hour) = 10 Sprints.

Therefore if we want to answer how long will it take to develop a particular software product, we:

Add up the story points, divide by the velocity, and that gives us the time.

In order to do this we will need to create a reference story for all of the other story points to be compared against.  So how do we establish our reference story? And how do we know what velocity is?

In a Scrum environment, estimates are supposed to be done by the whole team, those who will actually perform the work.  So the team defines what a story point is.

The suggested way of doing this is to consider the task list and state that the task that appears to be the easiest to perform is valued as 2.  All other tasks are estimated relative to this task.  However it doesn’t have to be the smallest task, just a task the whole team can agree too.

So what do you use?  The Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.), t-shirt sizes (XS, S, M, L, XL, XXL, XXXL) or anything that starts small and ends up large.  The most important thing here is that the team understands and responds to the values that are being used.

Ok now onto Velocity.  What is it? Where does it come from?  Here is another answer that the powers that be won’t like…In the first sprint, we guess. It’s all about gut feeling, after a few sprints things will become clearer.

After each sprint the velocity is measured, after one or two sprints we have an average that we can use for predicting sprints in the future.  From this we can estimate the completion date.  With a little bit of thinking we can calculate values such as £/Story Points which can be used to estimate project costs.

The important word here is estimate!  It’s not definitive or fixed.

It is worth remembering that Story points can create a lot of vagueness within the agile process.  For every team, story size could mean different things depending on what baseline they chose, so you can’t cross estimate teams.  If two teams are given the same stories one team can say their velocity is 35 and the other 12 dependant on what numbers they choose.

If you use Story points in this way the Scrum Release Burn Down Chart can provide a fairly accurate picture of the progress of the project, and this will give the management a good overview of the projects progress, or lack of progress.