To me the assumption there's an "ideal burndown" is something left
over from traditional project management where all the scope -- and
all the tasks to get them done -- are presumed to be known in the
As George Dinwiddie recently wrote, many of us prefer release burnup
(or down) charts that show the rate of PBIs completed vs. the rate of
new PBIs discovered. This can clarify the extent the deviation from
the original expectation is related to new scope discovery vs.
observed velocity slower than someone's original expectation.
After collecting enough empirical data, Product Owners can have more
realistic expectations what to expect by a given date and make more
informed prioritization decisions.
BTW, you may have noticed I think Product Owners should focus on PBIs
done (rather than tasks) when making business decisions.
. Michael James | http://danube.com
. 5-page illustrated summary of Scrum: http://tinyurl.com/dkyqjs
. An example checklist for serious ScrumMasters: http://tinyurl.com/cvdwor
On Apr 26, 2009, at 6:09 AM, Ron Jeffries wrote:
> Hello, brian_bofu. On Saturday, April 25, 2009, at 10:46:59 PM,
> you wrote:
>> My question is, do we need to update (re-draw) the "ideal
>> burndown" to follow the trend of actual burndown line at the end
>> of each Sprint? As the original "ideal burndown" already out of
>> date and make no sense for comparison any more. It's like re-
>> baseline in CMM world.
>> what do you guys think about it?
> What value is the ideal burndown providing you? What would you lose
> if you erased it the first time you put up a data point?
> Ron Jeffries
> And thirdly, the Code is more what you'd call guidelines than actual
> -- Barbossa
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
> ! Groups Links