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

Tracking hours for budgets and billing

Expand Messages
  • Jeremy Haile
    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
    Message 1 of 13 , Mar 6, 2007
      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
    • Steven Gordon
      If your company already has this billing and budgeting requirement, then it presumably already hasa system for people to enter their time for billing and
      Message 2 of 13 , Mar 6, 2007
        If your company already has this billing and budgeting requirement, then it 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 times.

        Not only will adding noise to the burn-down and task board make those tools more difficult for the team to read at a glance and use for their intended 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 on for self-organizing in a way that will tend to hide problems until later in the sprint.

        Steve

        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


      • Pascal Thivent
        Hello, ... 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
        Message 3 of 13 , Mar 6, 2007
          Hello,

          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.

          >
          > Thanks,
          > Jeremy Haile
          >

          --
          Pascal
        • Jeremy Haile
          Thanks for your feedback. ... Certainly they are possible. Are you suggesting that by doing fixed price you eliminate the need to worry track hours
          Message 4 of 13 , 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
          • Jeremy Haile
            Thanks 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
            Message 5 of 13 , Mar 6, 2007
              Thanks 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
              good argument.

              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.

              Jeremy Haile


              On Tue, 6 Mar 2007 08:30:34 -0700, "Steven Gordon"
              <sgordonphd@...> said:
              > If your company already has this billing and budgeting requirement, then
              > it
              > 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
              > times.
              >
              > Not only will adding noise to the burn-down and task board make those
              > tools
              > more difficult for the team to read at a glance and use for their
              > intended
              > 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
              > on
              > for self-organizing in a way that will tend to hide problems until later
              > in
              > the sprint.
              >
              > Steve
              >
              > 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
              > >
              > >
            • Nicholas Cancelliere
              Scrum uses time-boxed iterations. If your client is billed at 30 hrs a month, for example, you should only be planning 30 hrs of work in your sprint backlog.
              Message 6 of 13 , Mar 7, 2007
                Scrum uses time-boxed iterations.  If your client is billed at 30 hrs a month, for example, you should only be planning 30 hrs of work in your sprint backlog.  It sounds like you have your features fixed (ie whatever is in the sprint *must* be completed at the end of it) and instead work overtime to make up for the difference.  That isn't really how Scrum is supposed to work.  Features are negotiable - the schedule and resources are fixed.
                 
                In your situation I'd a) have the team plan only as much work that they think they can reasonably accomplish in the amount of time the customer is paying for, b) track actuals if necessary for accounting purposes.  Actuals won't tell you were the project is, but can be helpful after a project to see how close or far off you were from the original plan.  Presumably you can use the burndown for this too because if at the end the burndown still had 5 hrs of features remaining, the team was off by 5 hrs in their estimate.
                 
                I think the bigger issue you need to examine is how you're planning the sprint.  It sounds like a fixed-scope sitaution to me.
                 
                Nicholas
                 


                On 3/6/07, 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




                --
                Nicholas Cancelliere, Austin TX
                " Do not meddle in the affairs of Wizards, for they are subtle and quick to anger." -- J.R.R. Tolkien
              • eg0master
                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
                Message 7 of 13 , Mar 8, 2007
                  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.
                • Ron Jeffries
                  Hello, eg0master. On Thursday, March 8, 2007, at 5:59:51 AM, you ... Welcome to the dark side. You will be much more powerful now, my young apprentice ... Ron
                  Message 8 of 13 , Mar 8, 2007
                    Hello, eg0master. On Thursday, March 8, 2007, at 5:59:51 AM, you
                    wrote:

                    > So what was the solution? Well, I have completely turned from the
                    > "using an application" towards using a taskboard on a
                    > table/whiteboard.

                    Welcome to the dark side. You will be much more powerful now, my
                    young apprentice ...

                    Ron Jeffries
                    www.XProgramming.com
                    My advice is to do it by the book, get good at the practices, then do as
                    you will. Many people want to skip to step three. How do they know?
                  • Jeremy Haile
                    You got it exactly. We honestly don t have a situation where we are doing fixed planning and then making people slave in overtime hours to get everything
                    Message 9 of 13 , Mar 8, 2007
                      You got it exactly. We honestly don't have a situation where we are
                      doing "fixed planning" and then making people slave in overtime hours to
                      get everything done. We plan time-boxed sprints, and try to get those
                      features done to the best of our abilities. Sometimes people have
                      vacation planned well in advance (which we know during sprint planning),
                      sometimes people work more hours, sometimes less... Regardless, since
                      you can't just say "40 hours" and be done with it, we do have to track
                      hours so we can report to our clients for billing.

                      I really appreciate your feedback - getting the Scrum planning part "out
                      of a tool" was one solution I was considering, and it's great to hear
                      that it worked for you. Now I just have to sell my organization on that
                      solution. But I'm sure I'll meet some resistance. The organization has
                      paid money for a tool (JIRA), many people like the tool, and we brag
                      about the ability of clients to login to our website and get information
                      about the current Sprint tasks, etc. Obviously clients could come into
                      the office and look at our taskboard - and we always have (at a minimum)
                      weekly meetings with our clients to make sure we can ask questions and
                      they can stay informed of our progress. But, many people like the idea
                      of being able to log into a website and see things, generate reports,
                      etc.

                      Thanks!
                      Jeremy Haile


                      On 08 Mar 2007 03:00:04 -0800, "eg0master" <yahoo@...> said:
                      > 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.
                      >
                    • hroriz_filho
                      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
                      Message 10 of 13 , Mar 8, 2007
                        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.
                        >
                      • Mark Levison
                        ... I ve nothing useful to add wrt your original topic - but I do think you will the section Agile Outside of Software Development pgs 311-334 of Alistair
                        Message 11 of 13 , Mar 8, 2007
                          On 3/6/07, Jeremy Haile <jhaile@...> wrote:
                          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.

                          I've nothing useful to add wrt your original topic - but I do think you will the section "Agile Outside of Software Development" pgs 311-334 of Alistair Cockburn's "Agile Software Development" give you some interesting ideas.

                          Cheers
                          Mark
                          ----------------------------------------------------------------------
                          Blog: http://www.notesfromatooluser.com/
                          Most Popular posts:
                          Aperture vs. Lightroom - best comparisons
                          http://www.notesfromatooluser.com/2007/02/aperture_vs_lig.html
                          Scrum in a Nutshell or 5 minutes to learn Scrum http://www.notesfromatooluser.com/2006/11/scrum_in_a_nuts.html
                          Getting Things Done!!! Can't Keep Track of all the tasks you have to do? Need a better Tool to Implement GTD? http://www.notesfromatooluser.com/2006/12/getting_things_.html
                        • George Dinwiddie
                          ... Would a daily photograph of the taskboard and a sprintly summary in JIRA suffice for people? - George -- ... * George Dinwiddie *
                          Message 12 of 13 , Mar 8, 2007
                            Jeremy Haile wrote:
                            > I really appreciate your feedback - getting the Scrum planning part "out
                            > of a tool" was one solution I was considering, and it's great to hear
                            > that it worked for you. Now I just have to sell my organization on that
                            > solution. But I'm sure I'll meet some resistance. The organization has
                            > paid money for a tool (JIRA), many people like the tool, and we brag
                            > about the ability of clients to login to our website and get information
                            > about the current Sprint tasks, etc. Obviously clients could come into
                            > the office and look at our taskboard - and we always have (at a minimum)
                            > weekly meetings with our clients to make sure we can ask questions and
                            > they can stay informed of our progress. But, many people like the idea
                            > of being able to log into a website and see things, generate reports,
                            > etc.

                            Would a daily photograph of the taskboard and a sprintly summary in JIRA
                            suffice for people?

                            - George

                            --
                            ----------------------------------------------------------------------
                            * George Dinwiddie * http://blog.gdinwiddie.com
                            Software Development http://www.idiacomputing.com
                            Consultant and Coach http://www.agilemaryland.org
                            ----------------------------------------------------------------------
                          • srinivas chillara
                            ... Ha, ha, ha,... and by the time you learn, you ll be old my friend. Joking! ... How very true indeed!
                            Message 13 of 13 , Mar 8, 2007
                              > Welcome to the dark side. You will be much more
                              > powerful now, my
                              > young apprentice ...

                              Ha, ha, ha,... and by the time you learn, you'll be
                              old my friend. Joking!


                              > My advice is to do it by the book, get good at the
                              > practices, then do as
                              > you will. Many people want to skip to step three.
                              > How do they know?

                              How very true indeed!



                              __________________________________________________________
                              Yahoo! India Answers: Share what you know. Learn something new
                              http://in.answers.yahoo.com/
                            Your message has been successfully submitted and would be delivered to recipients shortly.