Track Velocity, Not Time Spent on Tasks

...the Scum Development list...

Oops... my own slip. My comment should have been, "I know SOME people don't like Scrum...".

:)

Absolutely agree that if you're thinking you're getting value out of tracking beyond any extremely casual level your tasks, then you're prolly not really "getting" agile. You're likely doing something wrong.

My rant on why (and on "burn" charts) here:
aydsoftware.blogspot.com/2009/01/burning-down-h...

Cheers
MB

Yup, Agile 101 - "Track results (delivered Stories) not activity (tasks)".

As for burning the burndowns, I agree comnpletely for Sprint/Iteration burndowns. I do see value in Release-level burndowns, though.

Dave Rooney
Mayford Technologies

Hi!

I agree with this view. Time tracking in a project environment hast its focus in the wrong aspect, similar to driving a car guided for the fuel meter.

My problem is that my company has a pool of engineers that serve many customers concurrently, therefore the finantial manager wants tio know which customer consumes with fraction of the time, to make the billings.

Any hint to avoid time tracking in this type of environment?

Agustin

I do see value in Release-level burndowns, though.

"I do see value in Release-level burndowns, though."

? Please do tell. I'm curious what the use of that is. If you have good velocity you don't really need a burndown chart.

Please do tell. I'm curious what the use of that is.

So you mean that a Release burnDOWN, aka lines of hours (activity) completed/remaining, is a good way to show when "finished" might occur?

I'm confused, I admit. How is that any more useful (or, maybe more to the point, any more reliable) than lines of "story points" (functionality) completed/desired?

Not trying to pick on ya, I'm just not getting it.

Cheers
MB

I use Story Points remaining. Here's an example:

www.mayford.ca/xp/velocity.html

Again, within a team it doesn't provide a whole lot of value. Outside of the team, however, it's a simple tool for quick communication.

(And I don't feel picked on... yet ;)

Dave Rooney
Mayford Technologies

We are currently in the midst of this issue, and I would love to get feedback on this issue...

As we roll out a new agile process across a large development organization (500+), we are trying to reconcile the management view that is necessary to support Sales and Marketing. Playing devils advocate on this, as an product development executive, I want to know where I stand against the thematic agreement of scope for a given date. I intend to report currently comprehended scope on a sprint-by-sprint basis, but I need to know if we are off from the original expectations set at Release Planning time - even if they are high level.

This seems like a reasonable desire for interfaces to Sales, for example, from the product Development organization. Ergo, Release Burndowns are useful to me.

Can anyone comment on this?

--
James Korotney
Technical Consultant, Technical Architecture
Compuware
One Campus Martius
Detroit, Michigan 48226
313-227-2395 Direct
248-760-8218 Mobile
313-227-7300
james.korotney@compuware.com

Not wanting to be "branded un Agile" on this one but i dont think it is a particularly big issue. We are a medium sized shop with which estimates in story points and tracks in hours using a burndown over the iteration.

Without tracking in hours devlopers found it hard to focus on what the team expected them to achieve and the time tracking gave them focus. The key was that there is no blame within the team if an estimate is under or over.

A task is estimated by the owner when they are given the task and the card is updated each day with hours done and remaining. The estimate can be changed each day by the task owner with no negativity attached. This has several benefits

management and stakeholdes can look at the burndown as they walk past the board and see at a glance where we are

The team have early visability of a task slipping and can all try to help rectify the situtation as a team

the project manager can start setting the stakeholder expectations for non delivery of low priority tasks

by tracking points the developers couldnt acurately manage how long they had left on a task to stay on track and the PM was constantly asking how long left some tasks had just in case one was slipping. it's a question of human beings; people do tend to focus more when they have expectations setupon them to deliver, this is where trust and quality is key must be present. Not all humans work hard constantly and have the consistancy of attitude that i have found just using points would require.

comments are greatly welcome

Ah, I see. A "points/features-based" burndown. Sorry to be picky...but I call that a "burnUP", just with the line going in the other direction.

We could look at this as one of those "tomatoe / tomahtoe" things.

But, I could also point out at least 2 reasons I think literally going UP has an advantage:

1. (touchy feely) it focuses on the positive: "more and more features are being delivered" (aka "we are creating things!"), rather than "less and less features need to be completed" (aka "We're just working down a checklist"). Maybe its just me, but I think this makes a difference. Admittedly, take it with a grain of salt.

2. (more concrete) it enables one to compare progress to multiple possible release thresholds (horizontal lines), rather than implying there is only one possible release content threshold (x-axis). I think this fits in more suitably with how we should really be approaching agile release planning/management.

(ok, and a third, I lied) Another reason is simply the "spade is a spade" one - Scrum has ingrained in many people's heads (this thread as a case in point) that a burndown is an hours/input-based chart, and its kinda confusing doing what's more typically known as a burnup, a points/output-based chart and burning the line down. Again, maybe just me though.

Either way...spose I'm now being picky, so I'll stop there :-)

Cheers
MB

(Re: James Korotney)

First, regarding "I intend to report currently comprehended scope on a sprint-by-sprint basis" - High-Five, that's an excellent start and way more than half the battle, so long as ya'll be honest with yourselves!

Second, yes, it's a more than reasonable ask by Sales, Execs, PM, etc for you to compare where the team is relative to what was said at Release Planning time (any time in the past for that matter). In fact...it's the essence of agile: Plan, Go, Inspect, Adapt! This of course being the "Inspect" part, I also hope you and your askers make good on the the "Adapt" part. That is the real essence of Agile. And, unfortunately, the one most forgotten, particular (at least in my experience) with bigger organizations.

Finally, more to your question, a Release-level burn chart is absolutely a reasonable mechanism to get a feel for how you're tracking. All I'm saying is that I think a burnUP is a better tool to use for this than a burnDOWN (see my last response for more on this).

Hope that helps.

Cheers
MB

BTW, if you're interested in a more one-one discussion on this, shoot me an email at bria526@gmail.com.

(Re: Stuart Hughes)

If you haven't done so, I highly suggest taking a good read of the Scrum mailing list thread that this InfoQ news post is based upon. I think you'll find some good nuggets there that'll apply to where you're coming from.

That said, an additional thought or two from me. First, glad this is working for you! - it ain't "un-Agile", just may be worth considering if you have other options.

Typically, in my experience, if the only way to get the transparency and motivation you need is by tracking metrics on tasks, then one (or many) of a few things could be happening:
- your stories are too big, making them take too long (and look "stalled")
- you have too many stories in progress at one time, also making each take longer, and also making it much harder to keep track of what's done and what's not
- your iterations are too long, which makes "natural motivation" a much harder achievement, as well as makes using a "gut feel" to know where you stand overall harder
- your not verbally communicating within the team as best as you could (eg with your daily standup), which puts a heavier reliance on "the numbers"

Maybe none of this is the case, hard for me to say. Just my $.02 of experience from what I've seen from most teams who couldn't manage themselves (and they're managers) without relying on hours-based task estimates.

Hope this is helpful for you!

Cheers
MB

RE Mike Bria

Mike thanks for the view i think you make a lot of sense with what you are saying and i think your points have some real value.

This may be a symptom of implementing agile and evolving as the team learns. in response to your questions

Our stories are three days (max)
One developer is not allowed to have more than one card "in progress" at any time, we allow one to be moved to "on hold" if it gets blocked
Our iterations are 3 weeks
Standups happen every day at the same time and happen if the PM is not present, we also have a scrum of scrums every tuesday and thursday to work at a higher level

Thought these facts may help. My view is that this is part of a transformation of a company and sometimes changing to many things at once or removing somthing that people are used to can be difficult.

I believe agile to be an evolution of what works and we have shown this to be the case over the past year. maybe we will attempt a trial based on the scrum list? probably not, as a company many of the bits of Agile have made it into our development process very quickly. Sadly with project offices, budgets and accountants some of the others are a little slower to evolve.

thanks for the view

Stuart

In my experience, the greatest pressure for Burndown charts come from those outside the team. Typically it's the Project Managers or well-meaning executives who want to see progress up on the wall (or on their computer screen, if your charts are automated) because they're the ones feeling the pressure. The team members and the coach know that everyone's working hard, regardless of whether the end result in a particular Iteration is 75% of what was planned, 100% or 125%. The problem is that many of those outside the team expect 100% or better every time, so that they never have to adjust a release schedule "outward" (extend it beyond its current end-date).

That sort of thing can lead teams to under-commit (thereby making it more likely that they'll always hit at least 100%), which inevitably then results in them being (somewhat understandably) accused of "low-balling" their commitments, and things go downhill from there. It's unfortunate that so many people in important positions fail to understand that an average, by definition, means that you'll sometimes be under and sometimes be over. Instead, it's treated as a mark that has to be hit every time.

I have found the same thing, using just the number of story points per iteration is enough to get a good feel for our capability per iteration/sprint. When we did our 1st sprint we did break things down to tasks and estimated hours, worked out our budget in hours and did the maths..a lot of effort which we found out by the end of the sprint anyway by simply totalling up the story points..suppose it depends on how/if you want to monitor individuals involvement during the sprint...tracking actual time does help with this but its an overhead...what does anyone else think about this?

Dude - "Ask" is not a noun. You remove all credibility when you do stuff like that.

Cheers.