Re: [Scrum] burndown chart - "remaining tasks" and "remaining effort" different?

[John Miller]

I think too many have been burned by the burndown ...could not resist : )

Thank You,

John 

Sent from my iPhone. It likes to sabotage my grammar. 

On Jul 4, 2012, at 12:06 PM, Mark Levison <ma...@mlevison.com> wrote:

On Wed, Jul 4, 2012 at 2:54 PM, John Miller <agiles...@gmail.com> wrote:

Mark,

It is all about the team understanding of the purpose of the measurement tool and then using it accordingly.

I believe the scenario presented is a false dichotomy.

Another option is for Team 3 to use the burndown as intended, not be managed by the burndown chart or to force them to alter their behavior to the "ideal line". To use it as an indicator if the team is on track and is focused. To be able to use make visible clues about performance issues in the team.  I have seen teams use it to help them realize they were pushing all the documentation and testing towards the end of the sprint, which led them to more Agile testing and documentation methods, increasing their quality. I have also seen teams use it as a guide for a sustainable pace in a Sprint and to help the team with their focus.

It all comes back to my earlier point. I find the Sprint burndown puts the focus in the wrong place - the reduction of the number of estimated task hours. For teams that feel they will still gain value I suggest that they just count the number of stories (not their sizes) in Not Started, In Progress and Accepted each day. That at least moves the focus from task hours to stories complete. Note I don't recommend this pattern its just better than tracking hours.

My experience and yours aren't the same, I appreciate that others find value in Sprint Burndown's where I don't. I'm not even sure if I'm in the majority with my experience. I've just seen too much damage done in their name to be happy with them anymore.

Cheers

Mark 

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.

[Ron Jeffries]

Hi John,

On Wednesday, July 4, 2012, John Miller wrote:

Mark,

It is all about the team understanding of the purpose of the measurement tool and then using it accordingly.

I believe the scenario presented is a false dichotomy.

Another option is for Team 3 to use the burndown as intended, not be managed by the burndown chart or to force them to alter their behavior to the "ideal line". To use it as an indicator if the team is on track and is focused. To be able to use make visible clues about performance issues in the team.  I have seen teams use it to help them realize they were pushing all the documentation and testing towards the end of the sprint, which led them to more Agile testing and documentation methods, increasing their quality. I have also seen teams use it as a guide for a sustainable pace in a Sprint and to help the team with their focus.

Please explain how the burn down shows that testing, say, is pushed to the end. The burn down does not identify what kinds of things are done vs not done.

Thanks,

Ron 

--
Darn. If I use gMail, I'll lose all those cool sigs. What shall I do?

Ron Jeffries
www.XProgramming.com

[John Miller]

Ron, 

It do not show it explicitly. It provided a visible clue that helped the team realize they were pushing it to the end. 

Thank You,

John 

Sent from my iPhone. It likes to sabotage my grammar. 

--

[Mark Levison]

Ron, John and Andrew - shouldn't you both be checking out the rocket's red glare on this fine summer's day. Let us Canuck's hold fort for 24hrs it will still be here when you get back.

Cheers

Mark

[Ron Jeffries]

On Wednesday, July 4, 2012, John Miller wrote:

Ron, 

It do not show it explicitly. It provided a visible clue that helped the team realize they were pushing it to the end. 

Kind of like a task board would have shown explicitly?

:)

[John Miller]

Ron,

I am bot arguing against your point. I am, perhaps poorly, attempting to make a case that burn downs can be useful to some teams sometimes. Burn downs are not evil, just misunderstood. Happy Independence Day!

Thank You,

John 

Sent from my iPhone. It likes to sabotage my grammar. 

--

[RonJeffries]

On Jul 4, 2012, at 3:38 PM, John Miller wrote:

I am bot arguing against your point. I am, perhaps poorly, attempting to make a case that burn downs can be useful to some teams sometimes. Burn downs are not evil, just misunderstood.

Yes they can be useful ... and a task board is group maintained and makes more info visible.

I wonder if they are a Generally Accepted Scrum Practice yet. Getting close I should think ...

Ron Jeffries

www.XProgramming.com

Impossible is not a fact. It is an opinion.  -- Muhammad Ali

[John Miller]

Task Board > Burndown
Does not equal
Never Use Burndown.

I feel we are going in circles here and I will tap out due to mere attrition.

[RonJeffries]

John,

On Jul 4, 2012, at 9:09 PM, John Miller wrote:

Task Board > Burndown
Does not equal
Never Use Burndown.

I feel we are going in circles here and I will tap out due to mere attrition.

Well, that's too bad. I was about to ask:

When, then, would you recommend a burndown instead of a task board?

When would you recommend using both?

When would you recommend using just the task board?

And why?

Ron Jeffries

www.XProgramming.com

I'm really pissed off by what people are passing off as "agile" these days.

You may have a red car, but that does not make it a Ferrari.

  -- Steve Hayes

[George Dinwiddie]

Ron,

I would also add another question.

On 7/4/12 10:05 PM, RonJeffries wrote:
> John,
>
> On Jul 4, 2012, at 9:09 PM, John Miller wrote:
>

>> *Task Board > Burndown
>> Does not equal
>> Never Use Burndown.*
>> *
>> *
>> *I feel we are going in circles here and I will tap out due to mere
>> attrition.*

>
> Well, that's too bad. I was about to ask:
>
> When, then, would you recommend a burndown instead of a task board?
> When would you recommend using both?
> When would you recommend using just the task board?

What would you recommend measuring on the Y axis of the burndown.

> And why?
>
> Ron Jeffries

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Kurt Häusler]

Hi,
they don't share the same unit.

Tasks is a simple count of how many tasks.
Effort adds up the, in this case hours remaining, on each card. So not the same unit. The vertical axis on the right indicates the count of remaining tasks.

Also to my eyes they seem to correlate fairly well.

I think reestimating all tasks in hours and adding them up is wasteful. I think if you try and keep all tasks appropriately small a simple count is quick enough for the purposes of a burndown.

Cheers,

Kurt

On Jul 2, 2012, at 1:56 AM, dotnetguy wrote:

> Hello - Wikipedia has the following example pic of a burndown chart:
> http://tinyurl.com/7gfbexv. I'm curious about 2 particular
> measurement lines in this pic:
>
> * Remaining Tasks
> * Remaining Effort
>
> The burndown chart in this pic shows these 2 measurement lines
> decreasing together but not with a very strong direct correlation.
> Can someone explain how these 2 measurements are different and why
> there's not necessarily a strong direct correlation between these 2
> measurement lines? Both of these measurements share the same unit -
> story points or hours.....

[dotnetguy]

[dotnetguy]

[George Dinwiddie]

Andrew,

Some tasks are estimated to take longer than other tasks. That's why the
hours estimated remaining and the number of tasks estimated remaining do
not track very well.

BTW, there are a number of things in that burndown chart that I would
recommend against. I wouldn't use it as an example of the goal state of
a burndown chart.

[RonJeffries]

Hi George,

On Jul 3, 2012, at 1:46 PM, George Dinwiddie wrote:

BTW, there are a number of things in that burndown chart that I would recommend against. I wouldn't use it as an example of the goal state of a burndown chart.

I don't recommend burn charts at all. Task boards are much more informative IMO.

[John Miller]

I recommend it be optional for a team. I have had some teams use it, as, they felt it provided them focus and to stay on track. Others found it to be overhead, and often, management would use it as for reporting progress, which, is not what it is meant for. I, of course, agree with Ron, look at the task board. What will a burnown chart provide you that will help the team move forward?

[Mark Levison]

Like Ron I've long since recommended teams stop using sprint burndown charts. These charts tend to encourage people to focus on the number of task hours which leads to tackling large tasks. I place my focus on the completion of Stories/Features. With Sprint Burndowns many people try to create an "ideal" burndown, when focusing on this ideal takes away from the delivery of value.

Like Ron I focus on the flow of the Story/Task wall. 

I smell a very long blog post coming soon.

Cheers

Mark

[George Dinwiddie]

Ron,

On 7/3/12 1:49 PM, RonJeffries wrote:
> Hi George,
>
> On Jul 3, 2012, at 1:46 PM, George Dinwiddie wrote:
>
>> BTW, there are a number of things in that burndown chart that I would
>> recommend against. I wouldn't use it as an example of the goal state
>> of a burndown chart.
>
> I don't recommend burn charts at all. Task boards are much more
> informative IMO.

Yes, but the Wikipedia burn down chart is, in my opinion, a poor example
of a burn down chart. It highlights the wrong things and ignores better
things. If people are going to use a burn down to summarize the task
board over time, they should make a more useful burn down than that.

[George Dinwiddie]

Mark,

On 7/3/12 2:20 PM, Mark Levison wrote:
> Like Ron I've long since recommended teams stop using sprint burndown
> charts. These charts tend to encourage people to focus on the number of
> task hours which leads to tackling large tasks. I place my focus on the
> completion of Stories/Features. With Sprint Burndowns many people try to
> create an "ideal" burndown, when focusing on this ideal takes away from
> the delivery of value.

Yes, absolutely. If I'm going to create a burndown, I want to measure
something reliable (e.g., Stories/Features) rather than something
estimated. And I object strongly to the rhumb line being called an
"ideal" line. As I say in
http://idiacomputing.com/pub/BetterSoftware-BurnCharts.pdf a burn down
that follows this line is an indicator of cooked books, not perfect
execution.

> Like Ron I focus on the flow of the Story/Task wall.

Yes, though a burn down (or burn up) can help some people visualize that
flow over time. For others, it's a waste and a distraction. And a poorly
executed burn down is misleading.

[Mark Levison]

On Tue, Jul 3, 2012 at 2:33 PM, George Dinwiddie <li...@idiacomputing.com> wrote:

Mark,

On 7/3/12 2:20 PM, Mark Levison wrote:

Like Ron I've long since recommended teams stop using sprint burndown
charts. These charts tend to encourage people to focus on the number of
task hours which leads to tackling large tasks. I place my focus on the
completion of Stories/Features. With Sprint Burndowns many people try to
create an "ideal" burndown, when focusing on this ideal takes away from
the delivery of value.

Yes, absolutely. If I'm going to create a burndown, I want to measure something reliable (e.g., Stories/Features) rather than something estimated. And I object strongly to the rhumb line being called an "ideal" line. As I say in http://idiacomputing.com/pub/BetterSoftware-BurnCharts.pdf a burn down that follows this line is an indicator of cooked books, not perfect execution.

Like Ron I focus on the flow of the Story/Task wall.

Yes, though a burn down (or burn up) can help some people visualize that flow over time. For others, it's a waste and a distraction. And a poorly executed burn down is misleading.

George - we're agreed, I would add only that find little value in watching the flow of stories Day over Day (i.e. at the Sprint Burndown level). Value seems to be accrued watching the flow in bigger chunks of time 3-5 days. YMMV

Cheers
Mark Levison

Mark Levison | Agile Pain Relief Consulting | Certified Scrum Trainings: Ottawa, Montreal
Agile Editor @ InfoQ | Blog | Twitter | Office: (613) 862-2538
ScrumMaster Tales: Impediments are holding back the team, Stop Digging New Holes

[Mark Levison]

On Tue, Jul 3, 2012 at 2:54 PM, Michael James <mj4s...@gmail.com> wrote:

Yeah, the Sprint Burndown Chart is one of those things that was useful in a particular environment but lends itself to so much abuse elsewhere that it seems better not to teach it at all.  If we *are* going to do one, let's please leave out the "ideal line" (a non-Scrum virus like "Sprint 0")!  It just encourages our self deceptive tendencies, pretending things are done when they're only "code complete."

Interesting my take during CSM classes is to draw it, discuss it and diss it. If we don't discuss many people bring it up anyway.

Cheers

Mark

 

--mj

http://ScrumTrainingSeries.com

[Michael James]

Yeah, the Sprint Burndown Chart is one of those things that was useful in a particular environment but lends itself to so much abuse elsewhere that it seems better not to teach it at all.  If we *are* going to do one, let's please leave out the "ideal line" (a non-Scrum virus like "Sprint 0")!  It just encourages our self deceptive tendencies, pretending things are done when they're only "code complete."

--mj

http://ScrumTrainingSeries.com

On Jul 3, 2012, at 11:20 AM, Mark Levison <ma...@mlevison.com> wrote:

[George Dinwiddie]

Mark,

On 7/3/12 2:53 PM, Mark Levison wrote:
>
>
> On Tue, Jul 3, 2012 at 2:54 PM, Michael James <mj4s...@gmail.com
> <mailto:mj4s...@gmail.com>> wrote:
>
> Yeah, the Sprint Burndown Chart is one of those things that was
> useful in a particular environment but lends itself to so much abuse
> elsewhere that it seems better not to teach it at all. If we *are*
> going to do one, let's please leave out the "ideal line" (a
> non-Scrum virus like "Sprint 0")! It just encourages our self
> deceptive tendencies, pretending things are done when they're only
> "code complete."
>
>
> Interesting my take during CSM classes is to draw it, discuss it and
> diss it. If we don't discuss many people bring it up anyway.

Agreed. And that is the reason I mentioned the problems with the one on
Wikipedia (and the reason I wrote my article on them for Better Software
http://idiacomputing.com/pub/BetterSoftware-BurnCharts.pdf)

[dotnetguy]

Thanks for all the feedback everyone. My initial post seemed like a
simple question. I had no idea it would generate so much
discussion :)

On Jul 3, 2:15 pm, George Dinwiddie <li...@iDIAcomputing.com> wrote:
> Mark,
>
> On 7/3/12 2:53 PM, Mark Levison wrote:
>
>
>
>
>
>
>
>
>
>
>
> > On Tue, Jul 3, 2012 at 2:54 PM, Michael James <mj4sc...@gmail.com
> > <mailto:mj4sc...@gmail.com>> wrote:
>
> >     Yeah, the Sprint Burndown Chart is one of those things that was
> >     useful in a particular environment but lends itself to so much abuse
> >     elsewhere that it seems better not to teach it at all.  If we *are*
> >     going to do one, let's please leave out the "ideal line" (a
> >     non-Scrum virus like "Sprint 0")!  It just encourages our self
> >     deceptive tendencies, pretending things are done when they're only
> >     "code complete."
>
> > Interesting my take during CSM classes is to draw it, discuss it and
> > diss it. If we don't discuss many people bring it up anyway.
>
> Agreed. And that is the reason I mentioned the problems with the one on

> Wikipedia (and the reason I wrote my article on them for Better Softwarehttp://idiacomputing.com/pub/BetterSoftware-BurnCharts.pdf)

[Mark Levison]

On Tue, Jul 3, 2012 at 3:55 PM, dotnetguy <andrew.d....@gmail.com> wrote:

Thanks for all the feedback everyone.  My initial post seemed like a
simple question.  I had no idea it would generate so much
discussion :)

Have you ever known myself, George and Ron to say 10 words what we could say in 1000 :-)

[RonJeffries]

Mark,

On Jul 3, 2012, at 3:58 PM, Mark Levison wrote:

Have you ever known myself, George and Ron to say 10 words what we could say in 1000 :-)

Never. :)

Ron Jeffries

www.XProgramming.com

I know we always like to say it'll be easier to do it now than it

will be to do it later. Not likely. I plan to be smarter later than

I am now, so I think it'll be just as easy later, maybe even easier.

Why pay now when we can pay later?

[dotnetguy]

To be honest - I like the burndown chart. People generally like visual
aids and I think the burndown chart provides a useful view of
iteration progress. I think when the burndown chart is updated at the
daily status meetings, the entire team can view progress and there are
fewer surprises at the end of the iteration.  This reduces the risk
that every day a team member might say everything is on track and then
on the last day report that nothing was completed. I think the
burndown chart also gives team members a goal to strive for, like a
game.

[Dan Rawsthorne]

Of course, the burndown defines progress as moving down to zero by the end of the sprint - highly predictive behavior. In my opinion, liking burndowns is a serious smell of non-agility. Just sayin'...

If you actually like to see progress made in a non-predictive way, use a buildup chart (I hate the term burnup, doesn't sound like progress to me)

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

[Mark Levison]

Imagine:

The team estimated 300 hrs of work over 6 User Stories or Features, 10 day sprint.

Scenario 1: day 7 - ~30 hrs of work remaining but no single story is complete. All stories are in progress. Would you bet on this team finishing much of anything before the end of the sprint? Personally I would bet against them.

Scenario 2: day 7 - ~60 hrs of  work remaining but 4 stories are complete, 1 story is in progress and 1 isn't started. This team won't finish the last story.

Which team would you rather be working with? Me I would go for two every time but, Sprint burndowns encourage Scenario #1, because its close to the "ideal" line.

[John Miller]

Mark,

It is all about the team understanding of the purpose of the measurement tool and then using it accordingly.

I believe the scenario presented is a false dichotomy.

Another option is for Team 3 to use the burndown as intended, not be managed by the burndown chart or to force them to alter their behavior to the "ideal line". To use it as an indicator if the team is on track and is focused. To be able to use make visible clues about performance issues in the team.  I have seen teams use it to help them realize they were pushing all the documentation and testing towards the end of the sprint, which led them to more Agile testing and documentation methods, increasing their quality. I have also seen teams use it as a guide for a sustainable pace in a Sprint and to help the team with their focus.

The burndown is indeed, misunderstood and abused. This does not mean it can not add value to an Agile team. It can be useful for teams, though, many teams do not need it.

Thanks,

John

[Mark Levison]

On Wed, Jul 4, 2012 at 2:54 PM, John Miller <agiles...@gmail.com> wrote:

Mark,

It is all about the team understanding of the purpose of the measurement tool and then using it accordingly.

I believe the scenario presented is a false dichotomy.

Another option is for Team 3 to use the burndown as intended, not be managed by the burndown chart or to force them to alter their behavior to the "ideal line". To use it as an indicator if the team is on track and is focused. To be able to use make visible clues about performance issues in the team.  I have seen teams use it to help them realize they were pushing all the documentation and testing towards the end of the sprint, which led them to more Agile testing and documentation methods, increasing their quality. I have also seen teams use it as a guide for a sustainable pace in a Sprint and to help the team with their focus.

It all comes back to my earlier point. I find the Sprint burndown puts the focus in the wrong place - the reduction of the number of estimated task hours. For teams that feel they will still gain value I suggest that they just count the number of stories (not their sizes) in Not Started, In Progress and Accepted each day. That at least moves the focus from task hours to stories complete. Note I don't recommend this pattern its just better than tracking hours.

My experience and yours aren't the same, I appreciate that others find value in Sprint Burndown's where I don't. I'm not even sure if I'm in the majority with my experience. I've just seen too much damage done in their name to be happy with them anymore.

Cheers

Mark