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

Re: [scrumdevelopment] Re: Using Scrum for a maintenance / sustained engineering assignment

Expand Messages
  • Ron Jeffries
    Hello, wnoida. On Tuesday, September 1, 2009, at 4:09:17 PM, you ... Velocity = # stories per sprint. When stories are defects, velocity may not even be
    Message 1 of 26 , Sep 1, 2009
      Hello, wnoida. On Tuesday, September 1, 2009, at 4:09:17 PM, you
      wrote:

      > Thanks for the reply Ron. Here we are mostly dealing with
      > defects. How can we measure the teams velocity? As defects are
      > assigned to the team members they are not in a position to assign
      > story points to it. Can we assign story points after fixing the
      > defects, as now the developer knows the size of the work item?
      > This will help us build a history and we can use this to predict
      > the velocity for future sprints? How should we approach this issue
      > when fixing defects? what is a good metrics in this situation?

      Velocity = # stories per sprint. When stories are defects, velocity
      may not even be stable. In any case, why not just count them?

      Ron Jeffries
      www.XProgramming.com
      www.xprogramming.com/blog
      Think! -- Aretha Franklin
    • Roy Morien
      It seems to me that the effort in fixing a defect can be reasonably counted in the team s velocity. Maybe it will be of interest as to why the defect occurred,
      Message 2 of 26 , Sep 2, 2009
        It seems to me that the effort in fixing a defect can be reasonably counted in the team's velocity. Maybe it will be of interest as to why the defect occurred, and certainly there will be some effort in clearly understanding what the defect is, and how to rectify it ... but, velocity is a measure of how much 'effort and complexity' a team can achieve in a sprint. Where does it say that velocity can only measure effort on new, 'green fields' work?

        The cause of the defect, the reason it occurred, the reason that it was not detected during the development of the feature in which the defect occurred, can be considered in a review or sprint retrospective, so that the process of development can be improved to avoid the same situation  occurring again. But this is not part of 'velocity'.

        My reaction to the statement 'they need to spend more time ... more than 4 hours' is 'maybe they would make better use of that time by getting on with fixing it, rather than trying to come up with a better estimate of when they will finish fixing it'. Sure , spend the necessary time understanding the problem, but to spend a lot of time trying to come up with a better estimate of time seems a rather unhelpful activity.

        Regards,
        Roy Morien 


        To: scrumdevelopment@yahoogroups.com
        From: wnoida@...
        Date: Tue, 1 Sep 2009 20:09:17 +0000
        Subject: [scrumdevelopment] Re: Using Scrum for a maintenance / sustained engineering assignment

         
        --- In scrumdevelopment@ yahoogroups. com, Ron Jeffries <ronjeffries@ ...> wrote:
        >
        > Hello, wnoida. On Saturday, August 8, 2009, at 3:55:13 AM, you
        > wrote:
        >
        > > The biggest challenge we are facing is with second part of the
        > > sprint planning meeting. Once the team understands the priortized
        > > backlog items, they need to spend time with the application,
        > > explore the code, gain more functional knowledge before they can
        > > come up with the commitment and some estimates. This exercise
        > > needs more than 4 hours. The collaoration between Developers and
        > > Testers also becomes challenging.
        >
        > What value would you get if it didn't take that long? Why not just
        > prioritize the defects and start working?
        >
        > Ron Jeffries
        > www.XProgramming. com
        > www.xprogramming. com/blog
        > Yesterday's code should be as good as we could make it yesterday.
        > The fact that we know more today, and are more capable today,
        > is good news about today, not bad news about yesterday.
        >
        Thanks for the reply Ron. Here we are mostly dealing with defects. How can we measure the teams velocity? As defects are assigned to the team members they are not in a position to assign story points to it. Can we assign story points after fixing the defects, as now the developer knows the size of the work item? This will help us build a history and we can use this to predict the velocity for future sprints? How should we approach this issue when fixing defects? what is a good metrics in this situation?

        Regards
        Rohit




        Find out how here Use Messenger in your Hotmail inbox
      • Jacob
        Hello, Are you running automated tests? I get the impression that the code is causing the problem here, not the estimations of velocity of the team. I would do
        Message 3 of 26 , Sep 2, 2009
          Hello,

          Are you running automated tests?

          I get the impression that the code is causing the problem here, not the estimations of velocity of the team.

          I would do some major code review sessions before tackling bugs which, in my opinion, the users should not be the ones reporting.

          For me, velocity is an estimate of how much functionality items can be delivered at the end of a sprint. Even story points are not entirely necessary. As a PO I would even be happy with a velocity measurements of 'a couple \ a few \ a handful \ many'.

          In that sense you can treat bug fixing in the same way. How many bugs will be fixed? Many? A couple? That becomes your velocity.

          But what do you want to use the velocity measurement for? Are you devising a release plan? Are you trying to estimate when all bugs will be fixed?

          Jacob


          On Wed, Sep 2, 2009 at 12:17 PM, Roy Morien <roymorien@...> wrote:
           

          It seems to me that the effort in fixing a defect can be reasonably counted in the team's velocity. Maybe it will be of interest as to why the defect occurred, and certainly there will be some effort in clearly understanding what the defect is, and how to rectify it ... but, velocity is a measure of how much 'effort and complexity' a team can achieve in a sprint. Where does it say that velocity can only measure effort on new, 'green fields' work?


          The cause of the defect, the reason it occurred, the reason that it was not detected during the development of the feature in which the defect occurred, can be considered in a review or sprint retrospective, so that the process of development can be improved to avoid the same situation  occurring again. But this is not part of 'velocity'.

          My reaction to the statement 'they need to spend more time ... more than 4 hours' is 'maybe they would make better use of that time by getting on with fixing it, rather than trying to come up with a better estimate of when they will finish fixing it'. Sure , spend the necessary time understanding the problem, but to spend a lot of time trying to come up with a better estimate of time seems a rather unhelpful activity.

          Regards,
          Roy Morien 


          To: scrumdevelopment@yahoogroups.com
          From: wnoida@...
          Date: Tue, 1 Sep 2009 20:09:17 +0000

          Subject: [scrumdevelopment] Re: Using Scrum for a maintenance / sustained engineering assignment

           
          --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
          >
          > Hello, wnoida. On Saturday, August 8, 2009, at 3:55:13 AM, you
          > wrote:
          >
          > > The biggest challenge we are facing is with second part of the
          > > sprint planning meeting. Once the team understands the priortized
          > > backlog items, they need to spend time with the application,
          > > explore the code, gain more functional knowledge before they can
          > > come up with the commitment and some estimates. This exercise
          > > needs more than 4 hours. The collaoration between Developers and
          > > Testers also becomes challenging.
          >
          > What value would you get if it didn't take that long? Why not just
          > prioritize the defects and start working?
          >
          > Ron Jeffries
          > www.XProgramming.com
          > www.xprogramming.com/blog
          > Yesterday's code should be as good as we could make it yesterday.
          > The fact that we know more today, and are more capable today,
          > is good news about today, not bad news about yesterday.
          >
          Thanks for the reply Ron. Here we are mostly dealing with defects. How can we measure the teams velocity? As defects are assigned to the team members they are not in a position to assign story points to it. Can we assign story points after fixing the defects, as now the developer knows the size of the work item? This will help us build a history and we can use this to predict the velocity for future sprints? How should we approach this issue when fixing defects? what is a good metrics in this situation?

          Regards
          Rohit




          Find out how here Use Messenger in your Hotmail inbox

        • wnoida
          Ron, As we are dealing with defects, it is difficult to know the size for a defect before digging into the code. Once developers dig into the code and analyze
          Message 4 of 26 , Sep 2, 2009
            Ron,

            As we are dealing with defects, it is difficult to know the size for a defect before digging into the code. Once developers dig into the code and analyze the cause for a defect, they are very near to actually fixing it. How do we tackle this in 2 hours of sprint planning? We have a weekly sprint as high priority bugs keep coming in.
            Can we attach story points post fixing the bugs for the sake of building a history of story points covered in a sprint and then use that to predict the future commitments?

            Regards
            Rohit




            --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
            >
            > Hello, wnoida. On Tuesday, September 1, 2009, at 4:09:17 PM, you
            > wrote:
            >
            > > Thanks for the reply Ron. Here we are mostly dealing with
            > > defects. How can we measure the teams velocity? As defects are
            > > assigned to the team members they are not in a position to assign
            > > story points to it. Can we assign story points after fixing the
            > > defects, as now the developer knows the size of the work item?
            > > This will help us build a history and we can use this to predict
            > > the velocity for future sprints? How should we approach this issue
            > > when fixing defects? what is a good metrics in this situation?
            >
            > Velocity = # stories per sprint. When stories are defects, velocity
            > may not even be stable. In any case, why not just count them?
            >
            > Ron Jeffries
            > www.XProgramming.com
            > www.xprogramming.com/blog
            > Think! -- Aretha Franklin
            >
          • wnoida
            Thanks Roy. But then how do we get our velocity? How do we assign story points to defects upfront? How do we show case our productivity if it is increasing or
            Message 5 of 26 , Sep 2, 2009
              Thanks Roy. But then how do we get our velocity? How do we assign story points to defects upfront? How do we show case our productivity if it is increasing or decreasing? Please also See my last comment to Ron.

              Regards
              Rohit


              --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@...> wrote:
              >
              >
              > It seems to me that the effort in fixing a defect can be reasonably counted in the team's velocity. Maybe it will be of interest as to why the defect occurred, and certainly there will be some effort in clearly understanding what the defect is, and how to rectify it ... but, velocity is a measure of how much 'effort and complexity' a team can achieve in a sprint. Where does it say that velocity can only measure effort on new, 'green fields' work?
              > The cause of the defect, the reason it occurred, the reason that it was not detected during the development of the feature in which the defect occurred, can be considered in a review or sprint retrospective, so that the process of development can be improved to avoid the same situation occurring again. But this is not part of 'velocity'.
              > My reaction to the statement 'they need to spend more time ... more than 4 hours' is 'maybe they would make better use of that time by getting on with fixing it, rather than trying to come up with a better estimate of when they will finish fixing it'. Sure , spend the necessary time understanding the problem, but to spend a lot of time trying to come up with a better estimate of time seems a rather unhelpful activity.
              > Regards,Roy Morien
              >
              > To: scrumdevelopment@yahoogroups.com
              > From: wnoida@...
              > Date: Tue, 1 Sep 2009 20:09:17 +0000
              > Subject: [scrumdevelopment] Re: Using Scrum for a maintenance / sustained engineering assignment
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              > --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@> wrote:
              >
              > >
              >
              > > Hello, wnoida. On Saturday, August 8, 2009, at 3:55:13 AM, you
              >
              > > wrote:
              >
              > >
              >
              > > > The biggest challenge we are facing is with second part of the
              >
              > > > sprint planning meeting. Once the team understands the priortized
              >
              > > > backlog items, they need to spend time with the application,
              >
              > > > explore the code, gain more functional knowledge before they can
              >
              > > > come up with the commitment and some estimates. This exercise
              >
              > > > needs more than 4 hours. The collaoration between Developers and
              >
              > > > Testers also becomes challenging.
              >
              > >
              >
              > > What value would you get if it didn't take that long? Why not just
              >
              > > prioritize the defects and start working?
              >
              > >
              >
              > > Ron Jeffries
              >
              > > www.XProgramming.com
              >
              > > www.xprogramming.com/blog
              >
              > > Yesterday's code should be as good as we could make it yesterday.
              >
              > > The fact that we know more today, and are more capable today,
              >
              > > is good news about today, not bad news about yesterday.
              >
              > >
              >
              > Thanks for the reply Ron. Here we are mostly dealing with defects. How can we measure the teams velocity? As defects are assigned to the team members they are not in a position to assign story points to it. Can we assign story points after fixing the defects, as now the developer knows the size of the work item? This will help us build a history and we can use this to predict the velocity for future sprints? How should we approach this issue when fixing defects? what is a good metrics in this situation?
              >
              >
              >
              > Regards
              >
              > Rohit
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              >
              > _________________________________________________________________
              > Use Messenger in your Hotmail inbox Find out how here
              > http://windowslive.ninemsn.com.au/article.aspx?id=823454
              >
            • wnoida
              Thanks for the response Jacob. Yes, the problem is with the code. We have limited test automation, we are working on it in parallel. The defects are coming
              Message 6 of 26 , Sep 2, 2009
                Thanks for the response Jacob.
                Yes, the problem is with the code. We have limited test automation, we are working on it in parallel. The defects are coming from regression testing being done by the QA team, also some of the clients participating in the Beta are reporting the defects.

                I can see the team spending the next 3-4 months stablizing the product. We are currently doing weekly sprints to accomodate higher priority defects that are getting reported every day.

                I want to have a metrics for the rest of the organization to see how we are doing? what is our productivity? Are we improving (better productivity and quality) after adopting scrum / agile process?

                Any suggestions?

                Regards
                Rohit

                --- In scrumdevelopment@yahoogroups.com, Jacob <jacob@...> wrote:
                >
                > Hello,
                >
                > Are you running automated tests?
                >
                > I get the impression that the code is causing the problem here, not the
                > estimations of velocity of the team.
                >
                > I would do some major code review sessions before tackling bugs which, in my
                > opinion, the users should not be the ones reporting.
                >
                > For me, velocity is an estimate of how much functionality items can be
                > delivered at the end of a sprint. Even story points are not entirely
                > necessary. As a PO I would even be happy with a velocity measurements of 'a
                > couple \ a few \ a handful \ many'.
                >
                > In that sense you can treat bug fixing in the same way. How many bugs will
                > be fixed? Many? A couple? That becomes your velocity.
                >
                > But what do you want to use the velocity measurement for? Are you devising a
                > release plan? Are you trying to estimate when all bugs will be fixed?
                >
                > Jacob
                >
                >
                > On Wed, Sep 2, 2009 at 12:17 PM, Roy Morien <roymorien@...> wrote:
                >
                > >
                > >
                > > It seems to me that the effort in fixing a defect can be reasonably counted
                > > in the team's velocity. Maybe it will be of interest as to why the defect
                > > occurred, and certainly there will be some effort in clearly understanding
                > > what the defect is, and how to rectify it ... but, velocity is a measure of
                > > how much 'effort and complexity' a team can achieve in a sprint. Where does
                > > it say that velocity can only measure effort on new, 'green fields' work?
                > >
                > > The cause of the defect, the reason it occurred, the reason that it was not
                > > detected during the development of the feature in which the defect occurred,
                > > can be considered in a review or sprint retrospective, so that the process
                > > of development can be improved to avoid the same situation occurring again.
                > > But this is not part of 'velocity'.
                > >
                > > My reaction to the statement 'they need to spend more time ... more than 4
                > > hours' is 'maybe they would make better use of that time by getting on with
                > > fixing it, rather than trying to come up with a better estimate of when they
                > > will finish fixing it'. Sure , spend the necessary time understanding the
                > > problem, but to spend a lot of time trying to come up with a better estimate
                > > of time seems a rather unhelpful activity.
                > >
                > > Regards,
                > > Roy Morien
                > >
                > > ------------------------------
                > > To: scrumdevelopment@yahoogroups.com
                > > From: wnoida@...
                > > Date: Tue, 1 Sep 2009 20:09:17 +0000
                > > Subject: [scrumdevelopment] Re: Using Scrum for a maintenance / sustained
                > > engineering assignment
                > >
                > >
                > > --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@>
                > > wrote:
                > > >
                > > > Hello, wnoida. On Saturday, August 8, 2009, at 3:55:13 AM, you
                > > > wrote:
                > > >
                > > > > The biggest challenge we are facing is with second part of the
                > > > > sprint planning meeting. Once the team understands the priortized
                > > > > backlog items, they need to spend time with the application,
                > > > > explore the code, gain more functional knowledge before they can
                > > > > come up with the commitment and some estimates. This exercise
                > > > > needs more than 4 hours. The collaoration between Developers and
                > > > > Testers also becomes challenging.
                > > >
                > > > What value would you get if it didn't take that long? Why not just
                > > > prioritize the defects and start working?
                > > >
                > > > Ron Jeffries
                > > > www.XProgramming.com
                > > > www.xprogramming.com/blog
                > > > Yesterday's code should be as good as we could make it yesterday.
                > > > The fact that we know more today, and are more capable today,
                > > > is good news about today, not bad news about yesterday.
                > > >
                > > Thanks for the reply Ron. Here we are mostly dealing with defects. How can
                > > we measure the teams velocity? As defects are assigned to the team members
                > > they are not in a position to assign story points to it. Can we assign story
                > > points after fixing the defects, as now the developer knows the size of the
                > > work item? This will help us build a history and we can use this to predict
                > > the velocity for future sprints? How should we approach this issue when
                > > fixing defects? what is a good metrics in this situation?
                > >
                > > Regards
                > > Rohit
                > >
                > >
                > >
                > > ------------------------------
                > > Find out how here Use Messenger in your Hotmail inbox<http://windowslive.ninemsn.com.au/article.aspx?id=823454>
                > >
                > >
                >
              • Doug McQuilken
                Rohit, Our team just estimated each defect in story points and started working on them. We found this to be an effective approach. Regards, Doug ... From:
                Message 7 of 26 , Sep 2, 2009
                  Rohit,

                  Our team just estimated each defect in story points and started working on them.
                  We found this to be an effective approach.

                  Regards,
                  Doug


                  --- On Wed, 9/2/09, wnoida <wnoida@...> wrote:

                  From: wnoida <wnoida@...>
                  Subject: [scrumdevelopment] Re: Using Scrum for a maintenance / sustained engineering assignment
                  To: scrumdevelopment@yahoogroups.com
                  Date: Wednesday, September 2, 2009, 11:28 AM

                   

                  Ron,

                  As we are dealing with defects, it is difficult to know the size for a defect before digging into the code. Once developers dig into the code and analyze the cause for a defect, they are very near to actually fixing it. How do we tackle this in 2 hours of sprint planning? We have a weekly sprint as high priority bugs keep coming in.
                  Can we attach story points post fixing the bugs for the sake of building a history of story points covered in a sprint and then use that to predict the future commitments?

                  Regards
                  Rohit

                  --- In scrumdevelopment@ yahoogroups. com, Ron Jeffries <ronjeffries@ ...> wrote:
                  >
                  > Hello, wnoida. On Tuesday, September 1, 2009, at 4:09:17 PM, you
                  > wrote:
                  >
                  > > Thanks for the reply Ron. Here we are mostly dealing with
                  > > defects. How can we measure the teams velocity? As defects are
                  > > assigned to the team members they are not in a position to assign
                  > > story points to it. Can we assign story points after fixing the
                  > > defects, as now the developer knows the size of the work item?
                  > > This will help us build a history and we can use this to predict
                  > > the velocity for future sprints? How should we approach this issue
                  > > when fixing defects? what is a good metrics in this situation?
                  >
                  > Velocity = # stories per sprint. When stories are defects, velocity
                  > may not even be stable. In any case, why not just count them?
                  >
                  > Ron Jeffries
                  > www.XProgramming. com
                  > www.xprogramming. com/blog
                  > Think! -- Aretha Franklin
                  >

                • Ron Jeffries
                  Hello, wnoida. On Wednesday, September 2, 2009, at 11:28:35 AM, ... We can t guess the story points on a defect in advance, almost ever. So just count them:
                  Message 8 of 26 , Sep 2, 2009
                    Hello, wnoida. On Wednesday, September 2, 2009, at 11:28:35 AM,
                    you wrote:

                    > As we are dealing with defects, it is difficult to know the size
                    > for a defect before digging into the code. Once developers dig
                    > into the code and analyze the cause for a defect, they are very
                    > near to actually fixing it. How do we tackle this in 2 hours of
                    > sprint planning? We have a weekly sprint as high priority bugs keep coming in.

                    > Can we attach story points post fixing the bugs for the sake of
                    > building a history of story points covered in a sprint and then
                    > use that to predict the future commitments?

                    We can't guess the story points on a defect in advance, almost ever.
                    So just count them: the distribution of sizes isn't likely to
                    change, and that will provide the best prediction possible.

                    Ron Jeffries
                    www.XProgramming.com
                    www.xprogramming.com/blog
                    To gain knowledge, add something every day;
                    to gain wisdom, remove something every day.
                    -- Lao Tzu
                  • wnoida
                    Thanks Ron.It helped a lot. Regards Rohit
                    Message 9 of 26 , Sep 2, 2009
                      Thanks Ron.It helped a lot.

                      Regards
                      Rohit


                      --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                      >
                      > Hello, wnoida. On Wednesday, September 2, 2009, at 11:28:35 AM,
                      > you wrote:
                      >
                      > > As we are dealing with defects, it is difficult to know the size
                      > > for a defect before digging into the code. Once developers dig
                      > > into the code and analyze the cause for a defect, they are very
                      > > near to actually fixing it. How do we tackle this in 2 hours of
                      > > sprint planning? We have a weekly sprint as high priority bugs keep coming in.
                      >
                      > > Can we attach story points post fixing the bugs for the sake of
                      > > building a history of story points covered in a sprint and then
                      > > use that to predict the future commitments?
                      >
                      > We can't guess the story points on a defect in advance, almost ever.
                      > So just count them: the distribution of sizes isn't likely to
                      > change, and that will provide the best prediction possible.
                      >
                      > Ron Jeffries
                      > www.XProgramming.com
                      > www.xprogramming.com/blog
                      > To gain knowledge, add something every day;
                      > to gain wisdom, remove something every day.
                      > -- Lao Tzu
                      >
                    • Gary Brown
                      Hey wnoida, One thing that you can do is measure the actual time spent investigating, tracking, fixing, and cleaning up after defects. Defects are waste. You
                      Message 10 of 26 , Sep 2, 2009
                        Hey wnoida,

                        One thing that you can do is measure the actual time spent investigating,
                        tracking, fixing, and cleaning up after defects. Defects are waste. You
                        can use that info to encourage people to improve their TDD practice and
                        maybe even encourage folks to pair more.

                        Defects are not required. Time spent on them would be better used providing
                        value to the Customer.

                        GB.
                      • Roy Morien
                        wnoida made the point about needing time to investigate the defect and find out as much information about it as they can before estimating it. That seems to me
                        Message 11 of 26 , Sep 2, 2009

                          wnoida made the point about needing time to investigate the defect and find out as much information about it as they can before estimating it. That seems to me to be just the same as estimating any other User Story. First, you have a User Story (make a User Story about the defect), then when the time comes to do something about it, put it on the table for analysis and estimating. Why would a defect be necessarily and significantly more difficult to estimate than any other User Story?

                          So, Doug, exactly what was your process in doing what you did? from realising there was a defect until the defect was delivered 'fixed'.

                          Regards,
                          Roy Morien

                          To: scrumdevelopment@yahoogroups.com
                          From: dougmcq000@...
                          Date: Wed, 2 Sep 2009 08:48:25 -0700
                          Subject: Re: [scrumdevelopment] Re: Using Scrum for a maintenance / sustained engineering assignment

                           

                          Rohit,

                          Our team just estimated each defect in story points and started working on them.
                          We found this to be an effective approach.

                          Regards,
                          Doug


                          --- On Wed, 9/2/09, wnoida <wnoida@yahoo. com> wrote:

                          From: wnoida <wnoida@yahoo. com>
                          Subject: [scrumdevelopment] Re: Using Scrum for a maintenance / sustained engineering assignment
                          To: scrumdevelopment@ yahoogroups. com
                          Date: Wednesday, September 2, 2009, 11:28 AM

                           
                          Ron,

                          As we are dealing with defects, it is difficult to know the size for a defect before digging into the code. Once developers dig into the code and analyze the cause for a defect, they are very near to actually fixing it. How do we tackle this in 2 hours of sprint planning? We have a weekly sprint as high priority bugs keep coming in.
                          Can we attach story points post fixing the bugs for the sake of building a history of story points covered in a sprint and then use that to predict the future commitments?

                          Regards
                          Rohit

                          --- In scrumdevelopment@ yahoogroups. com, Ron Jeffries <ronjeffries@ ...> wrote:
                          >
                          > Hello, wnoida. On Tuesday, September 1, 2009, at 4:09:17 PM, you
                          > wrote:
                          >
                          > > Thanks for the reply Ron. Here we are mostly dealing with
                          > > defects. How can we measure the teams velocity? As defects are
                          > > assigned to the team members they are not in a position to assign
                          > > story points to it. Can we assign story points after fixing the
                          > > defects, as now the developer knows the size of the work item?
                          > > This will help us build a history and we can use this to predict
                          > > the velocity for future sprints? How should we approach this issue
                          > > when fixing defects? what is a good metrics in this situation?
                          >
                          > Velocity = # stories per sprint. When stories are defects, velocity
                          > may not even be stable. In any case, why not just count them?
                          >
                          > Ron Jeffries
                          > www.XProgramming. com
                          > www.xprogramming. com/blog
                          > Think! -- Aretha Franklin
                          >





                          Click Here View photos of singles in your area
                        • Roy Morien
                          Is velocity about productivity? I don t think so. I think velocity is about being able to see how much the team can achieve so that they have a fairly
                          Message 12 of 26 , Sep 2, 2009
                            Is 'velocity' about 'productivity? I don't think so. I think 'velocity' is about being able to see how much the team can achieve so that they have a fairly good idea of their ability to meet, or to state, deadlines. Is that 'productivity'? I don't think it is. Velocity can also be used as an indication (not a 'measure') of team improvement in their achievements. 

                            When you ask about measuring 'productivity', what exactly are you trying to measure? 

                            Regards,
                            Roy Morien


                            To: scrumdevelopment@yahoogroups.com
                            From: wnoida@...
                            Date: Wed, 2 Sep 2009 15:32:47 +0000
                            Subject: [scrumdevelopment] Re: Using Scrum for a maintenance / sustained engineering assignment

                             
                            Thanks Roy. But then how do we get our velocity? How do we assign story points to defects upfront? How do we show case our productivity if it is increasing or decreasing? Please also See my last comment to Ron.

                            Regards
                            Rohit

                            --- In scrumdevelopment@ yahoogroups. com, Roy Morien <roymorien@. ..> wrote:
                            >
                            >
                            > It seems to me that the effort in fixing a defect can be reasonably counted in the team's velocity. Maybe it will be of interest as to why the defect occurred, and certainly there will be some effort in clearly understanding what the defect is, and how to rectify it ... but, velocity is a measure of how much 'effort and complexity' a team can achieve in a sprint. Where does it say that velocity can only measure effort on new, 'green fields' work?
                            > The cause of the defect, the reason it occurred, the reason that it was not detected during the development of the feature in which the defect occurred, can be considered in a review or sprint retrospective, so that the process of development can be improved to avoid the same situation occurring again. But this is not part of 'velocity'.
                            > My reaction to the statement 'they need to spend more time ... more than 4 hours' is 'maybe they would make better use of that time by getting on with fixing it, rather than trying to come up with a better estimate of when they will finish fixing it'. Sure , spend the necessary time understanding the problem, but to spend a lot of time trying to come up with a better estimate of time seems a rather unhelpful activity.
                            > Regards,Roy Morien
                            >
                            > To: scrumdevelopment@ yahoogroups. com
                            > From: wnoida@...
                            > Date: Tue, 1 Sep 2009 20:09:17 +0000
                            > Subject: [scrumdevelopment] Re: Using Scrum for a maintenance / sustained engineering assignment
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            > --- In scrumdevelopment@ yahoogroups. com, Ron Jeffries <ronjeffries@ > wrote:
                            >
                            > >
                            >
                            > > Hello, wnoida. On Saturday, August 8, 2009, at 3:55:13 AM, you
                            >
                            > > wrote:
                            >
                            > >
                            >
                            > > > The biggest challenge we are facing is with second part of the
                            >
                            > > > sprint planning meeting. Once the team understands the priortized
                            >
                            > > > backlog items, they need to spend time with the application,
                            >
                            > > > explore the code, gain more functional knowledge before they can
                            >
                            > > > come up with the commitment and some estimates. This exercise
                            >
                            > > > needs more than 4 hours. The collaoration between Developers and
                            >
                            > > > Testers also becomes challenging.
                            >
                            > >
                            >
                            > > What value would you get if it didn't take that long? Why not just
                            >
                            > > prioritize the defects and start working?
                            >
                            > >
                            >
                            > > Ron Jeffries
                            >
                            > > www.XProgramming. com
                            >
                            > > www.xprogramming. com/blog
                            >
                            > > Yesterday's code should be as good as we could make it yesterday.
                            >
                            > > The fact that we know more today, and are more capable today,
                            >
                            > > is good news about today, not bad news about yesterday.
                            >
                            > >
                            >
                            > Thanks for the reply Ron. Here we are mostly dealing with defects. How can we measure the teams velocity? As defects are assigned to the team members they are not in a position to assign story points to it. Can we assign story points after fixing the defects, as now the developer knows the size of the work item? This will help us build a history and we can use this to predict the velocity for future sprints? How should we approach this issue when fixing defects? what is a good metrics in this situation?
                            >
                            >
                            >
                            > Regards
                            >
                            > Rohit
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            > ____________ _________ _________ _________ _________ _________ _
                            > Use Messenger in your Hotmail inbox Find out how here
                            > http://windowslive. ninemsn.com. au/article. aspx?id=823454
                            >




                            Click Here View photos of singles in your area
                          • Roy Morien
                            Well, how do you assign story points to any story up front ? Presumably you identify the development need, stated as a User Story. Then, you give some thought
                            Message 13 of 26 , Sep 2, 2009
                              Well, how do you assign story points to any story 'up front'? Presumably you identify the development need, stated as a User Story. Then, you give some thought to how complex and difficult and potentially time consuming this will be, and assign story points. So with your defect, you turn it into a User Story, give some initial thought to how many story points it implies, give it a priority to mark its place in the Project Backlog. Depending on  its priority, you assign it into a Sprint Backlog.

                              I can hear your response already :) but again I ask you the question How do /you/ assign story points to any User Story? At what point in your iteration cycle do you dig down into the details of a User Story, any User Story, to discover the details and estimate the effort needed to deliver it?

                              So having 'reduced' the defect User Story to story points (assuming you are using story points as your estimating and 'velocity' unit, you treat it just like any other User Story ... at least, I would do that  ... and then you will incorporate it into your velocity measurement. Just because it is a defect, and is therefore probably treading back over old ground somewhat doesn't mean the team is expending zero effort, or effort that should not be counted. Velocity is not some sort of progress measure, it is a measure of the teams work rate, useful for future estimating, and 'measuring' team capacity to deliver / work rate. 

                              Regards,
                              Roy Morien

                              To: scrumdevelopment@yahoogroups.com
                              From: wnoida@...
                              Date: Wed, 2 Sep 2009 15:32:47 +0000
                              Subject: [scrumdevelopment] Re: Using Scrum for a maintenance / sustained engineering assignment

                               
                              Thanks Roy. But then how do we get our velocity? How do we assign story points to defects upfront? How do we show case our productivity if it is increasing or decreasing? Please also See my last comment to Ron.

                              Regards
                              Rohit

                              --- In scrumdevelopment@ yahoogroups. com, Roy Morien <roymorien@. ..> wrote:
                              >
                              >
                              > It seems to me that the effort in fixing a defect can be reasonably counted in the team's velocity. Maybe it will be of interest as to why the defect occurred, and certainly there will be some effort in clearly understanding what the defect is, and how to rectify it ... but, velocity is a measure of how much 'effort and complexity' a team can achieve in a sprint. Where does it say that velocity can only measure effort on new, 'green fields' work?
                              > The cause of the defect, the reason it occurred, the reason that it was not detected during the development of the feature in which the defect occurred, can be considered in a review or sprint retrospective, so that the process of development can be improved to avoid the same situation occurring again. But this is not part of 'velocity'.
                              > My reaction to the statement 'they need to spend more time ... more than 4 hours' is 'maybe they would make better use of that time by getting on with fixing it, rather than trying to come up with a better estimate of when they will finish fixing it'. Sure , spend the necessary time understanding the problem, but to spend a lot of time trying to come up with a better estimate of time seems a rather unhelpful activity.
                              > Regards,Roy Morien
                              >
                              > To: scrumdevelopment@ yahoogroups. com
                              > From: wnoida@...
                              > Date: Tue, 1 Sep 2009 20:09:17 +0000
                              > Subject: [scrumdevelopment] Re: Using Scrum for a maintenance / sustained engineering assignment
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              > --- In scrumdevelopment@ yahoogroups. com, Ron Jeffries <ronjeffries@ > wrote:
                              >
                              > >
                              >
                              > > Hello, wnoida. On Saturday, August 8, 2009, at 3:55:13 AM, you
                              >
                              > > wrote:
                              >
                              > >
                              >
                              > > > The biggest challenge we are facing is with second part of the
                              >
                              > > > sprint planning meeting. Once the team understands the priortized
                              >
                              > > > backlog items, they need to spend time with the application,
                              >
                              > > > explore the code, gain more functional knowledge before they can
                              >
                              > > > come up with the commitment and some estimates. This exercise
                              >
                              > > > needs more than 4 hours. The collaoration between Developers and
                              >
                              > > > Testers also becomes challenging.
                              >
                              > >
                              >
                              > > What value would you get if it didn't take that long? Why not just
                              >
                              > > prioritize the defects and start working?
                              >
                              > >
                              >
                              > > Ron Jeffries
                              >
                              > > www.XProgramming. com
                              >
                              > > www.xprogramming. com/blog
                              >
                              > > Yesterday's code should be as good as we could make it yesterday.
                              >
                              > > The fact that we know more today, and are more capable today,
                              >
                              > > is good news about today, not bad news about yesterday.
                              >
                              > >
                              >
                              > Thanks for the reply Ron. Here we are mostly dealing with defects. How can we measure the teams velocity? As defects are assigned to the team members they are not in a position to assign story points to it. Can we assign story points after fixing the defects, as now the developer knows the size of the work item? This will help us build a history and we can use this to predict the velocity for future sprints? How should we approach this issue when fixing defects? what is a good metrics in this situation?
                              >
                              >
                              >
                              > Regards
                              >
                              > Rohit
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              > ____________ _________ _________ _________ _________ _________ _
                              > Use Messenger in your Hotmail inbox Find out how here
                              > http://windowslive. ninemsn.com. au/article. aspx?id=823454
                              >




                              Let us find your next place for you! Need a place to rent, buy or share?
                            • Ron Jeffries
                              Hello, Roy. On Thursday, September 3, 2009, at 2:38:51 AM, you ... Story points for stories are easy: you know pretty well what you are going to do. Story
                              Message 14 of 26 , Sep 3, 2009
                                Hello, Roy. On Thursday, September 3, 2009, at 2:38:51 AM, you
                                wrote:

                                > Well, how do you assign story points to any story 'up front'?

                                Story points for stories are easy: you know pretty well what you are
                                going to do. Story points for defects are hard, because you don't.

                                Ron Jeffries
                                www.XProgramming.com
                                www.xprogramming.com/blog
                                You have to either laugh or cry. -- Bill Rogers
                              • wnoida
                                I agree with you Ron. This is what we are discovering that it is difficult to assign story points for defects. As I asked in the previous message: Can we gauge
                                Message 15 of 26 , Sep 3, 2009
                                  I agree with you Ron.

                                  This is what we are discovering that it is difficult to assign story points for defects. As I asked in the previous message: Can we gauge story points after fixing the defect so that we can use it for velocity calculations? If not then what is the best approach to work on defects in a scrum mode? We are only fixing defects in our sprints.

                                  Regards
                                  Rohit

                                  --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                                  >
                                  > Hello, Roy. On Thursday, September 3, 2009, at 2:38:51 AM, you
                                  > wrote:
                                  >
                                  > > Well, how do you assign story points to any story 'up front'?
                                  >
                                  > Story points for stories are easy: you know pretty well what you are
                                  > going to do. Story points for defects are hard, because you don't.
                                  >
                                  > Ron Jeffries
                                  > www.XProgramming.com
                                  > www.xprogramming.com/blog
                                  > You have to either laugh or cry. -- Bill Rogers
                                  >
                                • George Dinwiddie
                                  ... Rohit, what will you gain if you assign story points to defects after they re done and use that for velocity? Will that help you know how many defects you
                                  Message 16 of 26 , Sep 3, 2009
                                    wnoida wrote:
                                    > This is what we are discovering that it is difficult to assign story
                                    > points for defects. As I asked in the previous message: Can we gauge
                                    > story points after fixing the defect so that we can use it for
                                    > velocity calculations? If not then what is the best approach to work
                                    > on defects in a scrum mode? We are only fixing defects in our
                                    > sprints.

                                    Rohit, what will you gain if you assign story points to defects after
                                    they're done and use that for velocity? Will that help you know how
                                    many defects you can fix in the next sprint?

                                    If you merely count the number of defects closed each sprint, does the
                                    number jump around wildly?

                                    If you're /only/ fixing defects, perhaps you don't want to commit to a
                                    given amount of work at all. Perhaps you want to go to a "kanban"
                                    technique where you have a prioritized list of open defects, pull the
                                    the top one off and work on it (with as many people as can productively
                                    do so) until it's done. Then those people look to see if they can help
                                    with other defect fixes in progress and, if not, pull the next defect
                                    off the backlog.

                                    If you do this, I suspect you'll still find velocity (in # of defects,
                                    not story points) useful for tracking, though less so for planning. I
                                    also suspect that determining velocity after the fact will make it
                                    pretty useless.

                                    - George

                                    --
                                    ----------------------------------------------------------------------
                                    * George Dinwiddie * http://blog.gdinwiddie.com
                                    Software Development http://www.idiacomputing.com
                                    Consultant and Coach http://www.agilemaryland.org
                                    ----------------------------------------------------------------------
                                  • Ron Jeffries
                                    Hello, wnoida. On Thursday, September 3, 2009, at 8:58:05 AM, you ... Burn down stories, not points - the story line points to done date. You can totally
                                    Message 17 of 26 , Sep 3, 2009
                                      Hello, wnoida. On Thursday, September 3, 2009, at 8:58:05 AM, you
                                      wrote:

                                      > This is what we are discovering that it is difficult to assign
                                      > story points for defects. As I asked in the previous message: Can
                                      > we gauge story points after fixing the defect so that we can use
                                      > it for velocity calculations? If not then what is the best
                                      > approach to work on defects in a scrum mode? We are only fixing defects in our sprints.

                                      Burn down stories, not points -> the story line points to done date.

                                      You can totally ignore defect impact. If you fix fewer defects,
                                      story progress will go up.

                                      If you want to /predict/ what will happen when defect fixing goes
                                      down ... well, first make defects go down, then let's talk ...

                                      Ron Jeffries
                                      www.XProgramming.com
                                      www.xprogramming.com/blog
                                      I could be wrong, of course. It's just not the way to bet.
                                    • wnoida
                                      Hi George, When we assign story points to a user story and at the end of the sprint see how many story points we covered, it does help in predicting the
                                      Message 18 of 26 , Sep 3, 2009
                                        Hi George,

                                        When we assign story points to a user story and at the end of the sprint see how many story points we covered, it does help in predicting the velocity in long run, right. By assigning story points to defects after fixing i was looking for the same calculations.

                                        The number of defects changes based on the complexity of the defect, which we do not know upfront. So if i fix few complex, few medium and some simple defects in a sprint and have story points attached to them. Then in the next sprint i can look forward to achieve a similiar velocity but the mix of complex, medium and simple might differ.

                                        Currently we are following a approach similiar to what you have described. I just wanted to know from the others if this is the right way to handle defects in scrum mode.

                                        Thanks for your inputs.

                                        Regards
                                        Rohit



                                        --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@...> wrote:
                                        >
                                        > wnoida wrote:
                                        > > This is what we are discovering that it is difficult to assign story
                                        > > points for defects. As I asked in the previous message: Can we gauge
                                        > > story points after fixing the defect so that we can use it for
                                        > > velocity calculations? If not then what is the best approach to work
                                        > > on defects in a scrum mode? We are only fixing defects in our
                                        > > sprints.
                                        >
                                        > Rohit, what will you gain if you assign story points to defects after
                                        > they're done and use that for velocity? Will that help you know how
                                        > many defects you can fix in the next sprint?
                                        >
                                        > If you merely count the number of defects closed each sprint, does the
                                        > number jump around wildly?
                                        >
                                        > If you're /only/ fixing defects, perhaps you don't want to commit to a
                                        > given amount of work at all. Perhaps you want to go to a "kanban"
                                        > technique where you have a prioritized list of open defects, pull the
                                        > the top one off and work on it (with as many people as can productively
                                        > do so) until it's done. Then those people look to see if they can help
                                        > with other defect fixes in progress and, if not, pull the next defect
                                        > off the backlog.
                                        >
                                        > If you do this, I suspect you'll still find velocity (in # of defects,
                                        > not story points) useful for tracking, though less so for planning. I
                                        > also suspect that determining velocity after the fact will make it
                                        > pretty useless.
                                        >
                                        > - George
                                        >
                                        > --
                                        > ----------------------------------------------------------------------
                                        > * George Dinwiddie * http://blog.gdinwiddie.com
                                        > Software Development http://www.idiacomputing.com
                                        > Consultant and Coach http://www.agilemaryland.org
                                        > ----------------------------------------------------------------------
                                        >
                                      • wnoida
                                        Thanks Ron, I got valuable inputs. Regards Rohit
                                        Message 19 of 26 , Sep 3, 2009
                                          Thanks Ron, I got valuable inputs.

                                          Regards
                                          Rohit


                                          --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                                          >
                                          > Hello, wnoida. On Thursday, September 3, 2009, at 8:58:05 AM, you
                                          > wrote:
                                          >
                                          > > This is what we are discovering that it is difficult to assign
                                          > > story points for defects. As I asked in the previous message: Can
                                          > > we gauge story points after fixing the defect so that we can use
                                          > > it for velocity calculations? If not then what is the best
                                          > > approach to work on defects in a scrum mode? We are only fixing defects in our sprints.
                                          >
                                          > Burn down stories, not points -> the story line points to done date.
                                          >
                                          > You can totally ignore defect impact. If you fix fewer defects,
                                          > story progress will go up.
                                          >
                                          > If you want to /predict/ what will happen when defect fixing goes
                                          > down ... well, first make defects go down, then let's talk ...
                                          >
                                          > Ron Jeffries
                                          > www.XProgramming.com
                                          > www.xprogramming.com/blog
                                          > I could be wrong, of course. It's just not the way to bet.
                                          >
                                        • George Dinwiddie
                                          ... If it takes longer to fix, won t the assumption be that it s more complex? I think you ll reach the equivalent of This took me 8 hours, therefore it s 8
                                          Message 20 of 26 , Sep 3, 2009
                                            wnoida wrote:
                                            > Hi George,
                                            >
                                            > When we assign story points to a user story and at the end of the
                                            > sprint see how many story points we covered, it does help in
                                            > predicting the velocity in long run, right. By assigning story points
                                            > to defects after fixing i was looking for the same calculations.

                                            If it takes longer to fix, won't the assumption be that it's more
                                            complex? I think you'll reach the equivalent of "This took me 8 hours,
                                            therefore it's 8 story points." I can't see that helps.

                                            > The number of defects changes based on the complexity of the defect,
                                            > which we do not know upfront. So if i fix few complex, few medium and
                                            > some simple defects in a sprint and have story points attached to
                                            > them. Then in the next sprint i can look forward to achieve a
                                            > similiar velocity but the mix of complex, medium and simple might
                                            > differ.

                                            If you don't know upfront, then you'd have to wait until the end of the
                                            sprint to know how many defects will fit into the sprint. That doesn't
                                            sound very helpful to me.

                                            If you just count them, you could plot a histogram of fixes per sprint.
                                            Then you could say, "We usually fix X defects per sprint, but that
                                            number has been as high as Y on occasion or as low as Z." Would that be
                                            helpful?

                                            - George

                                            --
                                            ----------------------------------------------------------------------
                                            * George Dinwiddie * http://blog.gdinwiddie.com
                                            Software Development http://www.idiacomputing.com
                                            Consultant and Coach http://www.agilemaryland.org
                                            ----------------------------------------------------------------------
                                          • davenicolette
                                            George, I wonder if we re begging the question in this thread. Seems to me a process based on time-boxed iterations is helpful when we re building a defined
                                            Message 21 of 26 , Sep 4, 2009
                                              George,

                                              I wonder if we're begging the question in this thread. Seems to me a process based on time-boxed iterations is helpful when we're building a defined scope of work. When we're doing ongoing maintenance and fixes, it's a different sort of workflow. The size, urgency, and arrival times of work items are inherently unpredictable. The problems described in the thread seem to be related to the effort it takes to try and manage this sort of workflow in time-boxes, using the same mechanisms we use when we're burning down a defined scope. Maybe the answer to this question is to consider a different sort of process to manage this type of workflow.

                                              Dave

                                              --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@...> wrote:
                                              >
                                              > wnoida wrote:
                                              > > Hi George,
                                              > >
                                              > > When we assign story points to a user story and at the end of the
                                              > > sprint see how many story points we covered, it does help in
                                              > > predicting the velocity in long run, right. By assigning story points
                                              > > to defects after fixing i was looking for the same calculations.
                                              >
                                              > If it takes longer to fix, won't the assumption be that it's more
                                              > complex? I think you'll reach the equivalent of "This took me 8 hours,
                                              > therefore it's 8 story points." I can't see that helps.
                                              >
                                              > > The number of defects changes based on the complexity of the defect,
                                              > > which we do not know upfront. So if i fix few complex, few medium and
                                              > > some simple defects in a sprint and have story points attached to
                                              > > them. Then in the next sprint i can look forward to achieve a
                                              > > similiar velocity but the mix of complex, medium and simple might
                                              > > differ.
                                              >
                                              > If you don't know upfront, then you'd have to wait until the end of the
                                              > sprint to know how many defects will fit into the sprint. That doesn't
                                              > sound very helpful to me.
                                              >
                                              > If you just count them, you could plot a histogram of fixes per sprint.
                                              > Then you could say, "We usually fix X defects per sprint, but that
                                              > number has been as high as Y on occasion or as low as Z." Would that be
                                              > helpful?
                                              >
                                              > - George
                                              >
                                              > --
                                              > ----------------------------------------------------------------------
                                              > * George Dinwiddie * http://blog.gdinwiddie.com
                                              > Software Development http://www.idiacomputing.com
                                              > Consultant and Coach http://www.agilemaryland.org
                                              > ----------------------------------------------------------------------
                                              >
                                            • George Dinwiddie
                                              Dave, That s along the lines of what I m thinking. You ve said it much more clearly. I m suggesting that the process of choice for unpredictable work might be
                                              Message 22 of 26 , Sep 4, 2009
                                                Dave,

                                                That's along the lines of what I'm thinking. You've said it much more
                                                clearly.

                                                I'm suggesting that the process of choice for unpredictable work might
                                                be what some people call kanban:
                                                * a prioritized backlog queue of work to be done. (only the highest
                                                priority items need to be prioritized)
                                                * a limited amount of work in progress (limited to "as small as
                                                possible")

                                                with the addition of:
                                                * tracking the work accomplished by counting the items on a fixed,
                                                periodic basis. (e.g., count the items finished each week)

                                                If the arrival rate of work is more than the team can accomplish, the
                                                backlog will be growing, and something will need to be done about that.
                                                Otherwise, this seems to give maximum value possible, without wasting
                                                effort trying to exert more control and predictability than is possible.

                                                What do you (plural, meaning everyone) think?

                                                - George


                                                davenicolette wrote:
                                                > George,
                                                >
                                                > I wonder if we're begging the question in this thread. Seems to me a
                                                > process based on time-boxed iterations is helpful when we're building
                                                > a defined scope of work. When we're doing ongoing maintenance and
                                                > fixes, it's a different sort of workflow. The size, urgency, and
                                                > arrival times of work items are inherently unpredictable. The
                                                > problems described in the thread seem to be related to the effort it
                                                > takes to try and manage this sort of workflow in time-boxes, using
                                                > the same mechanisms we use when we're burning down a defined scope.
                                                > Maybe the answer to this question is to consider a different sort of
                                                > process to manage this type of workflow.
                                                >
                                                > Dave
                                                >
                                                > --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@...> wrote:
                                                >> wnoida wrote:
                                                >>> Hi George,
                                                >>>
                                                >>> When we assign story points to a user story and at the end of the
                                                >>> sprint see how many story points we covered, it does help in
                                                >>> predicting the velocity in long run, right. By assigning story points
                                                >>> to defects after fixing i was looking for the same calculations.
                                                >> If it takes longer to fix, won't the assumption be that it's more
                                                >> complex? I think you'll reach the equivalent of "This took me 8 hours,
                                                >> therefore it's 8 story points." I can't see that helps.
                                                >>
                                                >>> The number of defects changes based on the complexity of the defect,
                                                >>> which we do not know upfront. So if i fix few complex, few medium and
                                                >>> some simple defects in a sprint and have story points attached to
                                                >>> them. Then in the next sprint i can look forward to achieve a
                                                >>> similiar velocity but the mix of complex, medium and simple might
                                                >>> differ.
                                                >> If you don't know upfront, then you'd have to wait until the end of the
                                                >> sprint to know how many defects will fit into the sprint. That doesn't
                                                >> sound very helpful to me.
                                                >>
                                                >> If you just count them, you could plot a histogram of fixes per sprint.
                                                >> Then you could say, "We usually fix X defects per sprint, but that
                                                >> number has been as high as Y on occasion or as low as Z." Would that be
                                                >> helpful?

                                                --
                                                ----------------------------------------------------------------------
                                                * George Dinwiddie * http://blog.gdinwiddie.com
                                                Software Development http://www.idiacomputing.com
                                                Consultant and Coach http://www.agilemaryland.org
                                                ----------------------------------------------------------------------
                                              Your message has been successfully submitted and would be delivered to recipients shortly.