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

Re: [scrumdevelopment] Re: Pair programming - how to account for the hours spent?

Expand Messages
  • Charles Bradley - Scrum Coach CSM PSM I
    I concur with Chet, Ron, and others here. I myself have worked on a consulting gig where we were doing Scrum and had to track billable hours. Trying to do
    Message 1 of 28 , Feb 17, 2011
      I concur with Chet, Ron, and others here.  I myself have worked on a consulting gig where we were doing Scrum and had to track billable hours.

      Trying to do cost accounting at the Sprint task level is trying to modify Scrum to do something it was not meant to do.

      If you need to track the time for other reasons, use whatever you used before you knew about Scrum, but don't futz with the Scrum framework to do it.  Further, don't try to compare the costed time(billable, whatever) to the time spent on Scrum tasks.  Again, that's 'abusing' the Scrum framework, IMO.

      Further, I encourage teams to use "ideal developer hours" to estimate tasks.  This means they estimate about 5-6hrs/day of ideal developer time.  For the reasons to do this, see Cohn's _Agile Estimating and Planning_.  That would defeat your cost tracking reconciliation as well.

      Billable/costable time does not equal Scrum Task time.  My reco is to use a different system for that, totally outside/indpendent of Scrum.

      Now, if you're tasking out your Sprint Backlog(and not using it for cost accounting), I use developer equivalent hours for any paired task. 

      So, if task A is roughly one dev for 4 hrs, task hours = 4 hrs.
      So, if task B is roughly two devs for 4hrs, task hours = 8hrs.

      I think Cohn's book mentioned above has explanations for this and what to do in pairing situations.
       
      -------
      Charles Bradley, CSM, PSM I
      Experienced Scrum Coach
      My blog: http://scrumcrazy.wordpress.com/



      From: Chet Hendrickson <lists@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Thu, February 17, 2011 9:48:31 AM
      Subject: Re: [scrumdevelopment] Re: Pair programming - how to account for the hours spent?

      Hello Peter,

      Why wouldn't you just have the developer report hours spent on each
      project?

      chet

      Thursday, February 17, 2011, 9:42:02 AM, you wrote:


      > And just to ask, if the team has to be billed to multiple
      > concurrent projects (despite the attendant context switching costs) what do you do?

      > Do you just divide the average number of points per week by team
      > cost per
      week to identify a cost per point? Doesn't that introduce
      > pressure from business teams to care about and decrease the number
      > of points that their stories are estimated at?

      > If you have to bill work within most weeks to multiple projects
      > with different stakeholders, budgetary units, etc, how would you
      > allocate the weeks costs between them?

      > Best Wishes,
      > Peter

      > On Feb 17, 2011, at 9:25 AM, ronjeffries@... wrote:



      > The cost is the integral of team cost over time. No more detail
      > than that is needed by any business process that I am aware of.

      > R

      > On Feb 17, 2011, at 8:31 AM, "gopinath" <gopinath_ram@...> wrote:

      >> While focusing on
      delivering value to the customers, one should also keep track of how much it costs the team to deliver that value. Only then you can measure the profitability of the project. And businesses exist to make profits. Even Not-for-profit projects need to know the actuals so that they don't run into losses.
      >> And this is a business practice agnostic to the development method used - traditional or agile.
      >> Now in line with agile principles the job of entering and tracking the actual hours and the associated book keeping can be done by someone outside the project team (may be Scrum Master, some Admin support) so that the team can focus on delivering the working software. However the information on actuals should be shared with the teams on regular basis. I have also seen some projects using effort burn-up charts.
      >> Till the team has truly imbibed the the principle of "sustained pace" the tracking of actuals may be cumbersome but
      it is necessary. For teams successful in implementing the principle "sustained pace (40hr week)", the calculation of actuals will be as simple as summation of actual days worked by each team members.
      >>
      >> Gopinath
      >>
      >>
      >> --- In scrumdevelopment@yahoogroups.com, Alan Dayley <alandd@...> wrote:
      >>>
      >>> What do you expect to learn or know from the actual hours data? What do you
      >>> do with the data?
      >>>
      >>> What you want from the data will indicate how you account for the hours.
      >>>
      >>> Alan
      >>>
      >>> On Wed, Feb 16, 2011 at 5:51 AM, kevinkrac <kkrac78@...> wrote:
      >>>
      >>>>
      >>>>
      >>>> When a developer A leaves aside his task
      for a while (maybe a whole
      >>>> day or even two) to help another developer B with analysis or coding
      >>>> of a task… how should they specify the `actual effort' of the story/
      >>>> task?
      >>>>
      >>>> Should they assign the total hours they spent together working on the
      >>>> story/task, times 2 (because the two of them were working)? Just
      >>>> charge the total hours spent but accounting just for the developer
      >>>> that owns the task? Is it irrelevant?
      >>>>
      >>>>
      >>>>
      >>>
      >>
      >>
      >>
      >>
      >> ------------------------------------
      >>
      >> To Post a message, send it to: scrumdevelopment@...
      >> To Unsubscribe,
      send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
      >>
      >>
      >>

      >



      --
      Best regards,
      Chet Hendrickson                          mailto:lists@...
      Check out our upcoming CSM Plus courses @
      http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28



      ------------------------------------

      To Post a message, send it to:  scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

      <*> To visit your group on the web, go to:
          http://groups.yahoo.com/group/scrumdevelopment/

      <*> Your email settings:
          Individual Email | Traditional

      <*> To change settings online go to:
          http://groups.yahoo.com/group/scrumdevelopment/join
          (Yahoo! ID required)

      <*> To change settings via email:
          scrumdevelopment-digest@yahoogroups.com
          scrumdevelopment-fullfeatured@yahoogroups.com

      <*> To unsubscribe from this group, send an email to:
          scrumdevelopment-unsubscribe@yahoogroups.com

      <*> Your use of Yahoo! Groups is subject to:
          http://docs.yahoo.com/info/terms/

    • Chet Hendrickson
      Hello All, I think what we are seeing here is another example of the unintended side effects of using tasks denominated in story points as a unit of progress
      Message 2 of 28 , Feb 17, 2011
        Hello All,


        I think what we are seeing here is another example of the
        unintended side effects of using tasks denominated in story points
        as a unit of progress measurement.





        --
        Best regards,
        Chet Hendrickson mailto:lists@...
        Check out our upcoming CSM Plus courses @
        http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
      • Adam Sroka
        Right. To add to that the cost of running a Scrum team is relatively fixed over time. For small products (i.e. short development cycle) there might be some
        Message 3 of 28 , Feb 17, 2011
          Right. To add to that the cost of running a Scrum team is relatively fixed over time. For small products (i.e. short development cycle) there might be some additional accounting necessary during team ramp-up periods or if there is a death march before the big release. But, most of the time Agile teams can be effectively treated as fixed cost per iteration, and the cost of features can be derived by dividing that fixed cost by the average velocity. 

          On Thu, Feb 17, 2011 at 6:25 AM, <ronjeffries@...> wrote:
           

          The cost is the integral of team cost over time. No more detail than that is needed by any business process that I am aware of.

          R



          On Feb 17, 2011, at 8:31 AM, "gopinath" <gopinath_ram@...> wrote:

          > While focusing on delivering value to the customers, one should also keep track of how much it costs the team to deliver that value. Only then you can measure the profitability of the project. And businesses exist to make profits. Even Not-for-profit projects need to know the actuals so that they don't run into losses.
          > And this is a business practice agnostic to the development method used - traditional or agile.
          > Now in line with agile principles the job of entering and tracking the actual hours and the associated book keeping can be done by someone outside the project team (may be Scrum Master, some Admin support) so that the team can focus on delivering the working software. However the information on actuals should be shared with the teams on regular basis. I have also seen some projects using effort burn-up charts.
          > Till the team has truly imbibed the the principle of "sustained pace" the tracking of actuals may be cumbersome but it is necessary. For teams successful in implementing the principle "sustained pace (40hr week)", the calculation of actuals will be as simple as summation of actual days worked by each team members.
          >
          > Gopinath
          >
          >
          > --- In scrumdevelopment@yahoogroups.com, Alan Dayley <alandd@...> wrote:
          >>
          >> What do you expect to learn or know from the actual hours data? What do you
          >> do with the data?
          >>
          >> What you want from the data will indicate how you account for the hours.
          >>
          >> Alan
          >>
          >> On Wed, Feb 16, 2011 at 5:51 AM, kevinkrac <kkrac78@...> wrote:
          >>
          >>>
          >>>
          >>> When a developer A leaves aside his task for a while (maybe a whole
          >>> day or even two) to help another developer B with analysis or coding
          >>> of a task… how should they specify the `actual effort' of the story/
          >>> task?
          >>>
          >>> Should they assign the total hours they spent together working on the
          >>> story/task, times 2 (because the two of them were working)? Just
          >>> charge the total hours spent but accounting just for the developer
          >>> that owns the task? Is it irrelevant?
          >>>
          >>>
          >>>
          >>
          >
          >
          >
          >
          > ------------------------------------

          >
          > To Post a message, send it to: scrumdevelopment@...
          > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
          >
          >
          >


        • Peter Bell
          But how do you allocate the cost across multiple projects if you ve got a small team with deliverables to different groups or a consulting firm with multiple
          Message 4 of 28 , Feb 17, 2011
            But how do you allocate the cost across multiple projects if you've got a small team with deliverables to different groups or a consulting firm with multiple concurrent projects to different clients?

            Best Wishes,
            Peter

            On Feb 17, 2011, at 2:15 PM, Adam Sroka wrote:

             

            Right. To add to that the cost of running a Scrum team is relatively fixed over time. For small products (i.e. short development cycle) there might be some additional accounting necessary during team ramp-up periods or if there is a death march before the big release. But, most of the time Agile teams can be effectively treated as fixed cost per iteration, and the cost of features can be derived by dividing that fixed cost by the average velocity. 

            On Thu, Feb 17, 2011 at 6:25 AM, <ronjeffries@...> wrote:
             

            The cost is the integral of team cost over time. No more detail than that is needed by any business process that I am aware of.

            R



            On Feb 17, 2011, at 8:31 AM, "gopinath" <gopinath_ram@...> wrote:

            > While focusing on delivering value to the customers, one should also keep track of how much it costs the team to deliver that value. Only then you can measure the profitability of the project. And businesses exist to make profits. Even Not-for-profit projects need to know the actuals so that they don't run into losses.
            > And this is a business practice agnostic to the development method used - traditional or agile.
            > Now in line with agile principles the job of entering and tracking the actual hours and the associated book keeping can be done by someone outside the project team (may be Scrum Master, some Admin support) so that the team can focus on delivering the working software. However the information on actuals should be shared with the teams on regular basis. I have also seen some projects using effort burn-up charts.
            > Till the team has truly imbibed the the principle of "sustained pace" the tracking of actuals may be cumbersome but it is necessary. For teams successful in implementing the principle "sustained pace (40hr week)", the calculation of actuals will be as simple as summation of actual days worked by each team members.
            >
            > Gopinath
            >
            >
            > --- In scrumdevelopment@yahoogroups.com, Alan Dayley <alandd@...> wrote:
            >>
            >> What do you expect to learn or know from the actual hours data? What do you
            >> do with the data?
            >>
            >> What you want from the data will indicate how you account for the hours.
            >>
            >> Alan
            >>
            >> On Wed, Feb 16, 2011 at 5:51 AM, kevinkrac <kkrac78@...> wrote:
            >>
            >>>
            >>>
            >>> When a developer A leaves aside his task for a while (maybe a whole
            >>> day or even two) to help another developer B with analysis or coding
            >>> of a task… how should they specify the `actual effort' of the story/
            >>> task?
            >>>
            >>> Should they assign the total hours they spent together working on the
            >>> story/task, times 2 (because the two of them were working)? Just
            >>> charge the total hours spent but accounting just for the developer
            >>> that owns the task? Is it irrelevant?
            >>>
            >>>
            >>>
            >>
            >
            >
            >
            >
            > ------------------------------------

            >
            > To Post a message, send it to: scrumdevelopment@...
            > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
            >
            >
            >




          • ronjeffries@acm.org
            Don t do that. It delivers value more slowly to everyone. Invariably. One of the few known always bad ideas not usually prefixed by someone saying Watch
            Message 5 of 28 , Feb 17, 2011
              Don't do that. It delivers value more slowly to everyone. Invariably. One of the few known always bad ideas not usually prefixed by someone saying "Watch this".

              R

              On Feb 17, 2011, at 2:27 PM, Peter Bell <lists@...> wrote:

              But how do you allocate the cost across multiple projects if you've got a small team with deliverables to different groups or a consulting firm with multiple concurrent projects to different clients?

              Best Wishes,
              Peter

              On Feb 17, 2011, at 2:15 PM, Adam Sroka wrote:

               

              Right. To add to that the cost of running a Scrum team is relatively fixed over time. For small products (i.e. short development cycle) there might be some additional accounting necessary during team ramp-up periods or if there is a death march before the big release. But, most of the time Agile teams can be effectively treated as fixed cost per iteration, and the cost of features can be derived by dividing that fixed cost by the average velocity. 

              On Thu, Feb 17, 2011 at 6:25 AM, <ronjeffries@...> wrote:
               

              The cost is the integral of team cost over time. No more detail than that is needed by any business process that I am aware of.

              R



              On Feb 17, 2011, at 8:31 AM, "gopinath" <gopinath_ram@...> wrote:

              > While focusing on delivering value to the customers, one should also keep track of how much it costs the team to deliver that value. Only then you can measure the profitability of the project. And businesses exist to make profits. Even Not-for-profit projects need to know the actuals so that they don't run into losses.
              > And this is a business practice agnostic to the development method used - traditional or agile.
              > Now in line with agile principles the job of entering and tracking the actual hours and the associated book keeping can be done by someone outside the project team (may be Scrum Master, some Admin support) so that the team can focus on delivering the working software. However the information on actuals should be shared with the teams on regular basis. I have also seen some projects using effort burn-up charts.
              > Till the team has truly imbibed the the principle of "sustained pace" the tracking of actuals may be cumbersome but it is necessary. For teams successful in implementing the principle "sustained pace (40hr week)", the calculation of actuals will be as simple as summation of actual days worked by each team members.
              >
              > Gopinath
              >
              >
              > --- In scrumdevelopment@yahoogroups.com, Alan Dayley <alandd@...> wrote:
              >>
              >> What do you expect to learn or know from the actual hours data? What do you
              >> do with the data?
              >>
              >> What you want from the data will indicate how you account for the hours.
              >>
              >> Alan
              >>
              >> On Wed, Feb 16, 2011 at 5:51 AM, kevinkrac <kkrac78@...> wrote:
              >>
              >>>
              >>>
              >>> When a developer A leaves aside his task for a while (maybe a whole
              >>> day or even two) to help another developer B with analysis or coding
              >>> of a task… how should they specify the `actual effort' of the story/
              >>> task?
              >>>
              >>> Should they assign the total hours they spent together working on the
              >>> story/task, times 2 (because the two of them were working)? Just
              >>> charge the total hours spent but accounting just for the developer
              >>> that owns the task? Is it irrelevant?
              >>>
              >>>
              >>>
              >>
              >
              >
              >
              >
              > ------------------------------------

              >
              > To Post a message, send it to: scrumdevelopment@...
              > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
              >
              >
              >




            • George Dinwiddie
              Chet, ... I completely agree. When I first heard of the notion of working with User Stories, I was delighted that the notion only measured delivered
              Message 6 of 28 , Feb 17, 2011
                Chet,

                On 2/17/11 1:47 PM, Chet Hendrickson wrote:
                > I think what we are seeing here is another example of the
                > unintended side effects of using tasks denominated in story points
                > as a unit of progress measurement.

                I completely agree. When I first heard of the notion of working with
                User Stories, I was delighted that the notion only measured delivered
                functionality. All my career I've despaired at the amount of effort
                spent in tracking effort spent.

                - George

                --
                ----------------------------------------------------------------------
                * George Dinwiddie * http://blog.gdinwiddie.com
                Software Development http://www.idiacomputing.com
                Consultant and Coach http://www.agilemaryland.org
                ----------------------------------------------------------------------
              • George Dinwiddie
                Peter, ... Like Ron says, don t do it. Or, if you have to do it, work as a team until one deliverable is done and then move to another. - George -- ... *
                Message 7 of 28 , Feb 17, 2011
                  Peter,

                  On 2/17/11 2:27 PM, Peter Bell wrote:
                  > But how do you allocate the cost across multiple projects if you've got
                  > a small team with deliverables to different groups or a consulting firm
                  > with multiple concurrent projects to different clients?

                  Like Ron says, don't do it. Or, if you have to do it, work as a team
                  until one deliverable is done and then move to another.

                  - George

                  --
                  ----------------------------------------------------------------------
                  * George Dinwiddie * http://blog.gdinwiddie.com
                  Software Development http://www.idiacomputing.com
                  Consultant and Coach http://www.agilemaryland.org
                  ----------------------------------------------------------------------
                • Paul Hudson
                  ... if you do need one team on multiple projects, I would recommend having each iteration dedicated to just one project.
                  Message 8 of 28 , Feb 17, 2011

                     

                    But how do you allocate the cost across multiple projects if you've got a small team with deliverables to different groups or a consulting firm with multiple concurrent projects to different clients?


                    Any way that works for you. But you're not doing Scrum in that case. Even if you do need one team on multiple projects, I would recommend having each iteration dedicated to just one project.
                  • Charles Bradley - Scrum Coach CSM PSM I
                    Someone called me a few months ago with the same details (multiple teams, multiple deliverables, matrixed personnel, consulting firm, etc). I basically told
                    Message 9 of 28 , Feb 17, 2011
                      Someone called me a few months ago with the same details (multiple teams, multiple deliverables, matrixed personnel, consulting firm, etc).

                      I basically told her the same thing Paul did below, and I said if that wasn't possible, then Scrum is probably not the right dev process/framework for them to use.

                      Do any of the other Agile methodologies handle this kind of arrangement better?  Crystal, perhaps?
                       
                      -------
                      Charles Bradley, CSM, PSM I
                      Experienced Scrum Coach
                      My blog: http://scrumcrazy.wordpress.com/



                      From: Paul Hudson <phudson@...>
                      To: scrumdevelopment@yahoogroups.com
                      Sent: Thu, February 17, 2011 2:18:25 PM
                      Subject: Re: [scrumdevelopment] Re: Pair programming - how to account for the hours spent?

                       


                       

                      But how do you allocate the cost across multiple projects if you've got a small team with deliverables to different groups or a consulting firm with multiple concurrent projects to different clients?


                      Any way that works for you. But you're not doing Scrum in that case. Even if you do need one team on multiple projects, I would recommend having each iteration dedicated to just one project.
                    • Peter Bell
                      Well, kanban is an obvious approach. You just pull the next ticket whoever it comes from and get to make the explicit choice between the cost of context
                      Message 10 of 28 , Feb 17, 2011
                        Well, kanban is an obvious approach. You just pull the next ticket whoever it comes from and get to make the explicit choice between the cost of context switching and the cost of lead time.

                        For example, if I told you that as project 3 in the current queue it would cost $1000 to have a set of  tweaks in the next spare sprint in 3 weeks or you could have them for $1400 by Friday it might be worth the extra cost (which covers the context switching costs and a small profit margin) to pay the $1400. Of course it is not the most efficient way of delivering the most software from a given team, but that's not necessarily what you always want to optimize for.

                        The more I think about it the more it seems that kanban would be a good fit for this use case. It also allows you to manage cycle time which is typically the biggest issue for clients with frequent small projects. 

                        Of course, I still agree that not having such context switching is a more efficient approach and where I have a client team I'm working with (especially on new projects) I'll usually use 2 week scrums as they can work full time on their project even if I can't.

                        Best Wishes,
                        Peter 

                        On Feb 17, 2011, at 4:37 PM, Charles Bradley - Scrum Coach CSM PSM I wrote:

                         

                        Someone called me a few months ago with the same details (multiple teams, multiple deliverables, matrixed personnel, consulting firm, etc).

                        I basically told her the same thing Paul did below, and I said if that wasn't possible, then Scrum is probably not the right dev process/framework for them to use.

                        Do any of the other Agile methodologies handle this kind of arrangement better?  Crystal, perhaps?
                         
                        -------
                        Charles Bradley, CSM, PSM I
                        Experienced Scrum Coach
                        My blog: http://scrumcrazy.wordpress.com/



                        From: Paul Hudson <phudson@...>
                        To: scrumdevelopment@yahoogroups.com
                        Sent: Thu, February 17, 2011 2:18:25 PM
                        Subject: Re: [scrumdevelopment] Re: Pair programming - how to account for the hours spent?

                         


                         

                        But how do you allocate the cost across multiple projects if you've got a small team with deliverables to different groups or a consulting firm with multiple concurrent projects to different clients?


                        Any way that works for you. But you're not doing Scrum in that case. Even if you do need one team on multiple projects, I would recommend having each iteration dedicated to just one project.


                      • Adam Sroka
                        ... My suggestion would be the same as what others have said. Either have independent product teams doing parallel releases of different products or have the
                        Message 11 of 28 , Feb 17, 2011
                          On Thu, Feb 17, 2011 at 11:27 AM, Peter Bell <lists@...> wrote:
                          >
                          >
                          >
                          > But how do you allocate the cost across multiple projects if you've got a small team with deliverables to different groups or a consulting firm with multiple concurrent projects to different clients?
                          >

                          My suggestion would be the same as what others have said. Either have
                          independent product teams doing parallel releases of different
                          products or have the team switch after a release. Then the accounting
                          doesn't change, but more importantly you are keeping the focus on
                          delivering working products and avoiding context switching mid-Sprint.

                          If you really need a lot of flexibility I would suggest pushing the
                          size of releases down to a single two-week, or even one-week, Sprint.
                          If that isn't enough you could even go smaller. You could even go to
                          single story releases at which point you are doing something that
                          looks less like Scrum.

                          ...

                          There is a group that I have coached that has three Scrum teams
                          supporting a couple dozen products. Most of the products are small and
                          have been around for a while, so they don't all need a lot of work.
                          This group has done the "Scrum-of-Scrums" thing to have all three
                          teams work on the same product before, but they have also had each
                          team working on different products.

                          In this scenario all the products serve more or less the same
                          customers. The customers belong to two different business groups. So,
                          the managers got together with the business groups and agreed to
                          account 66.7% of the costs to one group and 33.3% to the other group.
                          They manage both the cost accounting and the backlog priorities
                          according to these percentages. Seems to work reasonably well.

                          Not every situation breaks down this neatly, but the takeaway is that
                          you should talk to your customers and find some simple accounting that
                          will allow you to work in an Agile way without getting mired in the
                          minutia of budgets.
                        Your message has been successfully submitted and would be delivered to recipients shortly.