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

Re: [scrumdevelopment] Productivity Metrics

Expand Messages
  • Steven Gordon
    Sal, I would suggest that the managers who would impose this kind of thing should first do the following: - task out everything they plan to do for the next
    Message 1 of 17 , Feb 1, 2007
      Sal,

      I would suggest that the managers who would impose this kind of thing
      should first do the following:
      - task out everything they plan to do for the next week,
      - estimate how long each such management task would take,
      - track how long each management task actually does take,
      - apply these metrics to see if they are being productive.

      If they refused. I would ask why their reasons for not even trying
      this would not apply equally well to professional knowledge workers.
      Perhaps, this would involve explaining the difference between building
      the right software and repairing a car (or some other more
      deterministic activity).

      If they actually were willing to try it for a week, then I would ask
      them to reflect on how well these metrics reflected their
      productivity. If it did not work well for them, I would again ask why
      would they expect it to work well for professional knowledge workers.

      Of course, if they did try it and found it worthwhile, then I would
      have to concede the argument. Realistically, what would be the chance
      of that happening?

      Steve

      On 2/1/07, Nam Dao Xuan Thien <dxtnam@...> wrote:
      >
      >
      >
      >
      >
      >
      >
      >
      > Hello,
      >
      >
      >
      > My name is Sal Bruno. I am a program metrics coordinator for my company and
      > joined this group to grow in my abilities and skills in producing leading
      > edge metrics for a CMMI Level 5 company.
      >
      >
      >
      > I am creating new metric - the productivity metric. This metric is an
      > aggregated metric from SPI and CPI. This metric is an indicator to
      > compliment the traditional Progress Metric which is simply planned verses
      > actual. I would like feedback, constructive criticism, and recommendations
      > from the group.
      >
      >
      >
      > The Productivity Index = [ P – (R – E)] / P x 100 %
      >
      >
      >
      > Where P = Planned hours (or BCWS)
      >
      > A = Result hours (or BCWP)
      >
      > E = Actual hours (or ACWP)
      >
      >
      >
      > Example: In creating the program plan, it was estimated that it
      > takes 1 hour to build 1 widget
      >
      > You plan 8 hours to build widgets today – Planned hours (8 widgets)
      >
      > You actual product (the result) 11 widgets – Result
      > hours (11 hours are reported to represent 11 widgets)
      >
      > You actually work 11 hours – Actual hours – Actual
      > hours worked that day
      >
      >
      >
      > The Productivity Index = 100%. That is, you productivity is normal or as
      > expected. The Progress Metric (not demonstrated here) would be over 100%
      > since you are ahead of schedule (planned verses actual), but productivity
      > wise, you are par for the course.
      >
      >
      >
      >
      >
      > Again, I welcome your feedback, comments, criticisms, and recommendations.
      >
      >
      >
      >
      >
      > Thank you, Sal.
      >
      >
      >
      > Salvatore R. Bruno
    • dnicolet99
      ... company and ... leading ... verses ... recommendations ... Result ... Actual ... or as ... 100% ... productivity ... recommendations. ... Hi Sal, The
      Message 2 of 17 , Feb 1, 2007
        --- In scrumdevelopment@yahoogroups.com, "Nam Dao Xuan Thien"
        <dxtnam@...> wrote:
        >
        > Hello,
        >
        >
        >
        > My name is Sal Bruno. I am a program metrics coordinator for my
        company and
        > joined this group to grow in my abilities and skills in producing
        leading
        > edge metrics for a CMMI Level 5 company.
        >
        >
        >
        > I am creating new metric - the productivity metric. This metric is an
        > aggregated metric from SPI and CPI. This metric is an indicator to
        > compliment the traditional Progress Metric which is simply planned
        verses
        > actual. I would like feedback, constructive criticism, and
        recommendations
        > from the group.
        >
        >
        >
        > The Productivity Index = [ P – (R – E)] / P x 100 %
        >
        >
        >
        > Where P = Planned hours (or BCWS)
        >
        > A = Result hours (or BCWP)
        >
        > E = Actual hours (or ACWP)
        >
        >
        >
        > Example: In creating the program plan, it was estimated that it
        > takes 1 hour to build 1 widget
        >
        > You plan 8 hours to build widgets today – Planned hours (8 widgets)
        >
        > You actual product (the result) 11 widgets –
        Result
        > hours (11 hours are reported to represent 11 widgets)
        >
        > You actually work 11 hours – Actual hours –
        Actual
        > hours worked that day
        >
        >
        >
        > The Productivity Index = 100%. That is, you productivity is normal
        or as
        > expected. The Progress Metric (not demonstrated here) would be over
        100%
        > since you are ahead of schedule (planned verses actual), but
        productivity
        > wise, you are par for the course.
        >
        >
        >
        >
        >
        > Again, I welcome your feedback, comments, criticisms, and
        recommendations.
        >
        >
        >
        >
        >
        > Thank you, Sal.
        >
        >
        >
        > Salvatore R. Bruno
        >

        Hi Sal,

        The Productivity Metric sounds very interesting. I'm not sure this is
        the right group to ask for feedback, though, since the metric doesn't
        apply to software development. Even in a manufacturing environment,
        this sort of metric may be problematic.

        Let's take the second point first.

        Say we're manufacturing standard #6 machine screws. That's our
        "widget". We have a production cell that takes in alloy, melts it,
        ensures it's the right mix, molds it into slugs, grinds the slugs into
        screws, recycles the leftover material back to the input, cools the
        slugs, and packs them.

        Each of the machines in that cell could be measured by the
        Productivity Metric you describe. The problem is, when people judge
        the productivity of their machines in that way, they tend to think
        they have to keep all the machines running at full capacity all the
        time, or else they're "losing productivity".

        The thing is, there may not be anyplace for the screws to go once
        they've been made. The overall production operation might be more
        efficient if this cell is allowed to remain idle at certain times. By
        looking at the Productivity Metric, plant management is liable to
        think they're doing something wrong unless they can get a 100%
        measurement on all the machines all the time.

        That's really a false indication of "productivity", because "producing
        stuff" isn't necessarily the same as "producing value". It *may* only
        amount to busy-ness. Have a look at any book about Theory of
        Constraints for more along these lines.

        Now to the first point.

        Think about the widgets we've been making. Each machine screw is
        produced individually from raw materials using exactly the same
        process, and every one of them has to be nearly identical. That's why
        they can be produced by an automated assembly cell, and that's why
        it's even *possible* to apply the Productivity Metric to the process.

        Let's change gears and say our "widget" is a software program of some
        kind, instead of a physical object like a screw. If we needed to
        distribute a copy of the program to each of 100,000 customers, we
        would not actually write the program 100,000 times from scratch using
        automated machines. We would write the program once, using human
        beings, and then make 99,999 digital copies of it for distribution.
        It's a completely different sort of activity.

        It's not meaningful to assign a standard unit of time for the
        production of any given "piece" of software; like, for instance, 8
        hours to develop a "class" or a "function" or a "database schema".
        Things just don't fall out that neatly. That's why I think the
        Productivity Metric doesn't apply to software development, even if
        it's an interesting formula on its own merits.
      • Nicholas Cancelliere
        I completely agree. I m a big Tolkien buff so I ll share an analogy. Upper managers tend to reside in these ivory towers and brood over reports and metrics,
        Message 3 of 17 , Feb 1, 2007
          I completely agree.

          I'm a big Tolkien buff so I'll share an analogy. Upper managers tend to
          reside in these ivory towers and brood over reports and metrics, etc. Like
          a palantir metrics show you something - but it's still left to
          interpretation what it all really means or even if the vision is true.
          Wisdom to be learned, you have to go out into the world and seek your own
          answers.

          Your example confuses me - because if I thought you could only do 8 widgets
          in a day and instead turned out 11 I'd say you're "more than productive" and
          would think your index showed something over 100%.

          So you're saying if I do less than 8 widgets I'm not being productive? How
          do you know that. Who estimated the number of 8, management or the worker?

          What if I produced 8 widgets in 4 hrs? If I understand your formula that'd
          come out to 50%? [8-(8-4)]/8 x 100 However I'd consider such an
          individual to be more productive since they did what was expected in less
          time.

          The other thing I don't understand is the statement about "result hours"
          being 1 widget = 1 hour. One widget is one widget, no? How does that
          translate arbitrarily into hours? Doesn't seem scientific.

          -Nick



          > -----Original Message-----
          > From: scrumdevelopment@yahoogroups.com
          > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Steven Gordon
          > Sent: Thursday, February 01, 2007 8:29 AM
          > To: scrumdevelopment@yahoogroups.com
          > Subject: Re: [scrumdevelopment] Productivity Metrics
          >
          > Sal,
          >
          > I would suggest that the managers who would impose this kind of thing
          > should first do the following:
          > - task out everything they plan to do for the next week,
          > - estimate how long each such management task would take,
          > - track how long each management task actually does take,
          > - apply these metrics to see if they are being productive.
          >
          > If they refused. I would ask why their reasons for not even trying
          > this would not apply equally well to professional knowledge workers.
          > Perhaps, this would involve explaining the difference between building
          > the right software and repairing a car (or some other more
          > deterministic activity).
          >
          > If they actually were willing to try it for a week, then I would ask
          > them to reflect on how well these metrics reflected their
          > productivity. If it did not work well for them, I would again ask why
          > would they expect it to work well for professional knowledge workers.
          >
          > Of course, if they did try it and found it worthwhile, then I would
          > have to concede the argument. Realistically, what would be the chance
          > of that happening?
          >
          > Steve
          >
          > On 2/1/07, Nam Dao Xuan Thien <dxtnam@...> wrote:
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > > Hello,
          > >
          > >
          > >
          > > My name is Sal Bruno. I am a program metrics coordinator for my company
          > and
          > > joined this group to grow in my abilities and skills in producing
          > leading
          > > edge metrics for a CMMI Level 5 company.
          > >
          > >
          > >
          > > I am creating new metric - the productivity metric. This metric is an
          > > aggregated metric from SPI and CPI. This metric is an indicator to
          > > compliment the traditional Progress Metric which is simply planned
          > verses
          > > actual. I would like feedback, constructive criticism, and
          > recommendations
          > > from the group.
          > >
          > >
          > >
          > > The Productivity Index = [ P - (R - E)] / P x 100 %
          > >
          > >
          > >
          > > Where P = Planned hours (or BCWS)
          > >
          > > A = Result hours (or BCWP)
          > >
          > > E = Actual hours (or ACWP)
          > >
          > >
          > >
          > > Example: In creating the program plan, it was estimated that it
          > > takes 1 hour to build 1 widget
          > >
          > > You plan 8 hours to build widgets today - Planned hours (8 widgets)
          > >
          > > You actual product (the result) 11 widgets -
          > Result
          > > hours (11 hours are reported to represent 11 widgets)
          > >
          > > You actually work 11 hours - Actual hours -
          > Actual
          > > hours worked that day
          > >
          > >
          > >
          > > The Productivity Index = 100%. That is, you productivity is normal or
          > as
          > > expected. The Progress Metric (not demonstrated here) would be over
          > 100%
          > > since you are ahead of schedule (planned verses actual), but
          > productivity
          > > wise, you are par for the course.
          > >
          > >
          > >
          > >
          > >
          > > Again, I welcome your feedback, comments, criticisms, and
          > recommendations.
          > >
          > >
          > >
          > >
          > >
          > > Thank you, Sal.
          > >
          > >
          > >
          > > Salvatore R. Bruno
          >
          >
          > To Post a message, send it to: scrumdevelopment@...
          > To Unsubscribe, send a blank message to: scrumdevelopment-
          > unsubscribe@...
          > Yahoo! Groups Links
          >
          >
          >
        • dnicolet99
          ... The palantir analogy is beautiful because the palantir doesn t merely provide plain information and leave the interpretation up to you, it actually tempts
          Message 4 of 17 , Feb 1, 2007
            --- In scrumdevelopment@yahoogroups.com, "Nicholas Cancelliere"
            <nickaustin74@...> wrote:

            > Like
            > a palantir metrics show you something - but it's still left to
            > interpretation what it all really means or even if the vision is true.

            The palantir analogy is beautiful because the palantir doesn't merely
            provide plain information and leave the interpretation up to you, it
            actually tempts you with visions you think you want to see and that
            you wish were true, and allows you to trick yourself into believing
            dangerous nonsense. That's exactly what this sort of metric does for
            the managers who believe in it.
          • mdwollin
            Can anyone suggest a good book and or online reference source for metics or productivity in an agile world? If not, does anyone want to collaborate on writing
            Message 5 of 17 , Feb 1, 2007
              Can anyone suggest a good book and or online reference source for metics or productivity in
              an agile world? If not, does anyone want to collaborate on writing one?
            • Steven Gordon
              It might be a rather short book. It would boil down to being careful to measure exactly the behavior you want to get, because that will be the result of
              Message 6 of 17 , Feb 1, 2007
                It might be a rather short book. It would boil down to being careful
                to measure exactly the behavior you want to get, because that will be
                the result of defining the metric and measuring it.

                So, if some productivity measure is more important than business value
                delivered, then by all means define that productivity measure and
                collect it. Just know that doing so will tend to deoptimize business
                value delivered in favor of the specific things that go into your
                productivity measure.

                On the other hand, you could just measure net business value
                delivered, also known as ROI.

                There is a related concept called Earned Value (EV) that a few
                agilists favor. It does not seem like the simplest thing that could
                work in most contexts, but it might be the best approach in situations
                where software is just one piece in a very complex endeavor.

                Steve

                On 2/1/07, mdwollin <yahoo@...> wrote:
                >
                >
                > Can anyone suggest a good book and or online reference source for metics or
                > productivity in
                > an agile world? If not, does anyone want to collaborate on writing one?
                >
              • Neeraj Kumar
                Hi, There is one metric we collect to measure productivity of the team : Velocity of the team (Story Points completed per Sprint). This metric will help in
                Message 7 of 17 , Feb 1, 2007
                  Hi,

                  There is one metric we collect to measure productivity of the team :
                  Velocity of the team (Story Points completed per Sprint). This metric will
                  help in understanding the throughput of the team for a given Sprint and will
                  also provide productivity baseline and objective for the team. For baselines
                  data should be collected for minimum 3 months.

                  Another metric I can think of is average time/effort spent on Maintenance
                  tasks during the Sprint. this metric can be considered especially when teams
                  are working on Sprint tasks as well as maintenance Tasks or HD tickets. This
                  metric will help the team in estimating better for the Sprint and help them
                  to commit to what they can deliver.
                  Probably identifying meaningful metrics which will help the teams in better
                  estimations and planning will deliver value to the business.

                  Regards,
                  Neeraj

                  >From: "mdwollin" <yahoo@...>
                  >Reply-To: scrumdevelopment@yahoogroups.com
                  >To: scrumdevelopment@yahoogroups.com
                  >Subject: [scrumdevelopment] Productivity Metrics
                  >Date: Fri, 02 Feb 2007 03:54:08 -0000
                  >
                  >Can anyone suggest a good book and or online reference source for metics or
                  >productivity in
                  >an agile world? If not, does anyone want to collaborate on writing one?
                  >

                  _________________________________________________________________
                  Want to look more beautiful? Ask Asha Bachani
                  http://content.msn.co.in/Lifestyle/Fashionbeauty/Default.aspx
                • Steven Gordon
                  ... It is good to keep track of velocity, but the purpose is not to measure productivity. It does not even have units, so you cannot meaningfully compare one
                  Message 8 of 17 , Feb 1, 2007
                    On 2/1/07, Neeraj Kumar <neerkuma@...> wrote:
                    >
                    >
                    >
                    >
                    >
                    >
                    > Hi,
                    >
                    > There is one metric we collect to measure productivity of the team :
                    > Velocity of the team (Story Points completed per Sprint). This metric will
                    > help in understanding the throughput of the team for a given Sprint and
                    > will
                    > also provide productivity baseline and objective for the team. For
                    > baselines
                    > data should be collected for minimum 3 months.
                    >

                    It is good to keep track of velocity, but the purpose is not to
                    measure productivity. It does not even have units, so you cannot
                    meaningfully compare one team's velocity with another. However,
                    velocity can be used to keep track of a team's improvement in
                    productivity.

                    The main purpose of velocity is to support planning release and
                    iteration planning.

                    > Another metric I can think of is average time/effort spent on Maintenance
                    > tasks during the Sprint. this metric can be considered especially when
                    > teams
                    > are working on Sprint tasks as well as maintenance Tasks or HD tickets.
                    > This
                    > metric will help the team in estimating better for the Sprint and help them
                    > to commit to what they can deliver.
                    > Probably identifying meaningful metrics which will help the teams in better
                    > estimations and planning will deliver value to the business.

                    Likewise, not a productivity measure, a metric for the team's own use.

                    >
                    > Regards,
                    > Neeraj
                    >
                  • Oldfield, Paul (ASPIRE)
                    (responding to mdwollin) ... Agile Estimating and Planning covers the topic as well as I ve ever really needed. Paul Oldfield
                    Message 9 of 17 , Feb 2, 2007
                      (responding to mdwollin)

                      > Can anyone suggest a good book and or online reference
                      > source for metics or productivity in an agile world?

                      "Agile Estimating and Planning" covers the topic as well
                      as I've ever really needed.

                      Paul Oldfield



                      ===========================================================
                      Our e-mail domain has now changed from iraspire.com to hmrcaspire.com. Please update your address books.
                      ===========================================================
                    • Ron Jeffries
                      Hello, mdwollin. On Thursday, February 1, 2007, at 10:54:08 PM, ... What part of what organization would you think such metrics would address? What kind of
                      Message 10 of 17 , Feb 2, 2007
                        Hello, mdwollin. On Thursday, February 1, 2007, at 10:54:08 PM,
                        you wrote:

                        > Can anyone suggest a good book and or online reference source for metics or productivity in
                        > an agile world? If not, does anyone want to collaborate on writing one?

                        What part of what organization would you think such metrics would
                        address? What kind of productivity seems important? Why?

                        Ron Jeffries
                        www.XProgramming.com
                        Fatalism is born of the fear of failure, for we all believe that we carry
                        success in our own hands, and we suspect that our hands are weak. -- Conrad
                      • Michael Wollin
                        I am taking over a team at a new company. I want to 1) make sure that the changes I put into effect are working and 2) show that to management in such a way
                        Message 11 of 17 , Feb 2, 2007
                          I am taking over a team at a new company. I want to 1) make sure that the changes I put into effect are working and 2) show that to management in such a way that builds confidence in my methods (resulting in more buy-in and funding for future proposals). Hypothetical example: One of my teams actually gets a lab. Show management the ROI.
                           
                          Michael
                        • Ron Jeffries
                          Hello, Michael. On Friday, February 2, 2007, at 12:47:04 PM, you ... Would customer satisfaction and perhaps the rate of generating features serve? Ron
                          Message 12 of 17 , Feb 2, 2007
                            Hello, Michael. On Friday, February 2, 2007, at 12:47:04 PM, you
                            wrote:

                            > I am taking over a team at a new company. I want to 1) make sure that the
                            > changes I put into effect are working and 2) show that to management in such
                            > a way that builds confidence in my methods (resulting in more buy-in and
                            > funding for future proposals). Hypothetical example: One of my teams
                            > actually gets a lab. Show management the ROI.

                            Would customer satisfaction and perhaps the rate of generating
                            features serve?

                            Ron Jeffries
                            www.XProgramming.com
                            Find the simple path to what works and follow it,
                            always looking for a simpler path. -- Patrick D. Smith
                          • Nicholas Cancelliere
                            Well you need to be careful - because experience says that at least 30-35% of your team will quit during Scrum adoption. You ll likely make quite a few
                            Message 13 of 17 , Feb 2, 2007

                              Well you need to be careful – because experience says that at least 30-35% of your team will quit during Scrum adoption.  You’ll likely make quite a few enemies and frustrate more traditionally minded people.  I don’t know if metrics would necessarily save the day there.  It depends on the environment, but just warning you to be ready.

                               

                              I agree with Ron … I’d focus on measuring things like customer satisfaction, development team morale, etc.  We don’t use Scrum to be more “productive” per se, as it’s hard to gauge that with knowledge workers anyhow.  We use Scrum to be able to produce software products reliably and with quality.

                               

                              A team might appear to be productive but their product is buggy or the team isn’t building features the customer really needs or wants.  Your metrics wouldn’t even capture these issues or touch on these points which is a big piece of what Scrum attempts to address.

                               

                              Nick

                               

                               

                               


                              From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
                              Sent: Friday, February 02, 2007 1:08 PM
                              To: scrumdevelopment@yahoogroups.com
                              Subject: Re: [scrumdevelopment] Re: Productivity Metrics

                               

                              Hello, Michael. On Friday, February 2, 2007, at 12:47:04 PM, you
                              wrote:

                              > I am taking over a team at a new company. I want to 1) make sure that the
                              > changes I put into effect are working and 2) show that to management in
                              such
                              > a way that builds confidence in my methods (resulting in more buy-in and
                              > funding for future proposals). Hypothetical example: One of my teams
                              > actually gets a lab. Show management the ROI.

                              Would customer satisfaction and perhaps the rate of generating
                              features serve?

                              Ron Jeffries
                              www.XProgramming. com
                              Find the simple path to what works and follow it,
                              always looking for a simpler path. -- Patrick D. Smith

                            • mpkirby
                              ... Read this: http://www.martinfowler.com/bliki/CannotMeasureProductivity.html Mike
                              Message 14 of 17 , Feb 3, 2007
                                Nam Dao Xuan Thien wrote:
                                >
                                >
                                > Again, I welcome your feedback, comments, criticisms, and
                                > recommendations.
                                >
                                Read this:

                                http://www.martinfowler.com/bliki/CannotMeasureProductivity.html

                                Mike
                              • Robin Dymond
                                As mentioned very eloquently in Martin Fowler s article, this is kind of measure not useful to the business, and potentially misleading. One very useful metric
                                Message 15 of 17 , Feb 4, 2007
                                  As mentioned very eloquently in Martin Fowler's article, this is kind of measure not useful to the business, and potentially misleading.

                                  One very useful metric we have used to drive change across an enterprise is Time To Market. This is measured as the time from project inception until the first release gets into production, and the time between subsequent releases. This basic measurement is great for showing the business how long it takes for any investment to start generating returns.

                                  We have done some thinking on this topic, you can check out the article presented at Agile 2006 at:

                                  http://www.berteigconsulting.com/ AppropriateAgileMeasurement.pdf

                                  We have proposed that there are two types of measures:
                                   - diagnostics, which are measures used to help the team, and
                                   - only 1 or 2 metrics, that include the economics of the project, such as NPV or some other measure of return on investment.

                                  What metrics can Program managers realistically act on? What will you do with the data? Does it tell you something the PM, Coach, or Scrum master couldn't tell you already? Perhaps a simple declaration of Red, Yellow, or Green status is all that is required?

                                  What bothers me about these so called productivity metrics is that I have NEVER heard of them positively impacting a project or team. Customers and product owners don't ask to see them. They want to see tested working software, they want to ensure the project is meeting the strategic goals, and they want to know how the investment made today will generate returns sooner, and faster.

                                  Any program level metrics that do not include ROI are probably too low level to be useful at the program level.
                                  However there are really great diagnostics from LEAN that all Program managers should be asking from their teams and including in their portfolios: CVA, BVA, and NVA.
                                  Check out Mishkin's overview on these at:
                                  http://www.agileadvice.com/archives/2005/07/value.html

                                  There are lots of good books on LEAN, and I'd recommend Lean software development by Poppendeick for a good intro into lean and its application to software development.

                                  cheers,
                                  Robin Dymond.

                                  On 2/3/07, mpkirby <mpkirby@...> wrote:
                                  Nam Dao Xuan Thien wrote:
                                  >
                                  >
                                  > Again, I welcome your feedback, comments, criticisms, and
                                  > recommendations.
                                  >
                                  Read this:

                                  http://www.martinfowler.com/bliki/CannotMeasureProductivity.html

                                  Mike



                                  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/

                                  <*> Your email settings:
                                      Individual Email | Traditional

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

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

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

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


                                • mpkirby
                                  ... I suppose it should a warning sign if any measure doesn t positively impact the development team. I think the URL got encoded wrong:
                                  Message 16 of 17 , Feb 4, 2007
                                    Robin Dymond wrote:
                                    >
                                    >
                                    > What bothers me about these so called productivity metrics is that I have
                                    > NEVER heard of them positively impacting a project or team. Customers and
                                    > product owners don't ask to see them. They want to see tested working
                                    > software, they want to ensure the project is meeting the strategic goals,
                                    > and they want to know how the investment made today will generate returns
                                    > sooner, and faster.

                                    I suppose it should a warning sign if any measure doesn't positively
                                    impact the development team.

                                    I think the URL got encoded wrong:

                                    http://www.berteigconsulting.com/AppropriateAgileMeasurement.pdf

                                    One of the things I like about Robin's concept of breaking measurement
                                    into two concepts: Long-lived "metrics" and short-lived "diagnostics",
                                    is that a lot of the "useful" metrics from computer science research can
                                    be used for short-lived investigations into problems identified with
                                    long-lived "metrics".

                                    I've combined this with some of the concepts identified in the Toyota
                                    Way by Jeffrey Liker. Toyota has the concept of measurements existing
                                    on a single sheet of paper. The theory is that if you can't make a
                                    decision based on the information on a single piece of paper, something
                                    is wrong with your measurement scheme.

                                    So I've got one for dealing with problems (which hopefully will go away
                                    as more of our code goes under test), and one for dealing with planning
                                    (burndowns, release plan, etc).

                                    We adjust these weekly, removing things that we find not to be useful,
                                    adding diagnostics when we detect a problem, and so forth. It works
                                    fairly well.

                                    http://www.goldpractices.com/practices/gqm/index.php

                                    Is a technique of mapping goals to questions to measures so your
                                    measurements drive decisions. I never really liked the approach in
                                    practice (although it was intellectually appealing), but combined with
                                    the idea of "metrics" and "diagnostics" I find it works fairly well.

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