Loading ...
Sorry, an error occurred while loading the content.

20037Re: Tracking hours for budgets and billing

Expand Messages
  • hroriz_filho
    Mar 8, 2007
    • 0 Attachment
      I 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.

      Heitor


      --- In scrumdevelopment@yahoogroups.com, "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.
      >
    • Show all 13 messages in this topic