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

SCRUM performance measurements

Expand Messages
  • Patrick Steyaert
    *.*; While introducing SCRUM to software organisations, the question pops up of what *bottom-line* improvements can be expected - decreasing number of bugs,
    Message 1 of 19 , Sep 26, 2004
      *.*;

      While introducing SCRUM to software organisations, the question pops up of
      what *bottom-line* improvements can be expected - decreasing number of bugs,
      lower cost of quality, faster time to deliver, ...
      My question is whether there are people out there, that have actually
      measured such improvements, and whether such measurements have been
      collected ? Are there experiences in using such measurements to actually
      track progress of introducing SCRUM into an organisation ?
      All input welcome.

      Patrick.
    • Steven Gordon
      Of course, this would require that an organization was already capable of accurately gathering accurate meaningful metrics and yet was feeling enough pain to
      Message 2 of 19 , Sep 26, 2004
        Of course, this would require that an organization was already
        capable of accurately gathering accurate meaningful metrics
        and yet was feeling enough pain to consider trying SCRUM.

        I would suspect that this is rarely the case, so there will rarely
        be a baseline to even establish measurable improvement against.

        -----Original Message-----
        From: Patrick Steyaert [mailto:steyaert.patrick@...]
        Sent: Sun 9/26/2004 11:24 AM
        To: scrumdevelopment@yahoogroups.com
        Cc:
        Subject: [scrumdevelopment] SCRUM performance measurements

        *.*;

        While introducing SCRUM to software organisations, the question pops up of
        what *bottom-line* improvements can be expected - decreasing number of bugs,
        lower cost of quality, faster time to deliver, ...
        My question is whether there are people out there, that have actually
        measured such improvements, and whether such measurements have been
        collected ? Are there experiences in using such measurements to actually
        track progress of introducing SCRUM into an organisation ?
        All input welcome.

        Patrick.



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



        Yahoo! Groups Sponsor
        ADVERTISEMENT
        click here <http://us.ard.yahoo.com/SIG=129u2ro3a/M=295196.4901138.6071305.3001176/D=groups/S=1707209021:HM/EXP=1096309677/A=2128215/R=0/SIG=10se96mf6/*http://companion.yahoo.com>
        <http://us.adserver.yahoo.com/l?M=295196.4901138.6071305.3001176/D=groups/S=:HM/A=2128215/rand=403396369>

        _____

        Yahoo! Groups Links


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

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

        * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> .
      • Schiel James - SHS Malvern
        Patrick, one metric I ve been able to gather has to do with the amount of time each day that each member of the team is recording spent against tasks in the
        Message 3 of 19 , Sep 26, 2004
          Patrick, one metric I've been able to gather has to do with the amount of
          time each day that each member of the team is recording spent against tasks
          in the Sprint. One of the things that is supposed to happen in the Sprint
          (because of the increased accountability and the support of the ScrumMaster
          to remove identified obstacles) is that each developer should be able to
          focus more and more time on the Sprint and not be sidetracked during the
          course of the Sprint. My experience so far shows a measurable increase in
          actual developer time when compared to non-Scrum iterations.

          I'm interested in hearing experiences from others on this too -- I'm working
          on other metrics that I can use to convince senior management of the
          usefulness of Scrum.

          Jim Schiel
          Siemens Medical Solutions, Malvern, PA

          -----Original Message-----
          From: Steven Gordon [mailto:sagordon@...]
          Sent: Sunday, September 26, 2004 8:03 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: RE: [scrumdevelopment] SCRUM performance measurements


          Of course, this would require that an organization was already
          capable of accurately gathering accurate meaningful metrics
          and yet was feeling enough pain to consider trying SCRUM.

          I would suspect that this is rarely the case, so there will rarely
          be a baseline to even establish measurable improvement against.

          -----Original Message-----
          From: Patrick Steyaert [mailto:steyaert.patrick@...]
          Sent: Sun 9/26/2004 11:24 AM
          To: scrumdevelopment@yahoogroups.com
          Cc:
          Subject: [scrumdevelopment] SCRUM performance measurements

          *.*;

          While introducing SCRUM to software organisations, the question pops up of
          what *bottom-line* improvements can be expected - decreasing number of bugs,
          lower cost of quality, faster time to deliver, ...
          My question is whether there are people out there, that have actually
          measured such improvements, and whether such measurements have been
          collected ? Are there experiences in using such measurements to actually
          track progress of introducing SCRUM into an organisation ?
          All input welcome.

          Patrick.



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



          Yahoo! Groups Sponsor
          ADVERTISEMENT
          click here
          <http://us.ard.yahoo.com/SIG=129u2ro3a/M=295196.4901138.6071305.3001176/D=gr
          oups/S=1707209021:HM/EXP=1096309677/A=2128215/R=0/SIG=10se96mf6/*http://comp
          anion.yahoo.com>

          <http://us.adserver.yahoo.com/l?M=295196.4901138.6071305.3001176/D=groups/S=
          :HM/A=2128215/rand=403396369>

          _____

          Yahoo! Groups Links


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

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

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



          -------------------------------------------------------------------------------
          This message and any included attachments are from Siemens Medical Solutions
          USA, Inc. and are intended only for the addressee(s).
          The information contained herein may include trade secrets or privileged or
          otherwise confidential information. Unauthorized review, forwarding, printing,
          copying, distributing, or using such information is strictly prohibited and may
          be unlawful. If you received this message in error, or have reason to believe
          you are not authorized to receive it, please promptly delete this message and
          notify the sender by e-mail with a copy to Central.SecurityOffice@...

          Thank you
        • Steven Gordon
          Jim, How can you make the claim clipped below from the middle of your posting unless this metric was being tracked before starting to do Scrum? What does this
          Message 4 of 19 , Sep 26, 2004
            Jim,

            How can you make the claim clipped below from the middle of your
            posting unless this metric was being tracked before starting to do
            Scrum?

            What does this metric (actual developer time spent on sprint tasks)
            even mean outside of the context of Scrum anyway?

            Steven Gordon

            -----Original Message-----
            From: Schiel James - SHS Malvern [mailto:james.schiel@...]
            Sent: Sun 9/26/2004 7:52 PM
            To: 'scrumdevelopment@yahoogroups.com'
            Cc:
            Subject: RE: [scrumdevelopment] SCRUM performance measurements



            <clip>

            My experience so far shows a measurable increase in
            actual developer time when compared to non-Scrum iterations.

            <clip>

            Jim Schiel
            Siemens Medical Solutions, Malvern, PA
          • Schiel James - SHS Malvern
            You can t -- I used data gathered through our project management software to determine the values before and after the Sprints began. So, while we weren t
            Message 5 of 19 , Sep 27, 2004
              RE: [scrumdevelopment] SCRUM performance measurements
              You can't -- I used data gathered through our project management software to determine the values before and after the Sprints began. So, while we weren't collecting the metric prior to Scrum per se, we did have access to the numbers we needed to determine the values back into 2003.
               
              As for your second question -- I should clarify -- the metric itself (actual time vs. estimated time) is a measure of how many hours of effort each week are posted against the project's tasks as compared to the number of hours that were expected to be posted based on the schedule (whether those tasks are part of a Sprint Backlog or not is not relevant). For example, if I have tasks this week that I'm supposed to log 30 hours against and I log 25 hours instead, I've only worked 83% (25 divided by 30). For whatever reason, I didn't log all thirty -- this might be the result of unplanned sick time but, more importantly, it may be a result of unplanned activity that you really don't want your developers getting involved in.
               
              One thing to note here is the difference in how you plan estimated hours. Before Scrum, when we planned out the task schedule for each iteration, a developer might have 34 hours one week, 21 hours the next week, 28 hours the week after, and so on. When we started Scrum and planned our a Sprint, we simply take the number of hours that a developer is allocated to the project (in most cases, this is 30 hours -- leaving 10 hours for education, emails, non-project group meetings, etc.). As an aside, if the measurements that I'm seeing hold up, we'll probably increase our allocations to 32 hours per week soon and see what happens.
               
              In my group (as with many others), we provide third level support for everything that we write. Therefore, we get continual pressure to provide assistance to our support group as well as other development groups using our tools and components. That pressure, not properly controlled or monitored, results in a wearing down of your developers actual allocations to your projects because those developers begin responding to every call and interruption as if it was more important than their project (which it might be, but there's no opportunity to check before the time is lost).
               
              One of the reasons we started using Scrum was that the ongoing and continual collaboration and accountability was seen as a way to encourage the developers on our project teams to focus more on the development tasks and leave the support to the small team of developers set aside each month to respond to support issues. As we began running Sprints, our actual vs. estimated time immediately began to climb. In a number of cases during the Sprint we just finished, actual vs. estimated climbed over 100% (which doesn't necessarily indicate overtime -- although some was spent -- it actually means that developers were closing in on putting all eight hours a day into the project rather than responding to every interruption that came by).
               
              Now, I should be clear about something else too -- whether a developer achieves 90% of their estimated hours or 110%, this metric, by itself, does not mean that everything's going perfectly.  There's still the matter of whether or not your developer spent eight hours on a three hour task. To untangle this issue, you have to turn to Earned Value reporting and/or the Sprint Burndown chart to see where you're going.
               
              However, as a indicator of how well Scrum is keeping your developers focused on the project and not continually task-switching from one interruption to another, the actual vs. estimated hours per week works pretty well.
              -----Original Message-----
              From: Steven Gordon [mailto:sagordon@...]
              Sent: Monday, September 27, 2004 12:05 AM
              To: scrumdevelopment@yahoogroups.com
              Subject: RE: [scrumdevelopment] SCRUM performance measurements

              Jim,
               
              How can you make the claim clipped below from the middle of your
              posting unless this metric was being tracked before starting to do
              Scrum?
               
              What does this metric (actual developer time spent on sprint tasks)
              even mean outside of the context of Scrum anyway?
               
              Steven Gordon
              -----Original Message-----
              From: Schiel James - SHS Malvern [mailto:james.schiel@...]
              Sent: Sun 9/26/2004 7:52 PM
              To: 'scrumdevelopment@yahoogroups.com'
              Cc:
              Subject: RE: [scrumdevelopment] SCRUM performance measurements

              <clip>

               My experience so far shows a measurable increase in
              actual developer time when compared to non-Scrum iterations.

              <clip>

              Jim Schiel
              Siemens Medical Solutions, Malvern, PA

              -------------------------------------------------------------------------------
              This message and any included attachments are from Siemens Medical Solutions
              USA, Inc. and are intended only for the addressee(s).
              The information contained herein may include trade secrets or privileged or
              otherwise confidential information. Unauthorized review, forwarding, printing,
              copying, distributing, or using such information is strictly prohibited and may
              be unlawful. If you received this message in error, or have reason to believe
              you are not authorized to receive it, please promptly delete this message and
              notify the sender by e-mail with a copy to Central.SecurityOffice@...

              Thank you
            • Steven Gordon
              Thanks - with metrics you have to be very clear what you are actually measuring. It should, of course, not be surprising that Scrum would decrease interuptions
              Message 6 of 19 , Sep 27, 2004
                Thanks - with metrics you have to be very clear what you are actually measuring.

                It should, of course, not be surprising that Scrum would decrease interuptions and
                increase focus, but it is great to have a real measure of that. Still, in an endeavor
                as complex as software development, the reason for a change in a metric is never
                completely clear. For example, a large part of the improvement in this particular
                metric may just be that the more flexible task definitions in a sprint makes it possible
                to classify activities as being on task that were not considered on task under the
                previous planning regiment, which was likely to be more detailed and less flexible.

                -----Original Message-----
                From: Schiel James - SHS Malvern [mailto:james.schiel@...]
                Sent: Mon 9/27/2004 6:52 AM
                To: 'scrumdevelopment@yahoogroups.com'
                Cc:
                Subject: RE: [scrumdevelopment] SCRUM performance measurements


                You can't -- I used data gathered through our project management software to determine the values before and after the Sprints began. So, while we weren't collecting the metric prior to Scrum per se, we did have access to the numbers we needed to determine the values back into 2003.

                As for your second question -- I should clarify -- the metric itself (actual time vs. estimated time) is a measure of how many hours of effort each week are posted against the project's tasks as compared to the number of hours that were expected to be posted based on the schedule (whether those tasks are part of a Sprint Backlog or not is not relevant). For example, if I have tasks this week that I'm supposed to log 30 hours against and I log 25 hours instead, I've only worked 83% (25 divided by 30). For whatever reason, I didn't log all thirty -- this might be the result of unplanned sick time but, more importantly, it may be a result of unplanned activity that you really don't want your developers getting involved in.

                One thing to note here is the difference in how you plan estimated hours. Before Scrum, when we planned out the task schedule for each iteration, a developer might have 34 hours one week, 21 hours the next week, 28 hours the week after, and so on. When we started Scrum and planned our a Sprint, we simply take the number of hours that a developer is allocated to the project (in most cases, this is 30 hours -- leaving 10 hours for education, emails, non-project group meetings, etc.). As an aside, if the measurements that I'm seeing hold up, we'll probably increase our allocations to 32 hours per week soon and see what happens.

                In my group (as with many others), we provide third level support for everything that we write. Therefore, we get continual pressure to provide assistance to our support group as well as other development groups using our tools and components. That pressure, not properly controlled or monitored, results in a wearing down of your developers actual allocations to your projects because those developers begin responding to every call and interruption as if it was more important than their project (which it might be, but there's no opportunity to check before the time is lost).

                One of the reasons we started using Scrum was that the ongoing and continual collaboration and accountability was seen as a way to encourage the developers on our project teams to focus more on the development tasks and leave the support to the small team of developers set aside each month to respond to support issues. As we began running Sprints, our actual vs. estimated time immediately began to climb. In a number of cases during the Sprint we just finished, actual vs. estimated climbed over 100% (which doesn't necessarily indicate overtime -- although some was spent -- it actually means that developers were closing in on putting all eight hours a day into the project rather than responding to every interruption that came by).

                Now, I should be clear about something else too -- whether a developer achieves 90% of their estimated hours or 110%, this metric, by itself, does not mean that everything's going perfectly. There's still the matter of whether or not your developer spent eight hours on a three hour task. To untangle this issue, you have to turn to Earned Value reporting and/or the Sprint Burndown chart to see where you're going.

                However, as a indicator of how well Scrum is keeping your developers focused on the project and not continually task-switching from one interruption to another, the actual vs. estimated hours per week works pretty well.


                -------------------------------------------------------------------------------
                This message and any included attachments are from Siemens Medical Solutions
                USA, Inc. and are intended only for the addressee(s).
                The information contained herein may include trade secrets or privileged or
                otherwise confidential information. Unauthorized review, forwarding, printing,
                copying, distributing, or using such information is strictly prohibited and may
                be unlawful. If you received this message in error, or have reason to believe
                you are not authorized to receive it, please promptly delete this message and
                notify the sender by e-mail with a copy to Central.SecurityOffice@...

                Thank you
              • Schiel James - SHS Malvern
                No argument there, Steve. That s why I believe that a single metric indicates extremely little (and we should be careful interpreting too much from a single
                Message 7 of 19 , Sep 27, 2004
                  RE: [scrumdevelopment] SCRUM performance measurements
                  No argument there, Steve. That's why I believe that a single metric indicates extremely little (and we should be careful interpreting too much from a single metric and a single instance of the same metric).  But, in combination with multiple instances and other complementary metrics, a true picture (if not the causes) can be illuminated.
                  -----Original Message-----
                  From: Steven Gordon [mailto:sagordon@...]
                  Sent: Monday, September 27, 2004 10:12 AM
                  To: scrumdevelopment@yahoogroups.com
                  Subject: RE: [scrumdevelopment] SCRUM performance measurements

                  Thanks - with metrics you have to be very clear what you are actually measuring.
                   
                  It should, of course, not be surprising that Scrum would decrease interuptions and
                  increase focus, but it is great to have a real measure of that.  Still, in an endeavor
                  as complex as software development, the reason for a change in a metric is never
                  completely clear.  For example, a large part of the improvement in this particular
                  metric may just be that the more flexible task definitions in a sprint makes it possible
                  to classify activities as being on task that were not considered on task under the
                  previous planning regiment, which was likely to be more detailed and less flexible.
                  -----Original Message-----
                  From: Schiel James - SHS Malvern [mailto:james.schiel@...]
                  Sent: Mon 9/27/2004 6:52 AM
                  To: 'scrumdevelopment@yahoogroups.com'
                  Cc:
                  Subject: RE: [scrumdevelopment] SCRUM performance measurements

                  You can't -- I used data gathered through our project management software to determine the values before and after the Sprints began. So, while we weren't collecting the metric prior to Scrum per se, we did have access to the numbers we needed to determine the values back into 2003.
                   
                  As for your second question -- I should clarify -- the metric itself (actual time vs. estimated time) is a measure of how many hours of effort each week are posted against the project's tasks as compared to the number of hours that were expected to be posted based on the schedule (whether those tasks are part of a Sprint Backlog or not is not relevant). For example, if I have tasks this week that I'm supposed to log 30 hours against and I log 25 hours instead, I've only worked 83% (25 divided by 30). For whatever reason, I didn't log all thirty -- this might be the result of unplanned sick time but, more importantly, it may be a result of unplanned activity that you really don't want your developers getting involved in.
                   
                  One thing to note here is the difference in how you plan estimated hours. Before Scrum, when we planned out the task schedule for each iteration, a developer might have 34 hours one week, 21 hours the next week, 28 hours the week after, and so on. When we started Scrum and planned our a Sprint, we simply take the number of hours that a developer is allocated to the project (in most cases, this is 30 hours -- leaving 10 hours for education, emails, non-project group meetings, etc.). As an aside, if the measurements that I'm seeing hold up, we'll probably increase our allocations to 32 hours per week soon and see what happens.
                   
                  In my group (as with many others), we provide third level support for everything that we write. Therefore, we get continual pressure to provide assistance to our support group as well as other development groups using our tools and components. That pressure, not properly controlled or monitored, results in a wearing down of your developers actual allocations to your projects because those developers begin responding to every call and interruption as if it was more important than their project (which it might be, but there's no opportunity to check before the time is lost).
                   
                  One of the reasons we started using Scrum was that the ongoing and continual collaboration and accountability was seen as a way to encourage the developers on our project teams to focus more on the development tasks and leave the support to the small team of developers set aside each month to respond to support issues. As we began running Sprints, our actual vs. estimated time immediately began to climb. In a number of cases during the Sprint we just finished, actual vs. estimated climbed over 100% (which doesn't necessarily indicate overtime -- although some was spent -- it actually means that developers were closing in on putting all eight hours a day into the project rather than responding to every interruption that came by).
                   
                  Now, I should be clear about something else too -- whether a developer achieves 90% of their estimated hours or 110%, this metric, by itself, does not mean that everything's going perfectly.  There's still the matter of whether or not your developer spent eight hours on a three hour task. To untangle this issue, you have to turn to Earned Value reporting and/or the Sprint Burndown chart to see where you're going.
                   
                  However, as a indicator of how well Scrum is keeping your developers focused on the project and not continually task-switching from one interruption to another, the actual vs. estimated hours per week works pretty well.
                  -------------------------------------------------------------------------------
                  This message and any included attachments are from Siemens Medical Solutions
                  USA, Inc. and are intended only for the addressee(s).
                  The information contained herein may include trade secrets or privileged or
                  otherwise confidential information. Unauthorized review, forwarding, printing,
                  copying, distributing, or using such information is strictly prohibited and may
                  be unlawful. If you received this message in error, or have reason to believe
                  you are not authorized to receive it, please promptly delete this message and
                  notify the sender by e-mail with a copy to Central.SecurityOffice@...

                  Thank you
                  -------------------------------------------------------------------------------
                  This message and any included attachments are from Siemens Medical Solutions
                  USA, Inc. and are intended only for the addressee(s).
                  The information contained herein may include trade secrets or privileged or
                  otherwise confidential information. Unauthorized review, forwarding, printing,
                  copying, distributing, or using such information is strictly prohibited and may
                  be unlawful. If you received this message in error, or have reason to believe
                  you are not authorized to receive it, please promptly delete this message and
                  notify the sender by e-mail with a copy to Central.SecurityOffice@...

                  Thank you
                • Patrick Steyaert
                  It should not necessarily be measurements *before* scrum introduction, but during a scrum introduction. (the scenario being: we are going to introduce scrum,
                  Message 8 of 19 , Sep 27, 2004
                    It should not necessarily be measurements *before* scrum introduction, but
                    during a scrum introduction. (the scenario being: we are going to introduce
                    scrum, how can we measure improvements, define measurements, baseline,
                    measure again after a couple of sprint, etc..).
                    To me that doesn't seem to be an unreasonable thing to do. Knowing of course
                    that defining good measurements can be tricky.


                    BTW. In the SCRUM certification class, Ken indicated certain percentage of
                    performance improvements ... I was wondering whether they were based on
                    measurement ??



                    -----Original Message-----
                    From: Steven Gordon [mailto:sagordon@...]
                    Sent: Monday, September 27, 2004 2:03 AM
                    To: scrumdevelopment@yahoogroups.com
                    Subject: RE: [scrumdevelopment] SCRUM performance measurements


                    Of course, this would require that an organization was already
                    capable of accurately gathering accurate meaningful metrics
                    and yet was feeling enough pain to consider trying SCRUM.

                    I would suspect that this is rarely the case, so there will rarely
                    be a baseline to even establish measurable improvement against.

                    -----Original Message-----
                    From: Patrick Steyaert [mailto:steyaert.patrick@...]
                    Sent: Sun 9/26/2004 11:24 AM
                    To: scrumdevelopment@yahoogroups.com
                    Cc:
                    Subject: [scrumdevelopment] SCRUM performance measurements

                    *.*;

                    While introducing SCRUM to software organisations, the question pops up of
                    what *bottom-line* improvements can be expected - decreasing number of bugs,
                    lower cost of quality, faster time to deliver, ...
                    My question is whether there are people out there, that have actually
                    measured such improvements, and whether such measurements have been
                    collected ? Are there experiences in using such measurements to actually
                    track progress of introducing SCRUM into an organisation ?
                    All input welcome.

                    Patrick.



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



                    Yahoo! Groups Sponsor
                    ADVERTISEMENT
                    click here
                    <http://us.ard.yahoo.com/SIG=129u2ro3a/M=295196.4901138.6071305.3001176/D=gr
                    oups/S=1707209021:HM/EXP=1096309677/A=2128215/R=0/SIG=10se96mf6/*http://comp
                    anion.yahoo.com>

                    <http://us.adserver.yahoo.com/l?M=295196.4901138.6071305.3001176/D=groups/S=
                    :HM/A=2128215/rand=403396369>

                    _____

                    Yahoo! Groups Links


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

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

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






                    To Post a message, send it to: scrumdevelopment@...
                    To Unsubscribe, send a blank message to:
                    scrumdevelopment-unsubscribe@...
                    Yahoo! Groups Links
                  • Mike Cohn
                    Hi Patrick-- Sorry for taking a few days to reply but I was working on exactly this question for a team this week and wanted to have solid answers. This team
                    Message 9 of 19 , Sep 29, 2004
                      Hi Patrick--
                      Sorry for taking a few days to reply but I was working on exactly this
                      question for a team this week and wanted to have solid answers.

                      This team used a waterfall process from 2001-2003. I switched them to Scrum
                      at the start of this year. They write in Java. Here are some measurements:

                      2001-03 2004
                      Lines of code per programmer-month 389 1206
                      Defects per thousand lines 10 2.9

                      Some code metrics as measured in Feb 2004 (2 months after Scrumming started)
                      and today. These show improvements in the code being written:

                      2/04 9/04
                      # of packages 43 118
                      # of classes 718 1,128
                      # of methods 10,451 14,424
                      lines of code 119,950 145,897
                      lines per class 159 121
                      Methods per class 14.6 12.8
                      Lines per class 10 8.4
                      Cyclomatic complexity 2.3 2.1

                      Keep in mind that things like "methods per class" going down so much means
                      the new code written using Scrum went down even further because the overall
                      average is shown above, not just totals for the new code in the right
                      column.

                      Note that throughout, lines of code is "non-comment source statements". A
                      caveat: I didn't count the JSP lines in the 2001-2003 version (not many of
                      them as much had been migrated back into servlets) or the velocity templates
                      in the 2004 system. If those were measured, things would look even better
                      for the latter metrics.

                      I think these show a very compelling advantage to Scrum. This team became
                      more than 300% as productive (as measured my lines, which is somewhat
                      questionable as a measure) and has 80% fewer defects. More importantly, the
                      CEO is ecstatic about what the team has achieved. They're 3x faster in lines
                      but are probably 10x in delivering business value. For example, the team's
                      best programmer spent all of 2003 on a feature that has still not been used
                      ONCE. That doesn't happen with Scrum.

                      Let me know if you have any questions,

                      --Mike Cohn
                      Author of User Stories Applied for Agile Software Development
                      www.mountaingoatsoftware.com
                      www.userstories.com

                      -----Original Message-----
                      From: Patrick Steyaert [mailto:steyaert.patrick@...]
                      Sent: Sunday, September 26, 2004 12:25 PM
                      To: scrumdevelopment@yahoogroups.com
                      Subject: [scrumdevelopment] SCRUM performance measurements


                      *.*;

                      While introducing SCRUM to software organisations, the question pops up of
                      what *bottom-line* improvements can be expected - decreasing number of bugs,
                      lower cost of quality, faster time to deliver, ...
                      My question is whether there are people out there, that have actually
                      measured such improvements, and whether such measurements have been
                      collected ? Are there experiences in using such measurements to actually
                      track progress of introducing SCRUM into an organisation ?
                      All input welcome.

                      Patrick.




                      To Post a message, send it to: scrumdevelopment@...
                      To Unsubscribe, send a blank message to:
                      scrumdevelopment-unsubscribe@...
                      Yahoo! Groups Links
                    • Victor Szalvay
                      I figure this is obvious to agilists but I have been fielding a lot questions lately on dubious metrics. Metrics are a tricky thing that must be selected very
                      Message 10 of 19 , Sep 29, 2004
                        I figure this is obvious to agilists but I have been fielding a lot
                        questions lately on dubious metrics. Metrics are a tricky thing that
                        must be selected very thoughtfully. For example, it strikes me that
                        lines of code (LOC) as a metric is dubious because it encourages
                        developers to increase volume of code produced. In most OO
                        environments an overarching quality goal is to increase code re-use
                        and decrease repetition. LOC on the other hand encourages developers
                        to cut-n-paste their way to more lines of code, decreasing overall
                        maintainability and quality. If you take a messy OO project and
                        reduce the total lines of code by refactoring, I would call that
                        progress...

                        It's the same story as other "metrics", some developers will find a
                        way to make themselves look good in light of the metric. Some folks
                        want to compare estimated to actuals still. The developers will find
                        a way to make them match up, at the expense of something else (most
                        often quality).

                        This is why defining good metrics is so tricky.

                        (clarifier: I know Mike doesn't advocate these metrics, just a
                        commentary after reading his post.)

                        -- Victor Szalvay

                        --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                        wrote:
                        > Hi Patrick--
                        > Sorry for taking a few days to reply but I was working on exactly
                        this
                        > question for a team this week and wanted to have solid answers.
                        >
                        > This team used a waterfall process from 2001-2003. I switched them
                        to Scrum
                        > at the start of this year. They write in Java. Here are some
                        measurements:
                        >
                        > 2001-03 2004
                        > Lines of code per programmer-month 389 1206
                        > Defects per thousand lines 10 2.9
                        >
                        > Some code metrics as measured in Feb 2004 (2 months after Scrumming
                        started)
                        > and today. These show improvements in the code being written:
                        >
                        > 2/04 9/04
                        > # of packages 43 118
                        > # of classes 718 1,128
                        > # of methods 10,451 14,424
                        > lines of code 119,950 145,897
                        > lines per class 159 121
                        > Methods per class 14.6 12.8
                        > Lines per class 10 8.4
                        > Cyclomatic complexity 2.3 2.1
                        >
                        > Keep in mind that things like "methods per class" going down so much
                        means
                        > the new code written using Scrum went down even further because the
                        overall
                        > average is shown above, not just totals for the new code in the
                        right
                        > column.
                        >
                        > Note that throughout, lines of code is "non-comment source
                        statements". A
                        > caveat: I didn't count the JSP lines in the 2001-2003 version (not
                        many of
                        > them as much had been migrated back into servlets) or the velocity
                        templates
                        > in the 2004 system. If those were measured, things would look even
                        better
                        > for the latter metrics.
                        >
                        > I think these show a very compelling advantage to Scrum. This team
                        became
                        > more than 300% as productive (as measured my lines, which is
                        somewhat
                        > questionable as a measure) and has 80% fewer defects. More
                        importantly, the
                        > CEO is ecstatic about what the team has achieved. They're 3x faster
                        in lines
                        > but are probably 10x in delivering business value. For example, the
                        team's
                        > best programmer spent all of 2003 on a feature that has still not
                        been used
                        > ONCE. That doesn't happen with Scrum.
                        >
                        > Let me know if you have any questions,
                        >
                        > --Mike Cohn
                        > Author of User Stories Applied for Agile Software Development
                        > www.mountaingoatsoftware.com
                        > www.userstories.com
                        >
                        > -----Original Message-----
                        > From: Patrick Steyaert [mailto:steyaert.patrick@p...]
                        > Sent: Sunday, September 26, 2004 12:25 PM
                        > To: scrumdevelopment@yahoogroups.com
                        > Subject: [scrumdevelopment] SCRUM performance measurements
                        >
                        >
                        > *.*;
                        >
                        > While introducing SCRUM to software organisations, the question pops
                        up of
                        > what *bottom-line* improvements can be expected - decreasing number
                        of bugs,
                        > lower cost of quality, faster time to deliver, ...
                        > My question is whether there are people out there, that have
                        actually
                        > measured such improvements, and whether such measurements have been
                        > collected ? Are there experiences in using such measurements to
                        actually
                        > track progress of introducing SCRUM into an organisation ?
                        > All input welcome.
                        >
                        > Patrick.
                        >
                        >
                        >
                        >
                        > To Post a message, send it to: scrumdevelopment@e...
                        > To Unsubscribe, send a blank message to:
                        > scrumdevelopment-unsubscribe@e...
                        > Yahoo! Groups Links
                      • Mike Cohn
                        Also, the developers don t know I captured those metrics. This was purely a research effort to measure the impact of Scrum on a team. I pointed out the most
                        Message 11 of 19 , Sep 29, 2004
                          Also, the developers don't know I captured those metrics. This was purely a
                          research effort to measure the impact of Scrum on a team. I pointed out the
                          most significant metric--that the CEO is ecstatic by what he sees day-by-day
                          and sprint-by-sprint.

                          --Mike Cohn
                          Author of User Stories Applied for Agile Software Development
                          www.mountaingoatsoftware.com
                          www.userstories.com

                          -----Original Message-----
                          From: Victor Szalvay [mailto:victor@...]
                          Sent: Wednesday, September 29, 2004 5:43 PM
                          To: scrumdevelopment@yahoogroups.com
                          Subject: [scrumdevelopment] Re: SCRUM performance measurements


                          I figure this is obvious to agilists but I have been fielding a lot
                          questions lately on dubious metrics. Metrics are a tricky thing that
                          must be selected very thoughtfully. For example, it strikes me that
                          lines of code (LOC) as a metric is dubious because it encourages
                          developers to increase volume of code produced. In most OO
                          environments an overarching quality goal is to increase code re-use
                          and decrease repetition. LOC on the other hand encourages developers
                          to cut-n-paste their way to more lines of code, decreasing overall
                          maintainability and quality. If you take a messy OO project and
                          reduce the total lines of code by refactoring, I would call that
                          progress...

                          It's the same story as other "metrics", some developers will find a
                          way to make themselves look good in light of the metric. Some folks
                          want to compare estimated to actuals still. The developers will find
                          a way to make them match up, at the expense of something else (most
                          often quality).

                          This is why defining good metrics is so tricky.

                          (clarifier: I know Mike doesn't advocate these metrics, just a
                          commentary after reading his post.)

                          -- Victor Szalvay

                          --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                          wrote:
                          > Hi Patrick--
                          > Sorry for taking a few days to reply but I was working on exactly
                          this
                          > question for a team this week and wanted to have solid answers.
                          >
                          > This team used a waterfall process from 2001-2003. I switched them
                          to Scrum
                          > at the start of this year. They write in Java. Here are some
                          measurements:
                          >
                          > 2001-03 2004
                          > Lines of code per programmer-month 389 1206
                          > Defects per thousand lines 10 2.9
                          >
                          > Some code metrics as measured in Feb 2004 (2 months after Scrumming
                          started)
                          > and today. These show improvements in the code being written:
                          >
                          > 2/04 9/04
                          > # of packages 43 118
                          > # of classes 718 1,128
                          > # of methods 10,451 14,424
                          > lines of code 119,950 145,897
                          > lines per class 159 121
                          > Methods per class 14.6 12.8
                          > Lines per class 10 8.4
                          > Cyclomatic complexity 2.3 2.1
                          >
                          > Keep in mind that things like "methods per class" going down so much
                          means
                          > the new code written using Scrum went down even further because the
                          overall
                          > average is shown above, not just totals for the new code in the
                          right
                          > column.
                          >
                          > Note that throughout, lines of code is "non-comment source
                          statements". A
                          > caveat: I didn't count the JSP lines in the 2001-2003 version (not
                          many of
                          > them as much had been migrated back into servlets) or the velocity
                          templates
                          > in the 2004 system. If those were measured, things would look even
                          better
                          > for the latter metrics.
                          >
                          > I think these show a very compelling advantage to Scrum. This team
                          became
                          > more than 300% as productive (as measured my lines, which is
                          somewhat
                          > questionable as a measure) and has 80% fewer defects. More
                          importantly, the
                          > CEO is ecstatic about what the team has achieved. They're 3x faster
                          in lines
                          > but are probably 10x in delivering business value. For example, the
                          team's
                          > best programmer spent all of 2003 on a feature that has still not
                          been used
                          > ONCE. That doesn't happen with Scrum.
                          >
                          > Let me know if you have any questions,
                          >
                          > --Mike Cohn
                          > Author of User Stories Applied for Agile Software Development
                          > www.mountaingoatsoftware.com
                          > www.userstories.com
                          >
                          > -----Original Message-----
                          > From: Patrick Steyaert [mailto:steyaert.patrick@p...]
                          > Sent: Sunday, September 26, 2004 12:25 PM
                          > To: scrumdevelopment@yahoogroups.com
                          > Subject: [scrumdevelopment] SCRUM performance measurements
                          >
                          >
                          > *.*;
                          >
                          > While introducing SCRUM to software organisations, the question pops
                          up of
                          > what *bottom-line* improvements can be expected - decreasing number
                          of bugs,
                          > lower cost of quality, faster time to deliver, ...
                          > My question is whether there are people out there, that have
                          actually
                          > measured such improvements, and whether such measurements have been
                          > collected ? Are there experiences in using such measurements to
                          actually
                          > track progress of introducing SCRUM into an organisation ?
                          > All input welcome.
                          >
                          > Patrick.
                          >
                          >
                          >
                          >
                          > To Post a message, send it to: scrumdevelopment@e...
                          > To Unsubscribe, send a blank message to:
                          > scrumdevelopment-unsubscribe@e...
                          > Yahoo! Groups Links




                          To Post a message, send it to: scrumdevelopment@...
                          To Unsubscribe, send a blank message to:
                          scrumdevelopment-unsubscribe@...
                          Yahoo! Groups Links
                        • John Gilman
                          Dear Mike (Ann Landers), your story raises an interesting question for me. I have begun working with a new team and am experiencing a new problem. The
                          Message 12 of 19 , Sep 29, 2004
                            Dear Mike (Ann Landers), your story raises an interesting question
                            for me. I have begun working with a new team and am experiencing a
                            new problem. The problem is with two of the developers (out of a
                            total of 3). They are really resistant to adopting the spirit of
                            what we are trying to do. They don't believe in it. They certainly
                            do not want to give up their offices and work in a common room with
                            the other team members from QA and PM, viewing it as some kind of
                            demotion and they are convinced that they will be less productive.

                            I fear that what one of them really wants is for me to hand him a
                            functional requirements document, he'll retire into his office and
                            come back at some point with workproduct. We aren't co-located yet
                            and he sleeps through meetings or checks his email on his laptop.
                            I'm a huge believer in building consensus and want conceptual buy-
                            in, but with this team have failed to date. The last team I worked
                            with got it from day one and we had zero issues of this type.

                            So here is my question. Did you have any issues like this with the
                            team that you took from waterfall to agile? Have you ever told
                            anyone "here is how we are doing things and it's my way or the
                            highway"?

                            John

                            --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                            wrote:
                            > Hi Patrick--
                            > Sorry for taking a few days to reply but I was working on exactly
                            this
                            > question for a team this week and wanted to have solid answers.
                            >
                            > This team used a waterfall process from 2001-2003. I switched them
                            to Scrum
                            > at the start of this year. They write in Java. Here are some
                            measurements:
                            >
                            > 2001-03 2004
                            > Lines of code per programmer-month 389 1206
                            > Defects per thousand lines 10 2.9
                            >
                            > Some code metrics as measured in Feb 2004 (2 months after
                            Scrumming started)
                            > and today. These show improvements in the code being written:
                            >
                            > 2/04 9/04
                            > # of packages 43 118
                            > # of classes 718 1,128
                            > # of methods 10,451 14,424
                            > lines of code 119,950 145,897
                            > lines per class 159 121
                            > Methods per class 14.6 12.8
                            > Lines per class 10 8.4
                            > Cyclomatic complexity 2.3 2.1
                            >
                            > Keep in mind that things like "methods per class" going down so
                            much means
                            > the new code written using Scrum went down even further because
                            the overall
                            > average is shown above, not just totals for the new code in the
                            right
                            > column.
                            >
                            > Note that throughout, lines of code is "non-comment source
                            statements". A
                            > caveat: I didn't count the JSP lines in the 2001-2003 version (not
                            many of
                            > them as much had been migrated back into servlets) or the velocity
                            templates
                            > in the 2004 system. If those were measured, things would look even
                            better
                            > for the latter metrics.
                            >
                            > I think these show a very compelling advantage to Scrum. This team
                            became
                            > more than 300% as productive (as measured my lines, which is
                            somewhat
                            > questionable as a measure) and has 80% fewer defects. More
                            importantly, the
                            > CEO is ecstatic about what the team has achieved. They're 3x
                            faster in lines
                            > but are probably 10x in delivering business value. For example,
                            the team's
                            > best programmer spent all of 2003 on a feature that has still not
                            been used
                            > ONCE. That doesn't happen with Scrum.
                            >
                            > Let me know if you have any questions,
                            >
                            > --Mike Cohn
                            > Author of User Stories Applied for Agile Software Development
                            > www.mountaingoatsoftware.com
                            > www.userstories.com
                            >
                            > -----Original Message-----
                            > From: Patrick Steyaert [mailto:steyaert.patrick@p...]
                            > Sent: Sunday, September 26, 2004 12:25 PM
                            > To: scrumdevelopment@yahoogroups.com
                            > Subject: [scrumdevelopment] SCRUM performance measurements
                            >
                            >
                            > *.*;
                            >
                            > While introducing SCRUM to software organisations, the question
                            pops up of
                            > what *bottom-line* improvements can be expected - decreasing
                            number of bugs,
                            > lower cost of quality, faster time to deliver, ...
                            > My question is whether there are people out there, that have
                            actually
                            > measured such improvements, and whether such measurements have been
                            > collected ? Are there experiences in using such measurements to
                            actually
                            > track progress of introducing SCRUM into an organisation ?
                            > All input welcome.
                            >
                            > Patrick.
                            >
                            >
                            >
                            >
                            > To Post a message, send it to: scrumdevelopment@e...
                            > To Unsubscribe, send a blank message to:
                            > scrumdevelopment-unsubscribe@e...
                            > Yahoo! Groups Links
                          • Mike Dwyer
                            Let s ask some questions. Within a Sprint, what value does measurement add to the functionality committed to at the end of the sprint? If a customer is willing
                            Message 13 of 19 , Sep 29, 2004
                              Let's ask some questions.



                              Within a Sprint, what value does measurement add to the functionality
                              committed to at the end of the sprint?

                              If a customer is willing to reduce the functional output of a
                              sprint in order to measure the effectiveness of the sprint then let it be a
                              task in the backlog and assigned a priority and commitment.



                              Second what value does measurement of sprints add to the functionality of
                              the product being delivered.

                              If a customer is willing to pay for nonfunctional tasks to be
                              conducted while moving a product through a series of sprints then track the
                              resources being consumed by allowing the providers of the non functional
                              tasks to provide and track their own resources to conduct the measurements
                              as chickens.



                              Finally what value is there in evaluating a product developed through
                              measurements if there is no means to verify and measure points of
                              improvement between products that use the same methodology?



                              Some thoughts

                              If we are going to apply Scrum and Agile principles to measurements we need
                              to begin with the customer

                              What have they assigned us at any given time?

                              The delivery of a specific set of functions using the available resources

                              Measurement equals delivery. Period.

                              If the customer changes what they want they will be given a new estimate.

                              Measurement equals old commitment minus new commitment giving

                              A negative value indicating the resources are saturated and cannot absorb
                              the change

                              A positive value indicating the resources are either not saturated (bad) or
                              have increased their productivity (good)



                              .





                              Michael F. Dwyer



                              -----Original Message-----
                              From: Steven Gordon [mailto:sagordon@...]
                              Sent: Monday, September 27, 2004 12:05 AM
                              To: scrumdevelopment@yahoogroups.com
                              Subject: RE: [scrumdevelopment] SCRUM performance measurements



                              Jim,



                              How can you make the claim clipped below from the middle of your
                              posting unless this metric was being tracked before starting to do

                              Scrum?



                              What does this metric (actual developer time spent on sprint tasks)

                              even mean outside of the context of Scrum anyway?



                              Steven Gordon

                              -----Original Message-----
                              From: Schiel James - SHS Malvern [mailto:james.schiel@...]
                              Sent: Sun 9/26/2004 7:52 PM
                              To: 'scrumdevelopment@yahoogroups.com'
                              Cc:
                              Subject: RE: [scrumdevelopment] SCRUM performance measurements



                              <clip>

                              My experience so far shows a measurable increase in
                              actual developer time when compared to non-Scrum iterations.

                              <clip>

                              Jim Schiel
                              Siemens Medical Solutions, Malvern, PA
                            • Mike Cohn
                              Those two will be less productive because they are going to fight it all the way. I have absolutely told people here is how we are doing things and it s my
                              Message 14 of 19 , Sep 30, 2004
                                Those two will be less productive because they are going to fight it all the
                                way. I have absolutely told people "here is how we are doing things and it's
                                my way or the highway." There is *nothing* in agile that says you have to
                                put up with belligerent people whom you can tell are never going to get with
                                the program. I wrote a paper for Cutter a few months ago on how some teams
                                need a "Telling" leadership style and some a "Selling" leadership style.
                                Your team needs "Telling" right now. They can't be truly agile in that mode
                                but you can lead them through that.

                                The article is on my site at
                                http://www.mountaingoatsoftware.com/articles.php and is called "Situational
                                Leadership for Agile Software Development."

                                --Mike Cohn
                                Author of User Stories Applied for Agile Software Development
                                www.mountaingoatsoftware.com
                                www.userstories.com

                                -----Original Message-----
                                From: John Gilman [mailto:jpgilman@...]
                                Sent: Wednesday, September 29, 2004 6:44 PM
                                To: scrumdevelopment@yahoogroups.com
                                Subject: [scrumdevelopment] Re: SCRUM performance measurements

                                Dear Mike (Ann Landers), your story raises an interesting question
                                for me. I have begun working with a new team and am experiencing a
                                new problem. The problem is with two of the developers (out of a
                                total of 3). They are really resistant to adopting the spirit of
                                what we are trying to do. They don't believe in it. They certainly
                                do not want to give up their offices and work in a common room with
                                the other team members from QA and PM, viewing it as some kind of
                                demotion and they are convinced that they will be less productive.

                                I fear that what one of them really wants is for me to hand him a
                                functional requirements document, he'll retire into his office and
                                come back at some point with workproduct. We aren't co-located yet
                                and he sleeps through meetings or checks his email on his laptop.
                                I'm a huge believer in building consensus and want conceptual buy-
                                in, but with this team have failed to date. The last team I worked
                                with got it from day one and we had zero issues of this type.

                                So here is my question. Did you have any issues like this with the
                                team that you took from waterfall to agile? Have you ever told
                                anyone "here is how we are doing things and it's my way or the
                                highway"?

                                John

                                --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                                wrote:
                                > Hi Patrick--
                                > Sorry for taking a few days to reply but I was working on exactly
                                this
                                > question for a team this week and wanted to have solid answers.
                                >
                                > This team used a waterfall process from 2001-2003. I switched them
                                to Scrum
                                > at the start of this year. They write in Java. Here are some
                                measurements:
                                >
                                > 2001-03 2004
                                > Lines of code per programmer-month 389 1206
                                > Defects per thousand lines 10 2.9
                                >
                                > Some code metrics as measured in Feb 2004 (2 months after
                                Scrumming started)
                                > and today. These show improvements in the code being written:
                                >
                                > 2/04 9/04
                                > # of packages 43 118
                                > # of classes 718 1,128
                                > # of methods 10,451 14,424
                                > lines of code 119,950 145,897
                                > lines per class 159 121
                                > Methods per class 14.6 12.8
                                > Lines per class 10 8.4
                                > Cyclomatic complexity 2.3 2.1
                                >
                                > Keep in mind that things like "methods per class" going down so
                                much means
                                > the new code written using Scrum went down even further because
                                the overall
                                > average is shown above, not just totals for the new code in the
                                right
                                > column.
                                >
                                > Note that throughout, lines of code is "non-comment source
                                statements". A
                                > caveat: I didn't count the JSP lines in the 2001-2003 version (not
                                many of
                                > them as much had been migrated back into servlets) or the velocity
                                templates
                                > in the 2004 system. If those were measured, things would look even
                                better
                                > for the latter metrics.
                                >
                                > I think these show a very compelling advantage to Scrum. This team
                                became
                                > more than 300% as productive (as measured my lines, which is
                                somewhat
                                > questionable as a measure) and has 80% fewer defects. More
                                importantly, the
                                > CEO is ecstatic about what the team has achieved. They're 3x
                                faster in lines
                                > but are probably 10x in delivering business value. For example,
                                the team's
                                > best programmer spent all of 2003 on a feature that has still not
                                been used
                                > ONCE. That doesn't happen with Scrum.
                                >
                                > Let me know if you have any questions,
                                >
                                > --Mike Cohn
                                > Author of User Stories Applied for Agile Software Development
                                > www.mountaingoatsoftware.com
                                > www.userstories.com
                                >
                                > -----Original Message-----
                                > From: Patrick Steyaert [mailto:steyaert.patrick@p...]
                                > Sent: Sunday, September 26, 2004 12:25 PM
                                > To: scrumdevelopment@yahoogroups.com
                                > Subject: [scrumdevelopment] SCRUM performance measurements
                                >
                                >
                                > *.*;
                                >
                                > While introducing SCRUM to software organisations, the question
                                pops up of
                                > what *bottom-line* improvements can be expected - decreasing
                                number of bugs,
                                > lower cost of quality, faster time to deliver, ...
                                > My question is whether there are people out there, that have
                                actually
                                > measured such improvements, and whether such measurements have been
                                > collected ? Are there experiences in using such measurements to
                                actually
                                > track progress of introducing SCRUM into an organisation ?
                                > All input welcome.
                                >
                                > Patrick.
                                >
                                >
                                >
                                >
                                > To Post a message, send it to: scrumdevelopment@e...
                                > To Unsubscribe, send a blank message to:
                                > scrumdevelopment-unsubscribe@e...
                                > Yahoo! Groups Links




                                To Post a message, send it to: scrumdevelopment@...
                                To Unsubscribe, send a blank message to:
                                scrumdevelopment-unsubscribe@...
                                Yahoo! Groups Links
                              • mike.dwyer1@comcast.net
                                You may find this interesting. http://www.stsc.hill.af.mil/crosstalk/2004/09/0409Ebert.html This article provides senior managers with a methodology to develop
                                Message 15 of 19 , Sep 30, 2004
                                  You may find this interesting.
                                   
                                  This article provides senior managers with a methodology to develop a metrics program that will form a basis for management decisions. It presents a series of questions a senior manager should ask to address business needs, rather than just getting informational briefings.
                                   
                                  Any problems connecting just go to the September edition
                                   
                                  While you are there take a look at the October issue on earned value, if you are interested.
                                   
                                  BTW   There have been several very good articles on Agile.   And Capers Jones latest dive into project success is good too.
                                  --
                                  Mike Dwyer

                                  "I Keep six faithful serving-men
                                  Who serve me well and true:
                                  Their names are What and Where and When
                                  And How and Why and Who." - Kipling
                                   
                                  -------------- Original message --------------

                                  > Those two will be less productive because they are going to fight it all the
                                  > way. I have absolutely told people "here is how we are doing things and it's
                                  > my way or the highway." There is *nothing* in agile that says you have to
                                  > put up with belligerent people whom you can tell are never going to get with
                                  > the program. I wrote a paper for Cutter a few months ago on how some teams
                                  > need a "Telling" leadership style and some a "Selling" leadership style.
                                  > Your team needs "Telling" right now. They can't be truly agile in that mode
                                  > but you can lead them through that.
                                  >
                                  > The article is on my site at
                                  > http://www.mountaingoatsoftware.com/articles.php and is called "Situational
                                  > Leadership for Agile Software Development."
                                  >
                                  > --Mike Cohn
                                  > Author of User Stories Applied for Agile Software Development
                                  > www.mountaingoatsoftware.com
                                  > www.userstories.com
                                  >
                                  > -----Original Message-----
                                  > From: John Gilman [mailto:jpgilman@...]
                                  > Sent: Wednesday, September 29, 2004 6:44 PM
                                  > To: scrumdevelopment@yahoogroups.com
                                  > Subject: [scrumdevelopment] Re: SCRUM performance measurements
                                  >
                                  > Dear Mike (Ann Landers), your story raises an interesting question
                                  > for me. I have begun working with a new team and am experiencing a
                                  > new problem. The problem is with two of the developers (out of a
                                  > total of 3). They are really resistant to adopting the spirit of
                                  > what we are trying to do. They don't believe in it. They certainly
                                  > do not want to give up their offices and work in a common room with
                                  > the other team members from QA and PM, viewing it as some kind of
                                  > demotion and they are convinced that they will be less productive.
                                  >
                                  > I fear that what one of them really wants is for me to hand him a
                                  > functional requirements document, he'll retire into his office and
                                  > come back at some point with workproduct. We aren't co-located yet
                                  > and he sleeps through meetings or checks his email on his laptop.
                                  > I'm a huge believer in building consensus and want conceptual buy-
                                  > in, but with this team have failed to date. The last team I worked
                                  > with got it from day one and we had zero issues of this type.
                                  >
                                  > So here is my question. Did you have any issues like this with the
                                  > team that you took from waterfall to agile? Have you ever told
                                  > anyone "here is how we are doing things and it's my way or the
                                  > highway"?
                                  >
                                  > John
                                  >
                                  > --- In scrumdevelopment@yahoogroups.com, "Mike Cohn"
                                  > wrote:
                                  > > Hi Patrick--
                                  > > Sorry for taking a few days to reply but I was working on exactly
                                  > this
                                  > > question for a team this week and wanted to have solid answers.
                                  > >
                                  > > This team used a waterfall process from 2001-2003. I switched them
                                  > to Scrum
                                  > > at the start of this year. They write in Java. Here are some
                                  > measurements:
                                  > >
                                  > > 2001-03 2004
                                  > > Lines of code per programmer-month 389 1206
                                  > > Defects per thousand lines 10 2.9
                                  > >
                                  > > Some code metrics as measured in Feb 2004 (2 months after
                                  > Scrumming started)
                                  > > and today. These show improvements in the code being written:
                                  > >
                                  > > 2/04 9/04
                                  > > # of packages 43 118
                                  > > # of classes 718 1,128
                                  > > # of methods 10,451 14,424
                                  > > lines of code 119,950 145,897
                                  > > lines per class 159 121
                                  > > Methods per class 14.6 12.8
                                  > > Lines per class 10 8.4
                                  > > Cyclomatic complexity 2.3 2.1
                                  > >
                                  > > Keep in mind that things like "methods per class" going down so
                                  > much means
                                  > > the new code written using Scrum went down even further because
                                  > the overall
                                  > > average is shown above, not just totals for the new code in the
                                  > right
                                  > > column.
                                  > >
                                  > > Note that throughout, lines of code is "non-comment source
                                  > statements". A
                                  > > caveat: I didn't count the JSP lines in the 2001-2003 version (not
                                  > many of
                                  > > them as much had been migrated back into servlets) or the velocity
                                  > templates
                                  > > in the 2004 system. If those were measured, things would look even
                                  > better
                                  > > for the latter metrics.
                                  > >
                                  > > I think these show a very compelling advantage to Scrum. This team
                                  > became
                                  > > more than 300% as productive (as measured my lines, which is
                                  > somewhat
                                  > > questionable as a measure) and has 80% fewer defects. More
                                  > importantly, the
                                  > > CEO is ecstatic about what the team has achieved. They're 3x
                                  > faster in lines
                                  > > but are probably 10x in delivering business value. For example,
                                  > the team's
                                  > > best programmer spent all of 2003 on a feature that has still not
                                  > been used
                                  > > ONCE. That doesn't happen with Scrum.
                                  > >
                                  > > Let me know if you have any questions,
                                  > >
                                  > > --Mike Cohn
                                  > > Author of User Stories Applied for Agile Software Development
                                  > > www.mountaingoatsoftware.com
                                  > > www.userstories.com
                                  > >
                                  > > -----Original Message-----
                                  > > From: Patrick Steyaert [mailto:steyaert.patrick@p...]
                                  > > Sent: Sunday, September 26, 2004 12:25 PM
                                  > > To: scrumdevelopment@yahoogroups.com
                                  > > Subject: [scrumdevelopment] SCRUM performance measurements
                                  > >
                                  > >
                                  > > *.*;
                                  > >
                                  > > While introducing SCRUM to software organisations, the question
                                  > pops up of
                                  > > what *bottom-line* improvements can be expected - decreasing
                                  > number of bugs,
                                  > > lower cost of quality, faster time to deliver, ...
                                  > > My question is whether there are people out there, that have
                                  > actually
                                  > > measured such improvements, and whether such measurements have been
                                  > > collected ? Are there experiences in using such measurements to
                                  > actually
                                  > > track progress of introducing SCRUM into an organisation ?
                                  > > All input welcome.
                                  > >
                                  > > Patrick.
                                  > >
                                  > >
                                  > >
                                  > >
                                  > > To Post a message, send it to: scrumdevelopment@e...
                                  > > To Unsubscribe, send a blank message to:
                                  > > scrumdevelopment-unsubscribe@e...
                                  > > Yahoo! Groups Links
                                  >
                                  >
                                  >
                                  >
                                  > To Post a message, send it to: scrumdevelopment@...
                                  > To Unsubscribe, send a blank message to:
                                  > scrumdevelopment-unsubscribe@...
                                  > Yahoo! Groups Links
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  > ------------------------ Yahoo! Groups Sponsor --------------------~-->
                                  > $9.95 domain names from Yahoo!. Register anything.
                                  > http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/9EfwlB/TM
                                  > --------------------------------------------------------------------~->
                                  >
                                  > To Post a message, send it to: scrumdevelopment@...
                                  > To Unsubscribe, send a blank message to:
                                  > scrumdevelopment-unsubscribe@...
                                  > Yahoo! Groups Links
                                  >
                                  > <*> To visit your group on the web, go to:
                                  > http://groups.yahoo.com/group/scrumdevelopment/
                                  >
                                  > <*> 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/
                                  >
                                  >
                                • John Gilman
                                  Thanks Mike and what a great article! I highly recommend to others dealing with similar issues. John ... it all the ... things and it s ... have to ... to get
                                  Message 16 of 19 , Sep 30, 2004
                                    Thanks Mike and what a great article! I highly recommend to others
                                    dealing with similar issues.

                                    John

                                    --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                                    wrote:
                                    > Those two will be less productive because they are going to fight
                                    it all the
                                    > way. I have absolutely told people "here is how we are doing
                                    things and it's
                                    > my way or the highway." There is *nothing* in agile that says you
                                    have to
                                    > put up with belligerent people whom you can tell are never going
                                    to get with
                                    > the program. I wrote a paper for Cutter a few months ago on how
                                    some teams
                                    > need a "Telling" leadership style and some a "Selling" leadership
                                    style.
                                    > Your team needs "Telling" right now. They can't be truly agile in
                                    that mode
                                    > but you can lead them through that.
                                    >
                                    > The article is on my site at
                                    > http://www.mountaingoatsoftware.com/articles.php and is
                                    called "Situational
                                    > Leadership for Agile Software Development."
                                    >
                                    > --Mike Cohn
                                    > Author of User Stories Applied for Agile Software Development
                                    > www.mountaingoatsoftware.com
                                    > www.userstories.com
                                    >
                                    > -----Original Message-----
                                    > From: John Gilman [mailto:jpgilman@m...]
                                    > Sent: Wednesday, September 29, 2004 6:44 PM
                                    > To: scrumdevelopment@yahoogroups.com
                                    > Subject: [scrumdevelopment] Re: SCRUM performance measurements
                                    >
                                    > Dear Mike (Ann Landers), your story raises an interesting question
                                    > for me. I have begun working with a new team and am experiencing
                                    a
                                    > new problem. The problem is with two of the developers (out of a
                                    > total of 3). They are really resistant to adopting the spirit of
                                    > what we are trying to do. They don't believe in it. They
                                    certainly
                                    > do not want to give up their offices and work in a common room
                                    with
                                    > the other team members from QA and PM, viewing it as some kind of
                                    > demotion and they are convinced that they will be less
                                    productive.
                                    >
                                    > I fear that what one of them really wants is for me to hand him a
                                    > functional requirements document, he'll retire into his office and
                                    > come back at some point with workproduct. We aren't co-located
                                    yet
                                    > and he sleeps through meetings or checks his email on his laptop.
                                    > I'm a huge believer in building consensus and want conceptual buy-
                                    > in, but with this team have failed to date. The last team I
                                    worked
                                    > with got it from day one and we had zero issues of this type.
                                    >
                                    > So here is my question. Did you have any issues like this with
                                    the
                                    > team that you took from waterfall to agile? Have you ever told
                                    > anyone "here is how we are doing things and it's my way or the
                                    > highway"?
                                    >
                                    > John
                                    >
                                    > --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                                    > wrote:
                                    > > Hi Patrick--
                                    > > Sorry for taking a few days to reply but I was working on
                                    exactly
                                    > this
                                    > > question for a team this week and wanted to have solid answers.
                                    > >
                                    > > This team used a waterfall process from 2001-2003. I switched
                                    them
                                    > to Scrum
                                    > > at the start of this year. They write in Java. Here are some
                                    > measurements:
                                    > >
                                    > > 2001-03 2004
                                    > > Lines of code per programmer-month 389 1206
                                    > > Defects per thousand lines 10 2.9
                                    > >
                                    > > Some code metrics as measured in Feb 2004 (2 months after
                                    > Scrumming started)
                                    > > and today. These show improvements in the code being written:
                                    > >
                                    > > 2/04 9/04
                                    > > # of packages 43 118
                                    > > # of classes 718 1,128
                                    > > # of methods 10,451 14,424
                                    > > lines of code 119,950 145,897
                                    > > lines per class 159 121
                                    > > Methods per class 14.6 12.8
                                    > > Lines per class 10 8.4
                                    > > Cyclomatic complexity 2.3 2.1
                                    > >
                                    > > Keep in mind that things like "methods per class" going down so
                                    > much means
                                    > > the new code written using Scrum went down even further because
                                    > the overall
                                    > > average is shown above, not just totals for the new code in the
                                    > right
                                    > > column.
                                    > >
                                    > > Note that throughout, lines of code is "non-comment source
                                    > statements". A
                                    > > caveat: I didn't count the JSP lines in the 2001-2003 version
                                    (not
                                    > many of
                                    > > them as much had been migrated back into servlets) or the
                                    velocity
                                    > templates
                                    > > in the 2004 system. If those were measured, things would look
                                    even
                                    > better
                                    > > for the latter metrics.
                                    > >
                                    > > I think these show a very compelling advantage to Scrum. This
                                    team
                                    > became
                                    > > more than 300% as productive (as measured my lines, which is
                                    > somewhat
                                    > > questionable as a measure) and has 80% fewer defects. More
                                    > importantly, the
                                    > > CEO is ecstatic about what the team has achieved. They're 3x
                                    > faster in lines
                                    > > but are probably 10x in delivering business value. For example,
                                    > the team's
                                    > > best programmer spent all of 2003 on a feature that has still
                                    not
                                    > been used
                                    > > ONCE. That doesn't happen with Scrum.
                                    > >
                                    > > Let me know if you have any questions,
                                    > >
                                    > > --Mike Cohn
                                    > > Author of User Stories Applied for Agile Software Development
                                    > > www.mountaingoatsoftware.com
                                    > > www.userstories.com
                                    > >
                                    > > -----Original Message-----
                                    > > From: Patrick Steyaert [mailto:steyaert.patrick@p...]
                                    > > Sent: Sunday, September 26, 2004 12:25 PM
                                    > > To: scrumdevelopment@yahoogroups.com
                                    > > Subject: [scrumdevelopment] SCRUM performance measurements
                                    > >
                                    > >
                                    > > *.*;
                                    > >
                                    > > While introducing SCRUM to software organisations, the question
                                    > pops up of
                                    > > what *bottom-line* improvements can be expected - decreasing
                                    > number of bugs,
                                    > > lower cost of quality, faster time to deliver, ...
                                    > > My question is whether there are people out there, that have
                                    > actually
                                    > > measured such improvements, and whether such measurements have
                                    been
                                    > > collected ? Are there experiences in using such measurements to
                                    > actually
                                    > > track progress of introducing SCRUM into an organisation ?
                                    > > All input welcome.
                                    > >
                                    > > Patrick.
                                    > >
                                    > >
                                    > >
                                    > >
                                    > > To Post a message, send it to: scrumdevelopment@e...
                                    > > To Unsubscribe, send a blank message to:
                                    > > scrumdevelopment-unsubscribe@e...
                                    > > Yahoo! Groups Links
                                    >
                                    >
                                    >
                                    >
                                    > To Post a message, send it to: scrumdevelopment@e...
                                    > To Unsubscribe, send a blank message to:
                                    > scrumdevelopment-unsubscribe@e...
                                    > Yahoo! Groups Links
                                  • mike.dwyer1@comcast.net
                                    Right on Mike! Some times the biggest impediment to productivity is the prima dona. By giving them the choice between what your doing and the highway, these
                                    Message 17 of 19 , Sep 30, 2004
                                      Right on Mike!
                                      Some times the biggest impediment to productivity is the prima dona.
                                      By giving them the choice between what your doing and the highway, these folks get a chance to either take off their toe shoes or see how far they can tip toe down the road
                                      --
                                      Mike Dwyer

                                      "I Keep six faithful serving-men
                                      Who serve me well and true:
                                      Their names are What and Where and When
                                      And How and Why and Who." - Kipling
                                       
                                      -------------- Original message --------------

                                      > Those two will be less productive because they are going to fight it all the
                                      > way. I have absolutely told people "here is how we are doing things and it's
                                      > my way or the highway." There is *nothing* in agile that says you have to
                                      > put up with belligerent people whom you can tell are never going to get with
                                      > the program. I wrote a paper for Cutter a few months ago on how some teams
                                      > need a "Telling" leadership style and some a "Selling" leadership style.
                                      > Your team needs "Telling" right now. They can't be truly agile in that mode
                                      > but you can lead them through that.
                                      >
                                      > The article is on my site at
                                      > http://www.mountaingoatsoftware.com/articles.php and is called "Situational
                                      > Leadership for Agile Software Development."
                                      >
                                      > --Mike Cohn
                                      > Author of User Stories Applied for Agile Software Development
                                      > www.mountaingoatsoftware.com
                                      > www.userstories.com
                                      >
                                      > -----Original Message-----
                                      > From: John Gilman [mailto:jpgilman@...]
                                      > Sent: Wednesday, September 29, 2004 6:44 PM
                                      > To: scrumdevelopment@yahoogroups.com
                                      > Subject: [scrumdevelopment] Re: SCRUM performance measurements
                                      >
                                      > Dear Mike (Ann Landers), your story raises an interesting question
                                      > for me. I have begun working with a new team and am experiencing a
                                      > new problem. The problem is with two of the developers (out of a
                                      > total of 3). They are really resistant to adopting the spirit of
                                      > what we are trying to do. They don't believe in it. They certainly
                                      > do not want to give up their offices and work in a common room with
                                      > the other team members from QA and PM, viewing it as some kind of
                                      > demotion and they are convinced that they will be less productive.
                                      >
                                      > I fear that what one of them really wants is for me to hand him a
                                      > functional requirements document, he'll retire into his office and
                                      > come back at some point with workproduct. We aren't co-located yet
                                      > and he sleeps through meetings or checks his email on his laptop.
                                      > I'm a huge believer in building consensus and want conceptual buy-
                                      > in, but with this team have failed to date. The last team I worked
                                      > with got it from day one and we had zero issues of this type.
                                      >
                                      > So here is my question. Did you have any issues like this with the
                                      > team that you took from waterfall to agile? Have you ever told
                                      > anyone "here is how we are doing things and it's my way or the
                                      > highway"?
                                      >
                                      > John
                                      >
                                      > --- In scrumdevelopment@yahoogroups.com, "Mike Cohn"
                                      > wrote:
                                      > > Hi Patrick--
                                      > > Sorry for taking a few days to reply but I was working on exactly
                                      > this
                                      > > question for a team this week and wanted to have solid answers.
                                      > >
                                      > > This team used a waterfall process from 2001-2003. I switched them
                                      > to Scrum
                                      > > at the start of this year. They write in Java. Here are some
                                      > measurements:
                                      > >
                                      > > 2001-03 2004
                                      > > Lines of code per programmer-month 389 1206
                                      > > Defects per thousand lines 10 2.9
                                      > >
                                      > > Some code metrics as measured in Feb 2004 (2 months after
                                      > Scrumming started)
                                      > > and today. These show improvements in the code being written:
                                      > >
                                      > > 2/04 9/04
                                      > > # of packages 43 118
                                      > > # of classes 718 1,128
                                      > > # of methods 10,451 14,424
                                      > > lines of code 119,950 145,897
                                      > > lines per class 159 121
                                      > > Methods per class 14.6 12.8
                                      > > Lines per class 10 8.4
                                      > > Cyclomatic complexity 2.3 2.1
                                      > >
                                      > > Keep in mind that things like "methods per class" going down so
                                      > much means
                                      > > the new code written using Scrum went down even further because
                                      > the overall
                                      > > average is shown above, not just totals for the new code in the
                                      > right
                                      > > column.
                                      > >
                                      > > Note that throughout, lines of code is "non-comment source
                                      > statements". A
                                      > > caveat: I didn't count the JSP lines in the 2001-2003 version (not
                                      > many of
                                      > > them as much had been migrated back into servlets) or the velocity
                                      > templates
                                      > > in the 2004 system. If those were measured, things would look even
                                      > better
                                      > > for the latter metrics.
                                      > >
                                      > > I think these show a very compelling advantage to Scrum. This team
                                      > became
                                      > > more than 300% as productive (as measured my lines, which is
                                      > somewhat
                                      > > questionable as a measure) and has 80% fewer defects. More
                                      > importantly, the
                                      > > CEO is ecstatic about what the team has achieved. They're 3x
                                      > faster in lines
                                      > > but are probably 10x in delivering business value. For example,
                                      > the team's
                                      > > best programmer spent all of 2003 on a feature that has still not
                                      > been used
                                      > > ONCE. That doesn't happen with Scrum.
                                      > >
                                      > > Let me know if you have any questions,
                                      > >
                                      > > --Mike Cohn
                                      > > Author of User Stories Applied for Agile Software Development
                                      > > www.mountaingoatsoftware.com
                                      > > www.userstories.com
                                      > >
                                      > > -----Original Message-----
                                      > > From: Patrick Steyaert [mailto:steyaert.patrick@p...]
                                      > > Sent: Sunday, September 26, 2004 12:25 PM
                                      > > To: scrumdevelopment@yahoogroups.com
                                      > > Subject: [scrumdevelopment] SCRUM performance measurements
                                      > >
                                      > >
                                      > > *.*;
                                      > >
                                      > > While introducing SCRUM to software organisations, the question
                                      > pops up of
                                      > > what *bottom-line* improvements can be expected - decreasing
                                      > number of bugs,
                                      > > lower cost of quality, faster time to deliver, ...
                                      > > My question is whether there are people out there, that have
                                      > actually
                                      > > measured such improvements, and whether such measurements have been
                                      > > collected ? Are there experiences in using such measurements to
                                      > actually
                                      > > track progress of introducing SCRUM into an organisation ?
                                      > > All input welcome.
                                      > >
                                      > > Patrick.
                                      > >
                                      > >
                                      > >
                                      > >
                                      > > To Post a message, send it to: scrumdevelopment@e...
                                      > > To Unsubscribe, send a blank message to:
                                      > > scrumdevelopment-unsubscribe@e...
                                      > > Yahoo! Groups Links
                                      >
                                      >
                                      >
                                      >
                                      > To Post a message, send it to: scrumdevelopment@...
                                      > To Unsubscribe, send a blank message to:
                                      > scrumdevelopment-unsubscribe@...
                                      > Yahoo! Groups Links
                                      >
                                      >
                                      >
                                      >
                                      >
                                      >
                                      >
                                      > ------------------------ Yahoo! Groups Sponsor --------------------~-->
                                      > $9.95 domain names from Yahoo!. Register anything.
                                      > http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/9EfwlB/TM
                                      > --------------------------------------------------------------------~->
                                      >
                                      > To Post a message, send it to: scrumdevelopment@...
                                      > To Unsubscribe, send a blank message to:
                                      > scrumdevelopment-unsubscribe@...
                                      > Yahoo! Groups Links
                                      >
                                      > <*> To visit your group on the web, go to:
                                      > http://groups.yahoo.com/group/scrumdevelopment/
                                      >
                                      > <*> 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/
                                      >
                                      >
                                    • Thierry Thelliez
                                      There is another scenario to help measuring how Scrum helps your organization. Collecting data before a Scrum implementation might not be obvious. But you
                                      Message 18 of 19 , Sep 30, 2004
                                        There is another scenario to help measuring how Scrum helps your
                                        organization.

                                        Collecting data before a Scrum implementation might not be obvious. But you
                                        could collect some data after...

                                        In our case we stepped back from explicit sprint definitions we had
                                        successfully released a major new release. The main reason was that
                                        support/training/bugs made our life so unpredictable that we just had to let
                                        the storm go by. Many issues were sent to the product backlog but some
                                        critical issues had to be addressed. We still had our daily meetings but we
                                        were not defining time boxing our activities anymore.

                                        The metrics I was recording during the sprint defined phase was the number
                                        of tasks the team could execute per week. We kept recording our tasks during
                                        the storm described. The numbers dropped by 50%!

                                        Not surprisingly the team was:
                                        - less focused / more interrupted,
                                        - probably less motivated,
                                        - involved in less technical tasks (setup, maintenance, support), and
                                        - less able to estimate the time needed for a task (mostly fixes).



                                        Thierry Thelliez
                                        www.doxcelerate.com



                                        -----Original Message-----
                                        From: Patrick Steyaert [mailto:steyaert.patrick@...]
                                        Sent: Monday, September 27, 2004 3:35 PM
                                        To: scrumdevelopment@yahoogroups.com
                                        Subject: RE: [scrumdevelopment] SCRUM performance measurements


                                        It should not necessarily be measurements *before* scrum introduction, but
                                        during a scrum introduction. (the scenario being: we are going to introduce
                                        scrum, how can we measure improvements, define measurements, baseline,
                                        measure again after a couple of sprint, etc..).
                                        To me that doesn't seem to be an unreasonable thing to do. Knowing of course
                                        that defining good measurements can be tricky.


                                        BTW. In the SCRUM certification class, Ken indicated certain percentage of
                                        performance improvements ... I was wondering whether they were based on
                                        measurement ??



                                        -----Original Message-----
                                        From: Steven Gordon [mailto:sagordon@...]
                                        Sent: Monday, September 27, 2004 2:03 AM
                                        To: scrumdevelopment@yahoogroups.com
                                        Subject: RE: [scrumdevelopment] SCRUM performance measurements


                                        Of course, this would require that an organization was already
                                        capable of accurately gathering accurate meaningful metrics
                                        and yet was feeling enough pain to consider trying SCRUM.

                                        I would suspect that this is rarely the case, so there will rarely
                                        be a baseline to even establish measurable improvement against.

                                        -----Original Message-----
                                        From: Patrick Steyaert [mailto:steyaert.patrick@...]
                                        Sent: Sun 9/26/2004 11:24 AM
                                        To: scrumdevelopment@yahoogroups.com
                                        Cc:
                                        Subject: [scrumdevelopment] SCRUM performance measurements

                                        *.*;

                                        While introducing SCRUM to software organisations, the question pops up of
                                        what *bottom-line* improvements can be expected - decreasing number of bugs,
                                        lower cost of quality, faster time to deliver, ...
                                        My question is whether there are people out there, that have actually
                                        measured such improvements, and whether such measurements have been
                                        collected ? Are there experiences in using such measurements to actually
                                        track progress of introducing SCRUM into an organisation ?
                                        All input welcome.

                                        Patrick.



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



                                        Yahoo! Groups Sponsor
                                        ADVERTISEMENT
                                        click here
                                        <http://us.ard.yahoo.com/SIG=129u2ro3a/M=295196.4901138.6071305.3001176/D=gr
                                        oups/S=1707209021:HM/EXP=1096309677/A=2128215/R=0/SIG=10se96mf6/*http://comp
                                        anion.yahoo.com>

                                        <http://us.adserver.yahoo.com/l?M=295196.4901138.6071305.3001176/D=groups/S=
                                        :HM/A=2128215/rand=403396369>

                                        _____

                                        Yahoo! Groups Links


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

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

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






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








                                        To Post a message, send it to: scrumdevelopment@...
                                        To Unsubscribe, send a blank message to:
                                        scrumdevelopment-unsubscribe@...
                                        Yahoo! Groups Links
                                      • Deb
                                        ... This is a great way to talk about what we usually call Abnormal Termination of a Sprint. I m going to remember that. It s so customer-centric. ... of a ...
                                        Message 19 of 19 , Sep 30, 2004
                                          > If the customer changes what they want they will be
                                          > given a new estimate.

                                          This is a great way to talk about what we usually call Abnormal
                                          Termination of a Sprint. I'm going to remember that. It's so
                                          customer-centric.

                                          --- In scrumdevelopment@yahoogroups.com, "Mike Dwyer"
                                          <mike.dwyer1@c...> wrote:
                                          > Let's ask some questions.
                                          >
                                          >
                                          >
                                          > Within a Sprint, what value does measurement add to the functionality
                                          > committed to at the end of the sprint?
                                          >
                                          > If a customer is willing to reduce the functional output
                                          of a
                                          > sprint in order to measure the effectiveness of the sprint then let
                                          it be a
                                          > task in the backlog and assigned a priority and commitment.
                                          >
                                          >
                                          >
                                          > Second what value does measurement of sprints add to the
                                          functionality of
                                          > the product being delivered.
                                          >
                                          > If a customer is willing to pay for nonfunctional tasks
                                          to be
                                          > conducted while moving a product through a series of sprints then
                                          track the
                                          > resources being consumed by allowing the providers of the non functional
                                          > tasks to provide and track their own resources to conduct the
                                          measurements
                                          > as chickens.
                                          >
                                          >
                                          >
                                          > Finally what value is there in evaluating a product developed through
                                          > measurements if there is no means to verify and measure points of
                                          > improvement between products that use the same methodology?
                                          >
                                          >
                                          >
                                          > Some thoughts
                                          >
                                          > If we are going to apply Scrum and Agile principles to measurements
                                          we need
                                          > to begin with the customer
                                          >
                                          > What have they assigned us at any given time?
                                          >
                                          > The delivery of a specific set of functions using the available
                                          resources
                                          >
                                          > Measurement equals delivery. Period.
                                          >
                                          > If the customer changes what they want they will be given a new
                                          estimate.
                                          >
                                          > Measurement equals old commitment minus new commitment giving
                                          >
                                          > A negative value indicating the resources are saturated and cannot
                                          absorb
                                          > the change
                                          >
                                          > A positive value indicating the resources are either not saturated
                                          (bad) or
                                          > have increased their productivity (good)
                                          >
                                          >
                                          >
                                          > .
                                          >
                                          >
                                          >
                                          >
                                          >
                                          > Michael F. Dwyer
                                          >
                                          >
                                          >
                                          > -----Original Message-----
                                          > From: Steven Gordon [mailto:sagordon@a...]
                                          > Sent: Monday, September 27, 2004 12:05 AM
                                          > To: scrumdevelopment@yahoogroups.com
                                          > Subject: RE: [scrumdevelopment] SCRUM performance measurements
                                          >
                                          >
                                          >
                                          > Jim,
                                          >
                                          >
                                          >
                                          > How can you make the claim clipped below from the middle of your
                                          > posting unless this metric was being tracked before starting to do
                                          >
                                          > Scrum?
                                          >
                                          >
                                          >
                                          > What does this metric (actual developer time spent on sprint tasks)
                                          >
                                          > even mean outside of the context of Scrum anyway?
                                          >
                                          >
                                          >
                                          > Steven Gordon
                                          >
                                          > -----Original Message-----
                                          > From: Schiel James - SHS Malvern [mailto:james.schiel@s...]
                                          > Sent: Sun 9/26/2004 7:52 PM
                                          > To: 'scrumdevelopment@yahoogroups.com'
                                          > Cc:
                                          > Subject: RE: [scrumdevelopment] SCRUM performance measurements
                                          >
                                          >
                                          >
                                          > <clip>
                                          >
                                          > My experience so far shows a measurable increase in
                                          > actual developer time when compared to non-Scrum iterations.
                                          >
                                          > <clip>
                                          >
                                          > Jim Schiel
                                          > Siemens Medical Solutions, Malvern, PA
                                        Your message has been successfully submitted and would be delivered to recipients shortly.