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

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

Expand Messages
  • Frank Rios
    Story points are based on estimated LOE. Effort is not the same thing as duration. The question should be, How much effort do you have left on this defect?
    Message 1 of 26 , Sep 1, 2009
    • 0 Attachment
      Story points are based on estimated LOE. Effort is not the same thing as duration. The question should be, "How much effort do you have left on this defect?"


      From: wnoida <wnoida@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Tuesday, September 1, 2009 3:09:17 PM
      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


    • 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 2 of 26 , Sep 1, 2009
      • 0 Attachment
        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 3 of 26 , Sep 2, 2009
        • 0 Attachment
          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 4 of 26 , Sep 2, 2009
          • 0 Attachment
            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 5 of 26 , Sep 2, 2009
            • 0 Attachment
              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 6 of 26 , Sep 2, 2009
              • 0 Attachment
                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 7 of 26 , Sep 2, 2009
                • 0 Attachment
                  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 8 of 26 , Sep 2, 2009
                  • 0 Attachment
                    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 9 of 26 , Sep 2, 2009
                    • 0 Attachment
                      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 10 of 26 , Sep 2, 2009
                      • 0 Attachment
                        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 11 of 26 , Sep 2, 2009
                        • 0 Attachment
                          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 12 of 26 , Sep 2, 2009
                          • 0 Attachment

                            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 13 of 26 , Sep 2, 2009
                            • 0 Attachment
                              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 14 of 26 , Sep 2, 2009
                              • 0 Attachment
                                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 15 of 26 , Sep 3, 2009
                                • 0 Attachment
                                  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 16 of 26 , Sep 3, 2009
                                  • 0 Attachment
                                    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 17 of 26 , Sep 3, 2009
                                    • 0 Attachment
                                      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 18 of 26 , Sep 3, 2009
                                      • 0 Attachment
                                        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 19 of 26 , Sep 3, 2009
                                        • 0 Attachment
                                          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 20 of 26 , Sep 3, 2009
                                          • 0 Attachment
                                            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 21 of 26 , Sep 3, 2009
                                            • 0 Attachment
                                              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 22 of 26 , Sep 4, 2009
                                              • 0 Attachment
                                                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 23 of 26 , Sep 4, 2009
                                                • 0 Attachment
                                                  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.