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

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

Expand Messages
  • ronjeffries@acm.org
    I think a cost focus is one of the main indicators that a project or organization is not going well. The value provided should be so visibly more than the cost
    Message 1 of 28 , Feb 17 9:39 AM
    • 0 Attachment
      I think a cost focus is one of the main indicators that a project or organization is not going well. The value provided should be so visibly more than the cost as to make detailed cost accounting clearly a waste of time.

      In addition, I happen to know that in almost every auditing situation, the exact details are not relevant. I base this on many years as a development executive running capitalized projects.

      R

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

      > Ron, I agree.
      > And that's what I meant when I said "summation of actual days worked by each team members". Of course cost of infrastructure (h/w, s/w, training etc.) also get added to this.
      > But again this is an ideal scenario when the team is working only 8 hrs/day and still meeting the sprint objectives.
      > But what if the team works over-time. If they are truly agile team, it should not come to that. But I am yet to see such team.
      > In such case don't you think we need to keep track of over-time cost? And how will we calculate over-time cost unless we keep track of actual hrs spent (assuming team members are paid on the basis of $/hr)on the project?
      >
      > Gopinath
      >
      >
      >
      >
      > --- In scrumdevelopment@yahoogroups.com, 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
      >>>
      >>>
      >>>
      >>
      >
      >
      >
      >
      > ------------------------------------
      >
      > To Post a message, send it to: scrumdevelopment@...
      > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
      >
      >
      >
    • 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 2 of 28 , Feb 17 10:18 AM
      • 0 Attachment
        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 3 of 28 , Feb 17 10:47 AM
        • 0 Attachment
          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 4 of 28 , Feb 17 11:15 AM
          • 0 Attachment
            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 5 of 28 , Feb 17 11:27 AM
            • 0 Attachment
              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 6 of 28 , Feb 17 11:34 AM
              • 0 Attachment
                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 7 of 28 , Feb 17 11:37 AM
                • 0 Attachment
                  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 8 of 28 , Feb 17 11:42 AM
                  • 0 Attachment
                    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 9 of 28 , Feb 17 1:18 PM
                    • 0 Attachment

                       

                      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 10 of 28 , Feb 17 1:37 PM
                      • 0 Attachment
                        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 11 of 28 , Feb 17 1:43 PM
                        • 0 Attachment
                          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 12 of 28 , Feb 17 1:58 PM
                          • 0 Attachment
                            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.