Danube - Reasons to Disable Your Tool's Estimates vs. Actuals, Ideal Line, and Individual Burndown Charts - Comments

more discussions of team performance vs. individual performance

MichaelJames — Wed, 07 Jan 2009 19:16:00 -0600

Observations from George Dinwiddie and Esther Derby:

http://groups.yahoo.com/group/scrumdevelopment/message/35687

http://blog.gdinwiddie.com/2008/12/21/working-hard-or-hardly-working/

--mj

Ron Jeffries weighs in

MichaelJames — Tue, 12 Aug 2008 09:05:35 -0500

[reposted from http://groups.yahoo.com/group/scrumdevelopment/message/31661 by mj]

Re: [scrumdevelopment] Per Person Burndown Poll Doesn't Make Sense

Hello, captwilco2002. On Monday, August 11, 2008, at 12:11:21 PM,
you wrote:

> 1. Why doesn't the poll make sense?

Because ...
... per person tracking is counter-productive;
... per person tracking does not collect useful data;
... burndown is measured in things done, not time spent;
... people don't burn things down, teams do.

> 2. Do you think I should be tracking this?

No. Not remotely.

> 3. About how many hours can be expected for an individual to burndown
> in one day (on average)? (Not what is a reasonable number of hours to
> expect each person to burndown on a daily basis, hence the purpose of
> my poll)

What is the difference between an average number that can be
expected, and a reasonable number to expect?

But never mind. Tracking individual hours of anything will break
Scrum, or any other process.

Ron Jeffries
www.XProgramming.com
I once had a coworker who worked so hard that when I came in the
morning, he was already sitting there trying to fix the things he
broke after I left the day before ... -- Ilja Preuss.

Brian

MichaelJames — Thu, 19 Jun 2008 17:26:32 -0500

Brian,

I can see why you might want to do that, especially for a longer Sprint, or in cases the work does fit the more predictable pattern. Another cool idea might be to show "ghost lines" from the team's previous Sprints.

ScrumWorks Pro is released several times per year. Feature requests can be submitted to Victor Szalvay (ScrumWorks Product Owner) here:
http://forums.danube.com/viewforum.php?f=4

--mj

Trendline

BrianBurdick — Wed, 18 Jun 2008 01:10:06 -0500

HI Michael,

I understand your points regarding anchoring, the non-linear nature of sprint progress, etc. I Still like to see the trendline for some kind of visual reference. I find myseful imagining the trend line anyway. I don't get to stressed out if I am way above it in the first half of the sprint. I would kindly ask that you at least make it an option - even if by default it is off. Also - it seems with the data that you have from previous sprints in each organization, that you could create an ideal curve based on the curves of previously completed sprints for the organization - a kind of best fit average burndown curve. This might more accurately reflect progress. It seems the data is already there in the product burndown - it just needs to be used per sprint as a curve.

Willi

MichaelJames — Sat, 07 Jun 2008 13:30:56 -0500

I agree the customer deserves the best information we can give about long term predictions. I describe an approach I've actually seen work (because it's based on empirical measurements) here:
http://danube.com/whitepaper/macro-measurements

For a more thorough treatment, I suggest Mike Cohn's book _Agile Estimation and Planning_. ScrumWorks was designed to support these practices, which are becoming standard approaches.

The chaos and unpredictability at the micro level does seem to smooth out at the macro level, kind of how objects move randomly under a microscope but move predictably when we zoom out.

--mj

Question

Willi — Sat, 07 Jun 2008 08:42:24 -0500

So, Michael,

What can we do when the customer asks for long term estimates for finishing the project?

We just say it's unpredictable?

That's gonna be hard to sell.

Despite agreeing with you that this is unpredictable, we also should see the customer's side.

Willi

Reasons to Disable Your Tool's Estimates vs. Actuals, Ideal Line, and Individual Burndown Charts

MichaelJames — Fri, 06 Jun 2008 03:08:52 -0500

Organizations that are looking for an automated tool to help manage Scrum fall along a continuum.

At one end are the Scrum purists, who feel that resistance to doing real Scrum is an organizational impediment to be exposed and rooted out rather than accommodated as business as usual. These folks believe the highest performance and ingenuity comes from intense collaboration, small cross-functional teams lacking defined roles, self organization, face to face communication, and even a certain amount of chaos during Sprint execution. They typically prefer lightweight tools that make the Scrum artifacts visible without impeding team self organization.
At the other end are those who want some version of the Scrum/Agile practices, but also feel "traditional" practices (such as Taylorism, waterfall, or parts of the PMBOK) would meet their current needs. They may be dealing with impediments to self organization, lack of co-location, suboptimal team composition, large departments, entrenched practices, regulatory requirements, etc. Or they may not be in a position to wait for teams to go through the "forming, storming, norming, performing" growth stages. These folks tend to request features that make the purists cringe.
Some are in organizations that are transitioning from traditional practices to Scrum. Some skeptics I've known became full-fledged advocates after seeing results from pilot teams attempting uncompromised Scrum with good coaching.