20008Re: [scrumdevelopment] Tracking hours for budgets and billing
- Mar 6, 2007Hello,
On 06 Mar 2007 06:49:51 -0800, 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.
My opinion is that fixed price and time should be possible if you are
flexible on the scope.
But actually, what I understand with your example is that the sprint
length and the number of sprints are defined but you may work more
than 40 hours if required. If this is the case, you're not doing fixed
time but *flexible* time and *fixed* scope (or you wouldn't work more
than 40h, right ?). So if you're billing on an hourly base, you may
run over budget unless you reduce the hourly rate :)
> 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
> related" task.
> 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!
I'd suggest to separate the scrum management stuff and the billing
stuff and to not use hours for estimations in scrum. You already
mentioned most disadvantages of hour based estimations (micro
management, boring for the team, meetings, reading/answering mails,...
need to be tracked too). That's why I'd really suggest to use
complexity/story/whatever points and velocity instead.
> Jeremy Haile
- << Previous post in topic Next post in topic >>