20021Re: [scrumdevelopment] Tracking hours for budgets and billing
- Mar 7, 2007Scrum uses time-boxed iterations. If your client is billed at 30 hrs a month, for example, you should only be planning 30 hrs of work in your sprint backlog. It sounds like you have your features fixed (ie whatever is in the sprint *must* be completed at the end of it) and instead work overtime to make up for the difference. That isn't really how Scrum is supposed to work. Features are negotiable - the schedule and resources are fixed.In your situation I'd a) have the team plan only as much work that they think they can reasonably accomplish in the amount of time the customer is paying for, b) track actuals if necessary for accounting purposes. Actuals won't tell you were the project is, but can be helpful after a project to see how close or far off you were from the original plan. Presumably you can use the burndown for this too because if at the end the burndown still had 5 hrs of features remaining, the team was off by 5 hrs in their estimate.I think the bigger issue you need to examine is how you're planning the sprint. It sounds like a fixed-scope sitaution to me.Nicholas
On 3/6/07, Jeremy Haile <jhaile@...> wrote:
Scrum only prescribes updating hours to show the amount of time
remaining on features. This works great in combination with a burn-down
chart to help manage delivering features within a Sprint.
However, I work for a software company that not only needs to be able to
deliver software within a sprint (or by a deadline), but also needs to
deliver it within a defined budget.
For example, let's say I'm building a web application and working on a 3
week sprint. If I work 50 hours each week, a burn-down chart may look
like everything is on track to be delivered during this sprint, but I
may still overrun the budget since we bill our clients on an hourly
basis. (10 hours * 3 weeks = 30 hours over-budget) Although if we
planned our sprints based on the number of hours worked and stuck to it
exactly, this might not be an issue - in reality, the number of hours
can vary week-by-week.
Our approach so far has been to track the hours that developers work on
specific tasks on a daily basis. This adds significant overhead,
headache, and is not "pure Scrum." We have typically reported hours to
tasks or features that are in the Sprint backlog.
However, sometimes your activities throughout the day are not directly
related to a particular backlog item ( e.g. writing e-mails, having a
general design meeting, etc.) We either end up adding in special tasks
for "administrative" work, or lumping those hours into the "most
I've thought about trying to completely separate the "Scrum management"
from the "billing/budget management." In this scenario, we would track
our hours in general buckets for "billing purposes", and update
remaining hours on features for "Scrum purposes." However, this can
make developers feel like they are having to do double time tracking.
Also, some of our managers like the ability to compare the number of
hours we've worked on tasks to our original estimates. (although you
could argue this is not really a good or necessary thing)
Does anyone have any experience in implementing Scrum and also meeting
the needs of doing hourly tracking for budgetary and billing purposes?
Does anyone have recommendations for methods or tools that could support
this process? I'd appreciate any ideas or thoughts!
Nicholas Cancelliere, Austin TX
" Do not meddle in the affairs of Wizards, for they are subtle and quick to anger." -- J.R.R. Tolkien
- << Previous post in topic Next post in topic >>