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

Re: QA metrics and Scrum

Expand Messages
  • lachlan
    ... Re-posting the link to the blog http://jchyip.blogspot.com/2009/01/no-matter-how-many-times-you-say-it-we.html
    Message 1 of 35 , Jan 26, 2009
    • 0 Attachment
      --- In scrumdevelopment@yahoogroups.com, "lachlan" <sydney@...> wrote:
      >
      >
      > --- In scrumdevelopment@yahoogroups.com, Ivo Verus <ivo.verus@>
      > wrote:
      > >
      > > Hi,
      > >
      > > My client asked me to introduce QA metrics like number of defects per
      > 1000
      > > lines of code, etc...
      > > We had these kind of measures before and personally I think that they
      > are
      > > not necessarry in Scrum and they can lead only to conflict situations
      > like
      > > why the number of defects are bigger than the previous release etc.
      > >
      > > What do you think about the situation? Should we introduce them with
      > Scrum
      > > also, should we introduce some other measurements maybe?
      > > Curently we are tracking the focus factor, estimated and actual
      > velocity per
      > > sprint and avarage.
      > >
      > > Thanks.
      > > Ivo Verus
      >
      >
      > Hi Ivo
      >
      > I have a couple of thoughts on this that I hope may be useful (no maths
      > will be required).
      >
      > What is the Goal of collecting the metrics? If the goal is to make sure
      > the product has a sufficient degree of quality you need to work out what
      > "quality" means, then define appropriate practices and metrics - check
      > out this blog post
      >
      > for well considered thoughts on quality. If the goal is to have some
      > numbers to to wave at people as a performance measure then you will get
      > conflict - this is a sign of a lack of trust from the client, which is a
      > bigger issue but I would suggest you work on making everything as
      > transparent as possible and see if you can start to build more trust.
      >
      > As a general thought on metrics you only want to collect data that helps
      > you achieve a goal. Check out the GQM approach to metrics for some
      > detail on this - apologies if this is something you are using -
      > wikipedia <http://en.wikipedia.org/wiki/GQM> , more detailed version
      > here.
      > <https://www.goldpractices.com/practices/gqm/>
      > A comment on you point about "I think that they are not necessarry in
      > Scrum". Just because you are using Scrum does not mean you throw away
      > everything you were doing before using Scrum. I hope you now have a
      > framework to judge the value of existing practices, and adapt these
      > appropriately.
      >
      > regards
      >
      > Lachlan
      >

      Re-posting the link to the blog

      http://jchyip.blogspot.com/2009/01/no-matter-how-many-times-you-say-it-we.html
    • lachlan
      ... Re-posting the link to the blog http://jchyip.blogspot.com/2009/01/no-matter-how-many-times-you-say-it-we.html
      Message 35 of 35 , Jan 26, 2009
      • 0 Attachment
        --- In scrumdevelopment@yahoogroups.com, "lachlan" <sydney@...> wrote:
        >
        >
        > --- In scrumdevelopment@yahoogroups.com, Ivo Verus <ivo.verus@>
        > wrote:
        > >
        > > Hi,
        > >
        > > My client asked me to introduce QA metrics like number of defects per
        > 1000
        > > lines of code, etc...
        > > We had these kind of measures before and personally I think that they
        > are
        > > not necessarry in Scrum and they can lead only to conflict situations
        > like
        > > why the number of defects are bigger than the previous release etc.
        > >
        > > What do you think about the situation? Should we introduce them with
        > Scrum
        > > also, should we introduce some other measurements maybe?
        > > Curently we are tracking the focus factor, estimated and actual
        > velocity per
        > > sprint and avarage.
        > >
        > > Thanks.
        > > Ivo Verus
        >
        >
        > Hi Ivo
        >
        > I have a couple of thoughts on this that I hope may be useful (no maths
        > will be required).
        >
        > What is the Goal of collecting the metrics? If the goal is to make sure
        > the product has a sufficient degree of quality you need to work out what
        > "quality" means, then define appropriate practices and metrics - check
        > out this blog post
        >
        > for well considered thoughts on quality. If the goal is to have some
        > numbers to to wave at people as a performance measure then you will get
        > conflict - this is a sign of a lack of trust from the client, which is a
        > bigger issue but I would suggest you work on making everything as
        > transparent as possible and see if you can start to build more trust.
        >
        > As a general thought on metrics you only want to collect data that helps
        > you achieve a goal. Check out the GQM approach to metrics for some
        > detail on this - apologies if this is something you are using -
        > wikipedia <http://en.wikipedia.org/wiki/GQM> , more detailed version
        > here.
        > <https://www.goldpractices.com/practices/gqm/>
        > A comment on you point about "I think that they are not necessarry in
        > Scrum". Just because you are using Scrum does not mean you throw away
        > everything you were doing before using Scrum. I hope you now have a
        > framework to judge the value of existing practices, and adapt these
        > appropriately.
        >
        > regards
        >
        > Lachlan
        >

        Re-posting the link to the blog

        http://jchyip.blogspot.com/2009/01/no-matter-how-many-times-you-say-it-we.html
      Your message has been successfully submitted and would be delivered to recipients shortly.