20010Re: [scrumdevelopment] Tracking hours for budgets and billing
- Mar 6, 2007Thanks for your feedback!
To give you more insight into how we are currently operating. We use
JIRA to perform backlog management, using JIRA's versions to correspond
to sprints. We have a separate timesheet entry tool that tracks time in
larger buckets for billing purposes.
I've suggested that we only fill in remaining estimate in JIRA (sprint
backlog items), but fill in time spent in the timesheet program for
billing. This argument was met with opposition by some people within my
organization, since the timesheet program is less granular and is not
updated as often.
I like your point about entering time in the backlog causing people to
subconsciously compute the estimate by subtracting the actual. Very
Also, to head off any tangents, I'm well aware of arguments for simply
maintaining a whiteboard, etc. for task lists. JIRA has proved useful
for keeping everything transparent, allowing off-site clients to keep up
with what is going on, and to support distributed teams when necessary.
All of these things are non-ideal, but are realities on some projects.
On Tue, 6 Mar 2007 08:30:34 -0700, "Steven Gordon"
> If your company already has this billing and budgeting requirement, then
> presumably already hasa system for people to enter their time for billing
> and budgeting purposes and software to accumulate these time entries
> appropriately. Why duplicate this effort - just ask the developers to
> continue using the pre-existing system for this purpose, and leave the
> burn-down and task board unpolluted with the additional noise of actual
> Not only will adding noise to the burn-down and task board make those
> more difficult for the team to read at a glance and use for their
> purpose, but I have found that putting actual on the same information
> radiator as revised estimates causes people to subconsciously compute the
> estimate of a task on day N+1 by subtract the actual time spent on day N
> from the estimate on day N. This biases the data that the team depends
> for self-organizing in a way that will tend to hide problems until later
> the sprint.
> 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.
> > 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!
> > Thanks,
> > Jeremy Haile
- << Previous post in topic Next post in topic >>