Re: Do you count weekends in your burn down chart?
- Hi Dan,
You're right! I don't like any metrics being performed at the sprint
task level, especially one like this that tries to extrapolate whether
a team will be done with their sprint work.
One of the ways Scrum/Agile differentiates from traditional project
management is a focus on what I'll call "macro" metrics instead of
"micro" metrics. Focusing metrics at the micro (or task) level causes
a variety of problems in Scrum teams. There is the principle that
"you get what you measure", and if your metric is sub-optimum then
teams will start performing to this sub-optimum metric. So the
question is "in Agile/Scrum, what would be the best metric"? Most
Agilists believe that metric to be the rate at which the product is
actually produced (velocity). That's why in Scrum the team should be
measured by whether or not they meet sprint goals (think product
backlog item level or higher) since the sprint goals should always
represent tangible progress on the product. I call these measurements
Velocity is not measured at the task level, it is a "once a sprint"
data point that comes from the sprint review. If the product owner
believes the committed product backlog items are done, then the team
gets "credit" for those items in terms of velocity.
The burndown chart and trend I believe Ron Jeffries is referring to in
his post is actually a "release burndown chart" (Ron, correct me if
I'm wrong here!). This tracks the rate at which actual work
increments are being done by the team, new work is being added to the
backlog, etc. I do like this metric because it encourages behavior
that is optimized for the real goal product development.
Check out Mike Cohn's new book on Agile Estimating and Planning for
more on this.
Hope this helps,
-- Victor Szalvay
Danube Technologies, Inc.
--- In email@example.com, "Dan Pierce" <dan.pierce@...>
> It seems to me that all of your comments apply to all measurements
> and metrics everywhere in every field. The many gauges on a race
> car (or the space shuttle for that matter) can hide vital truths
> about what is "really" going on. The Dow Jones' many indexes are
> constantly debated for their "true" meanings. Doctors caution other
> doctors against "treating the numbers", etc.
> All metrics are distortions and abstractions but that does not mean
> they are not useful. It just means we have to be vigilent about
> what they can show and what they can hide.
> Dan Pierce
> --- In firstname.lastname@example.org, "Victor Szalvay"
> <victor@> wrote:
> > Actually I've never had much use for a sprint burndown trendline at
> > all. They can be dubious and misleading themselves because only
> > team has any real sense for how things are going based the
> > facts of the sprint. The sprint burndown is there just as a
> > of that history, but it is not conclusive by itself to anyone
> > the team.
> > To illustrate this with an example, consider a team that is stuck
> by a
> > bug or impediment and the sprint burndown curve is "hung up". If
> > extrapolate a trend the team clearly won't make the sprint.
> > the team knows that they are on the verge of a breakthrough and
> > that happens they will be able to finish in time. In this case,
> > does the trendline do for you? At worst, it may cause tension
> > the SM/PO and the team because no one but the team members can
> > understand why the team thinks they will still make it on time.
> > The opposite scenario also supports this. Consider a team whose
> > looks like they will easily finish but they know they've been
> > off a high risk section of the sprint work that may spell disaster
> > the sprint goals. In this case, a trendline lulls everyone into a
> > feeling of safety; however, the team knows this is not reality.
> > I guess what I'm saying is that the sprint burndown chart is
> > without being part of the team and knowing exactly why it trends
> > way it does (or went up before it went down and then went back up
> > again). The sprint burndown is a tool for the team to remind
> > where it stands as of today and how it got there, but trending
> > seem to buy you any meaningful predictability. It is then up to
> > team itself as to how honest and forthright it wants to be in the
> > of trouble.
> > I hope this makes sense and helps convey a little of my experience
> > with the sprint burndown.
> > -- Victor Szalvay
> > Danube Technologies, Inc.
> > http://danube.com
- I do not unless your team is planning on working weekends all the time, and lets hope not! :-)-Nick----- Original Message -----From: Ilja PreussSent: Friday, June 02, 2006 1:13 AMSubject: RE: [scrumdevelopment] Re: Do you count weekends in your burn down chart?> Ron,
> I hope your question is rhetorical because clearly I can't
> answer something in a yahoo group posting that you've not
> been able to achieve in 2 years of work.
I didn't see anything in Ron's post suggesting that he wasn't able to help
> I agree this is a problem and I see it often myself. I don't
> think dumping additional metrics on top of the sprint
> burndown is going to solve this problem though.
Well, yes - just dumping it on the sprint burndown is probably not the most
effective way to use a trendline; it's certainly nothing I would suggest to
Take care, Ilja
"Information Radiation in Practice -
Communication Tools for Colocated Teams"
Tutorial at the XP2006 conference, Oulu