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

Story sizes and productivity gains

Expand Messages
  • Paul Epps
    I saw a presentation by Scott Downey last night at Agile SoCal on hyperproductive Scrum teams. Downey defines a hyperproductive team as a team that achieves a
    Message 1 of 18 , Jun 21 10:27 AM
      I saw a presentation by Scott Downey last night at Agile SoCal on hyperproductive Scrum teams. Downey defines a hyperproductive team as a team that achieves a 500% increase over its initial velocity, as measured in story points.

      I've seen Ron Jeffries recommend not using story points, instead sizing stories consistently around a couple of days, and counting stories instead of points. That's always seemed like a good idea to me, but after Downey's presentation, I was trying to think about how to measure productivity gains when sizing stories at a couple of days.

      To take a simple example, if I can do a story every two days, then I can do five stories in a two-week sprint. By definition (story = 2 days), I will continue to complete five stories per sprint forever. In order to demonstrate improvement over time, I would need a new measurement, e.g., value, right?

      Any ideas on how to measure team productivity over time using consistent story sizes?

      Thanks...

      Paul Epps
    • Chet Hendrickson
      Hello Paul, Please describe the process that this productivity measure will be input to. What is its purpose? chet Thursday, June 21, 2012, 1:27:06 PM, you
      Message 2 of 18 , Jun 21 10:44 AM
        Hello Paul,

        Please describe the process that this 'productivity measure' will be input to. What is its purpose?

        chet

        Thursday, June 21, 2012, 1:27:06 PM, you wrote:



        I saw a presentation by Scott Downey last night at Agile SoCal on hyperproductive Scrum teams. Downey defines a hyperproductive team as a team that achieves a 500% increase over its initial velocity, as measured in story points.

        I've seen Ron Jeffries recommend not using story points, instead sizing stories consistently around a couple of days, and counting stories instead of points. That's always seemed like a good idea to me, but after Downey's presentation, I was trying to think about how to measure productivity gains when sizing stories at a couple of days.

        To take a simple example, if I can do a story every two days, then I can do five stories in a two-week sprint. By definition (story = 2 days), I will continue to complete five stories per sprint forever. In order to demonstrate improvement over time, I would need a new measurement, e.g., value, right?

        Any ideas on how to measure team productivity over time using consistent story sizes?

        Thanks...

        Paul Epps






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

        [Non-text portions of this message have been removed]
      • Paul Epps
        Hi Chet - ... Downey described the purpose with this user story: AS A Scrum Product Owner who is trying to evaluate the efficacy of the product directions I
        Message 3 of 18 , Jun 21 11:27 AM
          Hi Chet -

          > Please describe the process that this 'productivity measure' will be input to. What is its purpose?

          Downey described the purpose with this user story: AS A Scrum Product Owner who is trying to evaluate the efficacy of the product directions I have chosen, I NEED a reliable way to measure the increased value
          contribution of the Team sprint-over-sprint SO THAT I can compare the Team's rate of value contribution increase to the changes in revenue we are generating and adjust our direction if the value isn't being realized.

          Thanks...

          pe

          > Thursday, June 21, 2012, 1:27:06 PM, you wrote:
          >
          >
          >
          > I saw a presentation by Scott Downey last night at Agile SoCal on hyperproductive Scrum teams. Downey defines a hyperproductive team as a team that achieves a 500% increase over its initial velocity, as measured in story points.
          >
          > I've seen Ron Jeffries recommend not using story points, instead sizing stories consistently around a couple of days, and counting stories instead of points. That's always seemed like a good idea to me, but after Downey's presentation, I was trying to think about how to measure productivity gains when sizing stories at a couple of days.
          >
          > To take a simple example, if I can do a story every two days, then I can do five stories in a two-week sprint. By definition (story = 2 days), I will continue to complete five stories per sprint forever. In order to demonstrate improvement over time, I would need a new measurement, e.g., value, right?
          >
          > Any ideas on how to measure team productivity over time using consistent story sizes?
          >
          > Thanks...
          >
          > Paul Epps
          >
          >
          >
          >
          >
          >
          > --
          > Best regards,
          > Chet Hendrickson mailto:lists@...
          > Check out our upcoming CSM Plus courses @
          > http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
          >
          > [Non-text portions of this message have been removed]
          >
        • Steven Gordon
          I suspect the relationship is backwards here: We should be finding that the bigger the stories a team works on, the slower the team would increase its
          Message 4 of 18 , Jun 21 11:28 AM
            I suspect the relationship is backwards here: We should be finding that the
            bigger the stories a team works on, the slower the team would increase its
            productivity.

            Productivity should be measure as actual value delivered to the customer
            over time, not something based on estimates.

            (BTW, I really enjoy the pushback I get from management on that - that
            development should be responsible for precise enough estimations to support
            all sorts of management metrics whereas the business does not have to be
            responsible for determining the actual value of being delivered what they
            ask for).

            SteveG

            On Thu, Jun 21, 2012 at 10:27 AM, Paul Epps <paul@...> wrote:

            > **
            >
            >
            > I saw a presentation by Scott Downey last night at Agile SoCal on
            > hyperproductive Scrum teams. Downey defines a hyperproductive team as a
            > team that achieves a 500% increase over its initial velocity, as measured
            > in story points.
            >
            > I've seen Ron Jeffries recommend not using story points, instead sizing
            > stories consistently around a couple of days, and counting stories instead
            > of points. That's always seemed like a good idea to me, but after Downey's
            > presentation, I was trying to think about how to measure productivity gains
            > when sizing stories at a couple of days.
            >
            > To take a simple example, if I can do a story every two days, then I can
            > do five stories in a two-week sprint. By definition (story = 2 days), I
            > will continue to complete five stories per sprint forever. In order to
            > demonstrate improvement over time, I would need a new measurement, e.g.,
            > value, right?
            >
            > Any ideas on how to measure team productivity over time using consistent
            > story sizes?
            >
            > Thanks...
            >
            > Paul Epps
            >
            >
            >


            [Non-text portions of this message have been removed]
          • Steven Gordon
            What else contributes to revenue changes? How can knowing how much the team delivered differentiate among all those contributions to revenue changes? Root
            Message 5 of 18 , Jun 21 11:33 AM
              What else contributes to revenue changes? How can knowing how much the
              team delivered differentiate among all those contributions to revenue
              changes?

              Root cause the revenue problems and see where development, marketing,
              sales, product ownership, etc. is involved. Assuming that the quantity
              delivered indicates whether development is the problem is lazy.

              SteveG

              On Thu, Jun 21, 2012 at 11:27 AM, Paul Epps <paul@...> wrote:

              > **
              >
              >
              > Hi Chet -
              >
              > > Please describe the process that this 'productivity measure' will be
              > input to. What is its purpose?
              >
              > Downey described the purpose with this user story: AS A Scrum Product
              > Owner who is trying to evaluate the efficacy of the product directions I
              > have chosen, I NEED a reliable way to measure the increased value
              > contribution of the Team sprint-over-sprint SO THAT I can compare the
              > Team's rate of value contribution increase to the changes in revenue we are
              > generating and adjust our direction if the value isn't being realized.
              >
              > Thanks...
              >
              > pe
              >
              >
              > > Thursday, June 21, 2012, 1:27:06 PM, you wrote:
              > >
              > >
              > >
              > > I saw a presentation by Scott Downey last night at Agile SoCal on
              > hyperproductive Scrum teams. Downey defines a hyperproductive team as a
              > team that achieves a 500% increase over its initial velocity, as measured
              > in story points.
              > >
              > > I've seen Ron Jeffries recommend not using story points, instead sizing
              > stories consistently around a couple of days, and counting stories instead
              > of points. That's always seemed like a good idea to me, but after Downey's
              > presentation, I was trying to think about how to measure productivity gains
              > when sizing stories at a couple of days.
              > >
              > > To take a simple example, if I can do a story every two days, then I can
              > do five stories in a two-week sprint. By definition (story = 2 days), I
              > will continue to complete five stories per sprint forever. In order to
              > demonstrate improvement over time, I would need a new measurement, e.g.,
              > value, right?
              > >
              > > Any ideas on how to measure team productivity over time using consistent
              > story sizes?
              > >
              > > Thanks...
              > >
              > > Paul Epps
              > >
              > >
              > >
              > >
              > >
              > >
              > > --
              > > Best regards,
              > > Chet Hendrickson mailto:lists@...
              >
              > > Check out our upcoming CSM Plus courses @
              > > http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
              > >
              > > [Non-text portions of this message have been removed]
              > >
              >
              >
              >


              [Non-text portions of this message have been removed]
            • George Dinwiddie
              Paul, On 6/21/12 1:27 PM, Paul Epps wrote: [snip] ... Any ideas on how to measure team productivity? - George -- ... * George Dinwiddie *
              Message 6 of 18 , Jun 21 11:38 AM
                Paul,

                On 6/21/12 1:27 PM, Paul Epps wrote:
                [snip]
                > Any ideas on how to measure team productivity over time using
                > consistent story sizes?

                Any ideas on how to measure team productivity?

                - George

                --
                ----------------------------------------------------------------------
                * George Dinwiddie * http://blog.gdinwiddie.com
                Software Development http://www.idiacomputing.com
                Consultant and Coach http://www.agilemaryland.org
                ----------------------------------------------------------------------
              • RonJeffries
                Hi Paul, ... That strikes me as ... how can I put this nicely ... overly indirect. It s a red herring. I suspect the real purpose of wanting to know this is to
                Message 7 of 18 , Jun 21 11:43 AM
                  Hi Paul,

                  On Jun 21, 2012, at 2:27 PM, Paul Epps wrote:

                  > Downey described the purpose with this user story: AS A Scrum Product Owner who is trying to evaluate the efficacy of the product directions I have chosen, I NEED a reliable way to measure the increased value
                  > contribution of the Team sprint-over-sprint SO THAT I can compare the Team's rate of value contribution increase to the changes in revenue we are generating and adjust our direction if the value isn't being realized.


                  That strikes me as ... how can I put this nicely ... overly indirect. It's a red herring.

                  I suspect the real purpose of wanting to know this is to "measure" how hard the team is working and how much they are accomplishing. This is a cost focus. Scrum projects are supposed to have a value focus: the PO is responsible for producing the highest possible value by the deadline. This is done quite simply: have the highest value possible in every Sprint.

                  The team is producing valuable stories at some rate. The PO's job is to select them so as to have the best possible value at every moment in time. If the stories are all the same "size", and the team is doing quality work (suitable testing and design improvement), the flow of work will be perfectly clear: you can draw a line to see how many more stories will be done.

                  If and when the team improves, the stories they can do in two days will be discernibly "larger". Everyone who is paying attention will notice this and take it into account when guessing how much they'll get done.

                  BUT THIS IS NOT IMPORTANT, because the PO always has the highest possible value attainable at the current moment, in potentially shippable form.

                  If the revenue potential of an idea is anywhere near the cost of the team building it, it is an incredibly bad idea and well past time to stop investing in the product. Therefore, at any moment in time, the PO can pick up her most favorite story and say to herself "This will bring in $11,000 in revenue and the team costs me $10,000 per Sprint. Screw this, time to get a better idea."

                  Hyperproductivity is a marketing idea made up by Jeff Sutherland to sell Scrum. It does exist, more or less. Teams doing good Scrum will get more done than they used to -- usually because they used to get nothing done. Nonetheless, this is a cost-based measure and is therefore inferior to managing by choosing valuable things to do.

                  Relatedly, Arlo Belshee has some evidence that choosing the most valuable thing no matter what it costs (within reason, I suppose) is a better strategy than considering the value/cost ratio.

                  Bottom line, cost focus is a danger sign in a Scrum / Agile project.

                  Ron Jeffries
                  www.XProgramming.com
                  If another does not intend offense, it is wrong for me to seek it;
                  if another does indeed intend offense, it is foolish for me to permit it.
                  -- Kelly Easterley



                  [Non-text portions of this message have been removed]
                • RonJeffries
                  George ... ... Any ideas on WHY to measure team productivity? Ron Jeffries www.XProgramming.com Wisdom begins when we understand the difference between that
                  Message 8 of 18 , Jun 21 11:44 AM
                    George ...

                    On Jun 21, 2012, at 2:38 PM, George Dinwiddie wrote:

                    > Any ideas on how to measure team productivity?


                    Any ideas on WHY to measure team productivity?

                    Ron Jeffries
                    www.XProgramming.com
                    Wisdom begins when we understand the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell



                    [Non-text portions of this message have been removed]
                  • George Dinwiddie
                    Ron, ... Another good question. My initial point is that the rest of the sentence is superfluous. Even if we think we have a good reason (or are just curious),
                    Message 9 of 18 , Jun 21 12:03 PM
                      Ron,

                      On 6/21/12 2:44 PM, RonJeffries wrote:
                      > George ...
                      >
                      > On Jun 21, 2012, at 2:38 PM, George Dinwiddie wrote:
                      >
                      >> Any ideas on how to measure team productivity?
                      >
                      >
                      > Any ideas on WHY to measure team productivity?

                      Another good question. My initial point is that the rest of the sentence
                      is superfluous. Even if we think we have a good reason (or are just
                      curious), we have /no/ way to measure this concept "productivity" in
                      knowledge work.

                      - George

                      --
                      ----------------------------------------------------------------------
                      * George Dinwiddie * http://blog.gdinwiddie.com
                      Software Development http://www.idiacomputing.com
                      Consultant and Coach http://www.agilemaryland.org
                      ----------------------------------------------------------------------
                    • RonJeffries
                      Hi George, ... Yes, I do fully agree, of course. In addition, I ve never seen a proposed measure that I could not immediately game to my advantage. Ron
                      Message 10 of 18 , Jun 21 12:17 PM
                        Hi George,

                        On Jun 21, 2012, at 3:03 PM, George Dinwiddie wrote:

                        > My initial point is that the rest of the sentence
                        > is superfluous. Even if we think we have a good reason (or are just
                        > curious), we have /no/ way to measure this concept "productivity" in
                        > knowledge work.


                        Yes, I do fully agree, of course. In addition, I've never seen a proposed measure that I could not immediately game to my advantage.

                        Ron Jeffries
                        www.XProgramming.com
                        I try to Zen through it and keep my voice very mellow and low.
                        Inside I am screaming and have a machine gun.
                        Yin and Yang I figure.
                        -- Tom Jeffries



                        [Non-text portions of this message have been removed]
                      • Dave Rooney
                        Hi Paul, ... I saw Scott give a presentation with Jeff Sutherland at Agile 2010 about this. During the session, I called BS to all of the numbers he and Jeff
                        Message 11 of 18 , Jun 21 12:42 PM
                          Hi Paul,

                          On 2012-06-21, at 1:27 PM, Paul Epps wrote:

                          > I saw a presentation by Scott Downey last night at Agile SoCal on hyperproductive Scrum teams. Downey defines a hyperproductive team as a team that achieves a 500% increase over its initial velocity, as measured in story points.
                          >

                          I saw Scott give a presentation with Jeff Sutherland at Agile 2010 about this. During the session, I called BS to all of the numbers he and Jeff said you should track, but the crowd ate it up. Clearly I was swimming upstream against a torrent.

                          I had a discussion with another conference attendee afterwards, someone who had been a VP of development. His org had a policy that allowed employees to order pizza if they were working late into supper hours. He said the only metric he used to evaluate whether he needed to ask some questions was the number of pizzas ordered in a given week. He didn't need velocity, he didn't need utilization vs. capacity, he didn't need *any* of the BS numbers that Downey & Sutherland say are critical.

                          This is my opinion, but I do know that it's shared with other people: Hyperproductivity is marketing BS that has done much more harm than good by being the Promised Land of Scrum. Your mileage (and opinion) may vary, of course. :)

                          Dave Rooney
                          daverooneyca@...



                          >
                          > I've seen Ron Jeffries recommend not using story points, instead sizing stories consistently around a couple of days, and counting stories instead of points. That's always seemed like a good idea to me, but after Downey's presentation, I was trying to think about how to measure productivity gains when sizing stories at a couple of days.
                          >
                          > To take a simple example, if I can do a story every two days, then I can do five stories in a two-week sprint. By definition (story = 2 days), I will continue to complete five stories per sprint forever. In order to demonstrate improvement over time, I would need a new measurement, e.g., value, right?
                          >
                          > Any ideas on how to measure team productivity over time using consistent story sizes?
                          >
                          > Thanks...
                          >
                          > Paul Epps
                          >
                          >



                          [Non-text portions of this message have been removed]
                        • Adrian Howard
                          ... The scary thing about that metric is that I ve seen too many places where they would consider more pizza orders to be a *good* thing :-) Adrian --
                          Message 12 of 18 , Jun 21 12:50 PM
                            On 21 Jun 2012, at 20:42, Dave Rooney wrote:

                            > He said the only metric he used to evaluate whether he needed to ask some questions was the number of pizzas ordered in a given week.

                            The scary thing about that metric is that I've seen too many places where they would consider more pizza orders to be a *good* thing :-)

                            Adrian
                            --
                            http://quietstars.com adrianh@... twitter.com/adrianh
                            t. +44 (0)7752 419080 skype adrianjohnhoward pinboard.in/u:adrianh
                          • M. Manca
                            Il 21/06/2012 21:17, RonJeffries ha scritto: Hi Ron and George, the point is always the same, some questions seem done by a manager that needs to know when
                            Message 13 of 18 , Jun 21 12:54 PM
                              Il 21/06/2012 21:17, RonJeffries ha scritto:
                              Hi Ron and George,

                              the point is always the same, some questions seem done by a manager that
                              needs to know when things will be done (not agile manager) and others by
                              a perfect XP team leader.
                              I think that both may be superfluous in a perfect XP contest and both
                              may be necessary in a not XP contest. The problem is what Scott Downey
                              said during the presentation.
                              >
                              >
                              > Hi George,
                              >
                              > On Jun 21, 2012, at 3:03 PM, George Dinwiddie wrote:
                              >
                              > > My initial point is that the rest of the sentence
                              > > is superfluous. Even if we think we have a good reason (or are just
                              > > curious), we have /no/ way to measure this concept "productivity" in
                              > > knowledge work.
                              >
                              > Yes, I do fully agree, of course. In addition, I've never seen a
                              > proposed measure that I could not immediately game to my advantage.
                              >
                              > Ron Jeffries
                              > www.XProgramming.com
                              > I try to Zen through it and keep my voice very mellow and low.
                              > Inside I am screaming and have a machine gun.
                              > Yin and Yang I figure.
                              > -- Tom Jeffries
                              >
                              > [Non-text portions of this message have been removed]
                              >
                              >



                              [Non-text portions of this message have been removed]
                            • Paul Epps
                              ... Good observation! Thanks everyone for the helpful replies. pe
                              Message 14 of 18 , Jun 21 4:20 PM
                                --- In extremeprogramming@yahoogroups.com, Steven Gordon <sgordonphd@...> wrote:
                                >
                                > (BTW, I really enjoy the pushback I get from management on that - that
                                > development should be responsible for precise enough estimations to support
                                > all sorts of management metrics whereas the business does not have to be
                                > responsible for determining the actual value of being delivered what they
                                > ask for).

                                Good observation!

                                Thanks everyone for the helpful replies.

                                pe
                              • Tim Ottinger
                                ... What is the relation between the two?  If the value is low, would you improve it by increasing or decreasing the rate of production?  It sounds to me
                                Message 15 of 18 , Jun 22 2:17 PM
                                  > Downey described the purpose with this user story: AS A Scrum Product Owner who
                                  > is trying to evaluate the efficacy of the product directions I have chosen, I
                                  > NEED a reliable way to measure the increased value
                                  > contribution of the Team sprint-over-sprint SO THAT I can compare the Team's
                                  > rate of value contribution increase to the changes in revenue we are generating
                                  > and adjust our direction if the value isn't being realized.

                                  What is the relation between the two? 

                                  If the value is low, would you improve it by increasing or decreasing the rate of production? 

                                  It sounds to me like checking the speedometer to determine the direction of travel.
                                   
                                  Tim Ottinger
                                  http://IndustrialLogic.com/
                                • JeffGrigg
                                  ... Knowledge Gained, divided by Time. ;-
                                  Message 16 of 18 , Jun 23 1:27 AM
                                    --- George Dinwiddie <lists@...> wrote:
                                    > [W]e have /no/ way to measure this concept "productivity" in
                                    > knowledge work.

                                    Knowledge Gained, divided by Time.


                                    ;->
                                  • JeffGrigg
                                    ... Oh; so all I have to do to be hyper-productive is start out really crappy. Hey; I think I can do that! ;-
                                    Message 17 of 18 , Jun 23 1:29 AM
                                      --- "Paul Epps" <paul@...> wrote:
                                      > ... Downey defines a hyperproductive team as a team that
                                      > achieves a 500% increase over its initial velocity, as
                                      > measured in story points.

                                      Oh; so all I have to do to be hyper-productive is start out really crappy. Hey; I think I can do that! >;->
                                    • Steve Freeman
                                      ... funny you should say that.... have you seen the baseline Sutherland s team started from? S.
                                      Message 18 of 18 , Jun 24 4:01 AM
                                        On 23 Jun 2012, at 09:29, JeffGrigg wrote:
                                        > --- "Paul Epps" <paul@...> wrote:
                                        >> ... Downey defines a hyperproductive team as a team that
                                        >> achieves a 500% increase over its initial velocity, as
                                        >> measured in story points.
                                        >
                                        > Oh; so all I have to do to be hyper-productive is start out really crappy. Hey; I think I can do that! >;->

                                        funny you should say that.... have you seen the baseline Sutherland's team started from?

                                        S.
                                      Your message has been successfully submitted and would be delivered to recipients shortly.