20037Re: Tracking hours for budgets and billing
- Mar 8, 2007I guess eg0master pointed out something that would help to "model"
this discussion perfectly. Imho, what is actually being discussed is
"how to track the sprint from a scrum point of view" if I need more
information to pass on to higher management and/or accounting? I am
not that experienced in scrum yet but tracking sprint in a scrum point
of view means: daily scrums AND burndown chart. Period. The SM knows
how to deal with the data he/she may infer out of this.
Now one may ask: what if higher management needs (for their reason)
any additional information that may lead me to "micromanagement"? What
we are doing here in my company covers this assumption. We have a
couple of scrum teams that deal with pure development PLUS another
scrum team that deals with process-related documentation and
measurement. The difference between both teams is that development
teams implements product-related PBIs whereas management team
implements process-related PBIs.
You could go further in this model and implement type B scrum making
the management team responsible for upcoming sprints planning.
Hope I could help.
--- In firstname.lastname@example.org, "eg0master" <yahoo@...> wrote:
> I think most comments here are concentrating a little bit too much on
> the "fixed feature" part. You are forgetting that 40h worked planned
> will turn out to be more or less than 40h ion the end and almost never
> exactly 40h.
> And since teams should be working towards the sprint goal it shouldn't
> come as a surprise that some teammembers will put in a few extra hours
> here and there in order to complete everything in the sprint. Not
> because they have to but because they want to.
> I have had a similar problem. Time was (and still is) tracked in a
> seperate system and we used a second system for the scrum related
> parts never mixing the two. Typically the time recording system have
> "projects" and breaking it down to sprints and backlog items is never
> needed. However we suffered from the "double work" feel and not
> restimating time remaining but rather remove whatever time was worked
> on each item until a few hours remained at which point the item
> remained at the same few hours until complete...
> So what was the solution? Well, I have completely turned from the
> "using an application" towards using a taskboard on a
> table/whiteboard. As soon as I use an application I want it to solve
> all my needs. But the "low tech" solution in my opinion gives me (and
> management) a better overview of how things are going in the sprint.
> Actually it was management who requested using a better "system" than
> the application since the taskboard is much more visable and
> understandible than hours remaining in a burndown chart. And since it
> is low-tech nobody expects it to solve all our time recording
> problems, it just solves the most important one - how to track the
> sprint from a scrum point of view.
- << Previous post in topic Next post in topic >>