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

20009Re: [scrumdevelopment] Tracking hours for budgets and billing

Expand Messages
  • Jeremy Haile
    Mar 6, 2007
      Thanks for your feedback.

      > My opinion is that fixed price and time should be possible if you are
      > flexible on the scope.

      Certainly they are possible. Are you suggesting that by doing fixed
      price you eliminate the need to worry track hours altogether? I can see
      a whole topic for discussion about how to construct contracts for
      software work that are friendly to Scrum. Perhaps that's related to my
      question... However, our current contracts typically fall into the
      normal fixed price or T&M (time and materials) variety.

      > 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 :)

      Developers typically work around 40 hours a week, but yes - in some
      cases they work more or less hours. If we are on a T&M (time and
      materials) contract, we would bill more or less depending on the number
      of hours worked. On a fixed price, management usually wants to know if
      they are running over budget or under budget on the fixed price contract
      - and how far over or under budget.

      > 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.

      We could (and have) use complexity/story points to do estimation - but
      in order to calculate cost, the reality is that we have to turn the
      estimate into a dollar value. Currently we do that by estimating or
      converting the estimate into hours and multiplying that times the hourly
      rate of the various resources who will be involved.

      Although I'm not sure the feasibility of completely revamping the
      organization's billing, tracking, and management practices - I'd love to
      hear actual experiences with how people have handled these types of
      situations. Has anyone started with a traditional project organization
      that billed clients on an hourly basis - and converted the model to a
      more Scrum-friendly approach? If so, what did you do and what pitfalls
      did you encounter?

      Thanks,
      Jeremy
    • Show all 13 messages in this topic