Tracking change and innovation in the enterprise software development community
Free Book Offer
SOA Demystified
$40 Value
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Posted by Chris Sims on Jan 26, 2009
A member of a new agile team asked the Scrum Development list how to keep track of the actual time engineers spend on tasks, and how this relates to the agile concept of velocity. Velocity is the agile metric for tracking how fast the team is completing features, and thus how long it will take to complete a project. The group's opinion was that tracking time spent isn't necessary or useful.
The original poster explained that his team estimates the size of their stories using story points. As the team completes stories, they tally up the associated story points. This tally is then used to calculate the team's velocity:
...the team's velocity is roughly the amount of work the team can do per sprint. Maybe something like 25 Story Points / 4 week sprint. That number can be used to help gauge how much work can be taken on in each subsequent sprint.
So far, so good. The poster goes on to describe how the team's stories get broken down into tasks, and these tasks get estimated and tracked in terms of hours:
We've been using a burndown chart, part of which is having each team member write down time remaining per task each day. This is entered into a burndown chart spreadsheet. But, that just captures data for the burndown, it doesn't help with velocity.
This confusion exemplifies why some agilists, including Ron Jeffries, recommend not estimating or tracking tasks at all. George Dinwiddie added his view:
If you make the stories small, then you don't need to track hours in your burndown. I find teams do better just tracking stories, and they don't waste all that time re-estimating hours.
In the discussion thread, Ron and others point out that all the information needed to make useful projections in captured in "25 Story Points / 4 week sprint". This is the team's velocity, and is exactly what is needed to predict how many stories this team will probably be able to complete in the future.
Does your team track task estimates as well as story estimates? Leave a comment and share why or why not.
Agile Development: A Manager's Roadmap for Success
Right Collaboration Architecture Drives Business Transformation
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
...the Scum Development list...
I know people don't like Scrum, but... :)
Dave Rooney
Mayford Technologies
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.
Really? Interesting, mi amigo. Please, do tell.
Cheers
MB
"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.
I see it as a useful communications tool to those outside a project. My experience has been that a team's velocity stabilizes at a certain number, and the chart can then show the trend for when "finished" will occur.
Inside a team, I agree that it's value is limited at best.
Dave Rooney
Mayford Technologies
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?
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
18 comments
Watch Thread Reply