4

The burn down chart will have story points on the Y-Axis and duration (number of days) on the X-Axis. My team is able to complete the stories almost at the end of the Sprint. This means the burn down chart is never linear in relation to the 'ideal working line.' Instead, the actual working line suddenly dips towards the ideal working line almost on the last day of the Sprint.

As a Scrum Master, I am unable to predict if the stories are progressing and getting completed as expected. I read that with the burn-down chart the team is burning hours and the tracking will be based on hours and not story points.

With story points on the Y-Axis and duration (number of days) on the X-Axis, how do I track hours? Secondly, how should I follow the process to make sure that the ideal line and actual line are symmetrical, or close to symmetrical?

12

TL;DR

As a Scrum Master, I am unable to predict if the stories are progressing and getting completed as expected. I read that with the burn-down chart the team is burning hours and the tracking will be based on hours and not story points.

The burn-down chart is the wrong tool for measuring progress. The correct tools would be:

  1. The daily stand-up, which you should be facilitating, where progress and blockers are coordinated among the Development Team.
  2. The Sprint Backlog, which can be used to track both stories and tasks for the current Sprint.
  3. The Kanban board, if your team happens to use one, which will visually identify where certain stories have gotten stuck.

The burn-down chart measures work remaining, but in your case it's unlikely to be useful as anything other than a visual warning that the team is only closing stories at the very end of the Sprint. If you didn't know that, then that's useful information. If you already knew that, then the burn-down chart is tangible evidence that you can present to the Scrum Team that there's a process problem that needs to be addressed.

Burn-Down Charts and Plateaus

My team is able to complete the stories almost at the end of the Sprint. This means the burn down chart is never linear in relation to the 'ideal working line.' Instead, the actual working line suddenly dips towards the ideal working line almost on the last day of the Sprint.

Whether you measure in ideal hours or story points, a burn-down chart should measure work remaining for the Sprint, not work in progress or effort expended. As a result, short plateaus and rapid dips are fairly common in burn-down charts. Since stories are either done or not-done, stories that are in-progress may cause a plateau (or even as a rising line as new tasks are discovered) until the story meets the Definition of Done. Once the story is done, there will be a sudden dip in the burn-down chart as the story or ideal hours are removed from the amount of work remaining for the Sprint.

If your burn-down only moves downwards at the very end of your Sprint, then it's likely that:

  • Your stories are too large.
  • Your stories are too interdependent.
  • Your work-in-progress (WIP) limits are too high.
  • You have some other process bottleneck that's preventing a reasonable cadence of task completion throughout the length of the iteration.

Last-minute integration tasks or mass story completions are generally a project smell indicating a fundamental process problem. Your team should carefully review your estimation and workflow practices during an upcoming Sprint Retrospective.

Understanding the Burn-Down Chart

[H]ow should I follow the process to make sure that the ideal line and actual line are symmetrical or if not close to symmetrical?

The goal of a burn-down chart is not to make the lines symmetrical. The goal of a burn-down chart is to act as an early-warning system, warning the team that there are unidentified blockers or hidden process problems where actual delivery is being skewed away from the original estimate beyond what might be considered reasonable deviation.

For example, a common rule of thumb in Scrum is that a single story should take between one-half and two days to complete. If your burn-down has plateaued for several days during the Sprint, but no one has raised any blockers during the daily stand-up, then you likely have a hidden process problem that the team needs to uncover.

  • 6
    Excellent answer but I would add that a burn down chart is only useful if participants actually make entries for story points and hour estimates, and then actually update them. Nobody in our agile team enters or updates those numbers and therefore our burndown chart is a trainwreck. That sounds like what the author is facing. – user3120173 Dec 20 '14 at 20:40
  • @user thats why the team only estimates time left. This is quite different from an estimate of effort (for which an update is like a "progress bar"). The estimated time left is a quantity that can also increase with the days. – Sklivvz Dec 20 '14 at 22:30
  • user3120173 - you are correct that the team is also not filling the hours on a day to day basis. Hence, i thought burn down chart not giving me value. Should that be consider a a process problem and chase the team to fill the time? – ramu Dec 21 '14 at 18:28
  • @ramu Instead of chasing the team try showing them the value of accurate tracking. – Alex Leonov Dec 21 '14 at 19:20
  • 1
    Great answer CG. Fantastic final insight in the final line. – Venture2099 Dec 23 '14 at 11:08
2

Burndown is not a great tool for tracking work progress during an iteration. Unless you have a ton of really small/granular stories and the team is good at continuous integration your burndown will look more like a staircase with 2-3 large steps.

You could create a task based burndown with days on the X axis and Hours on the Y axis, but honestly hour estimates for most teams do not reflect the actual progress towards getting the story done (people inflate values, forget tasks, and don't update their tracking tool regularly). Getting and keeping tasks accurate for many teams creates more overhead than the value it brings.

In scrum the simple ways to determine iteration progress are through daily standup and the kanban or story board.

Standup is a qualitative way of assessing iteration progress. Good team member communication and transparency are the key. Experienced scrum masters can tell from standup alone roughly where the team is, which stories are at risk, and if the team is over or under capacity.

The story or kanban board can help visualize the progression of work and is a more quantitative tool for understanding iteration progression. If your board tracks cycle time on the story or defect and the same has a story point estimate it is easy to determine the rough progress of a story. While story points don't equal time, there is a strong correlation between the complexity (Story points) of a story and the median, mean, or mode number of days that sized story takes to complete.

Take for example a 3 point story (assume the team defines this as an "easy/small" story). If you look at the distribution of days it takes to complete 3 point stories for this hypothetical team you will find that ~90% of their 3 point stories are completed in the 3-5 day range. So if you see a 3 point story on your board that has now be in progress for 3-4 days its fairly safe to assume the team is should be wrapping it up. If it hits the 5 day mark, you may want to start diving deeper into the progression of story and see if there are concerns/blockers that are not being communicated during standup.

  • +1 regarding the best use of communication and daily stand ups. Regarding Burndown, our team made the collective switch to a User Story Burndown which works well for us as we have a number of non-Scrum dependencies so as we move away from the predicted Burndown we can batter management with it to say.."See, dependencies are holding us up." – Venture2099 Dec 23 '14 at 11:06
0

CodeGnome already clarified precisely what is a burn-down chart and that is not the best tool for tracking progress (it's instead useful for the team itself and to show to the stakeholders that the team is in control).

I do not think is a process problem but probably the wrong tool (using hours or story points doesn't matter). If you would like to track the progress you could improve the daily meeting and maybe having more conversations / discussions. If you would like to improve the estimations you can try with other tools, for example a kanban board associated with smaller and independent tasks and possibly some simple automatic tracking calculation (i.e., it starts when moving into "progress" and stops when moving into "ready for test" or whatever statuses you would put in place.

Note: my suggestion is feel free to experiment (an agile principle is to inspect and adapt your own own process), unless you are applying / want to apply Scrum exactly as prescribed.

-2

In the interests of trying to provide a good answer to the question, I've rewritten my original answer to both better explain it and to address a number of the points in the comments:

Firstly, a quick overview of agile ideas and methodologies, to set the stage for the answer. There are two important rules to agile development that everyone should know and remind themselves of regularly. Combined they can save a lot of misunderstanding and misinformation:

  1. Agile is an adjective; not a noun. If someone says "We do agile", or "Agile is ..." then they have misunderstood the whole idea of agile development. Agile isn't a thing, any more than rapid in Rapid Application Development (RAD) is a thing. A good rule of thumb for determining if you are using the word correctly is to swap it for "nimble". "We do nimble" sounds silly; so this tells us "We do agile" is a bad use of the word. "Nimble is a mindset" sounds silly; this tells us the "Agile is a mindset" is also a bad use of the word. "We have adopted a set of nimble processes" and "we are a nimble development team" both make sense, which tells us these are good ways of using the word agile.
  2. One of the key principles of agile development is "Individuals and interactions over processes and tools". In other words, put what works for you at a given time before all dogma, "best practice" (a poisoned chalice of a phrase, if there ever was one) or any real or imagined rule of how to take an agile approach to development. If you come across someone saying "story points are only for stories, thus the name" or "Story points and ideal hours are not interchangeable" then they have forgotten this core principle and are putting process before people. If you want to measure stories in hours, tasks in elephants etc, then do so. If anyone tells you you are doing it wrong, point them to the agile manifesto and politely ask them they are advising you badly. There's an excellent article on real & ideal hours and story points at http://vladhorby.wordpress.com/2007/09/04/agile-adventures-ideal-vs-real-time/, which is well worth a read.

So back to my original answer, which I have rewritten to clarify what I was trying to advise; it was clearly badly phrased initially as it confused a number of people.

The scenario described is of a situation where a team has estimated a set of stories and these are being assigned to each sprint in turn. However, due to the duration of each story been similar to the length of the sprint, the scrum master's job of tracking progress is made difficult. Scrum guidelines suggest that a activity only be marked down on the burndown once it is done. Thus, the progress line flat-lines until the end of the sprint, before plummeting as the stories finish.

The simple reason why this happens is because the activities aren't granular enough. A solution to this is to take each story and decompose it into tasks during the sprint planning meeting. that way, each task reaches done more quickly and so can be marked down on the burndown chart. Thus progress is more accurately recorded.

Whilst it might be tempting to estimate the tasks in hours (or days) during the sprint planning meeting, there is an alternative approach that can provide valuable information to the scrum master on the the velocity that the team is achieving. That alternative approach is to estimate the tasks in story points (or "bolitas" - see the link above) too. These remain arbitrary amounts. Though some teams choose to equate a story point with an idealised "man day", this isn't universal or even necessary for some teams. As always with agile development, do what works best for your team. If you estimate tasks in story points, and record the hours spent, you can obtain hours spent vs estimated story points metrics. This can form a good way of determining the team’s velocity and estimating accuracy. These figures can then help inform discussions around improving estimating in the retrospective and in giving more reliable real duration estimates of story points in the future.

Addendum I have been asked by "Venture2099" to expand upon what "Individuals and interactions over processes and tools" actually means in practice. What this means in the real world was superbly expressed up by a talk at QCon London in 2013 by Glen Ford. The slides are available at http://qconlondon.com/london-2013/qconlondon.com/dl/qcon-london-2013/slides/GlenFord_PeopleOverProcessApplyingItInRealWorldSoftwareDevelopment.pdf, but without the video, they likely lack enough words to fully get the message across. However, the following quote superbly sums it up:

"Process is not the rule of law. Rather it is a set of concepts in which to frame the interaction between individuals in order to facilitate the efficient generation of value. The advantage of quality interactions is you decrease the reliance on process. Encourage quality interactions".

In a manufacturing environment for example, one needs strict processes. However, in a creative exploration of the unknown, which typifies software development, they are largely a hindrance. Unless those processes are agile themselves. The most agile of process is one that grows out of good inter-relationships between a team of people that want to do the best job they can and are empowered to do so.

All agile methodologies should embrace the "people before processes" ideal by offering guidelines, rather than rules. Rules beget inflexible processes and a belief in some that there is "one true way" of "doing agile". That's why it's always important to remember the "people before processes" idea when insisting that an agile method must be implemented in a certain way or before talking of agile "best practice" and the like. Such behaviour undermines a fundamental principle of agile development.

  • 2
    Tasks don't get story pointed, hence the reason why its called a story point. Tasks are hour estimated if a scrum team chooses to use tasking. – WBW Dec 19 '14 at 19:02
  • 2
    Uhh there are so many things wrong with the above statement I don't know where to start... – WBW Dec 20 '14 at 5:30
  • 1
    A sprint can contain many stories. A burn down is a burndown of stories over an iteration, quarter, release cycle, or whatever reporting interval you choose in the scrum world.. A scrum sprint or iteration is a fixed, reoccurring interval of time. Velocity should not be used to determine the duration of the iteration; it should be used to determine what can be achieved in a fixed time interval. Epic and story estimates hardly ever relate because they are different scales of sizing efforts. Epics are broken down into stories so that they CAN be story pointed. Tasks are not story pointed. – WBW Dec 20 '14 at 5:49
  • 1
    Hi David, your statements are incorrect. Please consider visiting some of these public resources about Scrum: – WBW Dec 20 '14 at 18:56
  • 1
    Technically, a sprint contains "backlogs" that are story pointed by the team. Its not uncommon to refer to these backlogs as stories or tasks. Additionally, there is nothing wrong with relating some Kanban principles to Scrum. In many Agile-Scrum implementations it is common practice to borrow certain concepts from Kanban. This may include the use of a Scrum "story" board or "task" board which borrow concepts from the traditional Kanban board. – WBW Dec 20 '14 at 19:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.