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

Re: Using Scrum for a maintenance / sustained engineering assignment

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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.