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

Discussion Point

Expand Messages
  • Paul Battisson
    Hey everyone, At my organisation, a discussion has recently broken out that I would like some opinion/clarification on. At the end of a sprint, it is well
    Message 1 of 19 , Aug 9, 2010
    • 0 Attachment
      Hey everyone,

      At my organisation, a discussion has recently broken out that I would like some opinion/clarification on. At the end of a sprint, it is well understood that you can only claim points for completed stories, but from my understanding the following two things are not correct:

      1) If the team has a 5 point story and it is felt that they spent closer to 8 points of effort on it, we can change the claimed number of points to 8 once the story is complete (again provided it is in the same sprint).
      2) If a team completes a bonus activity or story in a sprint, (for example in refactoring some work we manage to allow our self to extend the functionality of the product easily and cheaply as we had asked for in a future story) we can claim those bonus points for this sprint. (Apologies for the example here, it is a bit naive but only meant to be illustrative).

      I was led to believe in my agile training and readings that both those points were incorrect,. Am I correct or is it down to interpretation?

      Thanks

      Paul


    • Kurt Häusler
      ... You could, but tracking velocity incorporates the uncertainty of estimation, so there isn t much point. Just learn from it and attempt better estimates for
      Message 2 of 19 , Aug 9, 2010
      • 0 Attachment
        On Mon, Aug 9, 2010 at 2:15 PM, Paul Battisson <paulbattisson@...> wrote:
         

        1) If the team has a 5 point story and it is felt that they spent closer to 8 points of effort on it, we can change the claimed number of points to 8 once the story is complete (again provided it is in the same sprint).

        You could, but tracking velocity incorporates the uncertainty of estimation, so there isn't much point. Just learn from it and attempt better estimates for subsequent sprints.
         
        2) If a team completes a bonus activity or story in a sprint, (for example in refactoring some work we manage to allow our self to extend the functionality of the product easily and cheaply as we had asked for in a future story) we can claim those bonus points for this sprint. (Apologies for the example here, it is a bit naive but only meant to be illustrative).

        No I don't think so. I guess the "bonus" would come in being able to readjust backlog items with a lower estimate, and thus get more done in future sprints.

        Try not to think of velocity as a score, as in more is better. It is simply a tool to help plan the next sprint. Trying to game it doesn't improve anything real.
      • Ron Jeffries
        ... Both those things are incorrect. You are correct. I will write more later if it seems to be needed. Briefly, this kind of focus on points is evidence that
        Message 3 of 19 , Aug 9, 2010
        • 0 Attachment
          Hello, Paul. On Monday, August 9, 2010, at 8:15:59 AM, you wrote:

          > I was led to believe in my agile training and readings that both those points
          > were incorrect,. Am I correct or is it down to interpretation?

          Both those things are incorrect. You are correct. I will write more
          later if it seems to be needed.

          Briefly, this kind of focus on points is evidence that the team is
          being scored by how many points they accomplish. That is not a good
          way to operate a team.

          Ron Jeffries
          www.XProgramming.com
          www.xprogramming.com/blog
          Do I contradict myself? Very well then I contradict myself.
          (I am large, I contain multitudes.) --Walt Whitman
        • Kevin Johnston
          The purpose if the points/velocity is just to help you learn by what you have actually done. Hopefully what you actually have done allows you to guess/
          Message 4 of 19 , Aug 9, 2010
          • 0 Attachment
            The purpose if the points/velocity is just to help you learn by what you have actually done. Hopefully what you actually have done allows you to guess/ estimate that little but better in the next sprint with the same team. Don't get hung up on comparing teams and over analysing.

            Kevin

            Sent from my iPhone

            On 9 Aug 2010, at 13:15, Paul Battisson <paulbattisson@...> wrote:

             

            Hey everyone,

            At my organisation, a discussion has recently broken out that I would like some opinion/clarificati on on. At the end of a sprint, it is well understood that you can only claim points for completed stories, but from my understanding the following two things are not correct:

            1) If the team has a 5 point story and it is felt that they spent closer to 8 points of effort on it, we can change the claimed number of points to 8 once the story is complete (again provided it is in the same sprint).
            2) If a team completes a bonus activity or story in a sprint, (for example in refactoring some work we manage to allow our self to extend the functionality of the product easily and cheaply as we had asked for in a future story) we can claim those bonus points for this sprint. (Apologies for the example here, it is a bit naive but only meant to be illustrative) .

            I was led to believe in my agile training and readings that both those points were incorrect,. Am I correct or is it down to interpretation?

            Thanks

            Paul


          • Paul Battisson
            Thanks guys, it is good to clarify things just for certainty. I am trying to move the focus in the team away from a score and more onto targets and goals of
            Message 5 of 19 , Aug 9, 2010
            • 0 Attachment
              Thanks guys, it is good to clarify things just for certainty. I am trying to move the focus in the team away from a "score" and more onto targets and goals of functionality. Again thanks for all your help.


              From: Ron Jeffries <ronjeffries@...>
              To: scrumdevelopment@yahoogroups.com
              Sent: Mon, August 9, 2010 1:34:28 PM
              Subject: Re: [scrumdevelopment] Discussion Point

               

              Hello, Paul. On Monday, August 9, 2010, at 8:15:59 AM, you wrote:

              > I was led to believe in my agile training and readings that both those points
              > were incorrect,. Am I correct or is it down to interpretation?

              Both those things are incorrect. You are correct. I will write more
              later if it seems to be needed.

              Briefly, this kind of focus on points is evidence that the team is
              being scored by how many points they accomplish. That is not a good
              way to operate a team.

              Ron Jeffries
              www.XProgramming.com
              www.xprogramming.com/blog
              Do I contradict myself? Very well then I contradict myself.
              (I am large, I contain multitudes.) --Walt Whitman


            • Dave Smith
              Wanting credit for extra effort and for bonus work can also be a warning flag that the team is feeling under-appreciated for the effort they re putting in, and
              Message 6 of 19 , Aug 9, 2010
              • 0 Attachment
                Wanting credit for extra effort and for bonus work can also be a warning flag
                that the team is feeling under-appreciated for the effort they're putting in,
                and that you have an underlying morale problem to deal with.

                Dave


                On Mon, Aug 9, 2010 at 5:34 AM, Ron Jeffries <ronjeffries@...> wrote:
                Hello, Paul.  On Monday, August 9, 2010, at 8:15:59 AM, you wrote:

                > I was led to believe in my agile training and readings that both those points
                > were incorrect,. Am I correct or is it down to interpretation?

                Both those things are incorrect. You are correct. I will write more
                later if it seems to be needed.

                Briefly, this kind of focus on points is evidence that the team is
                being scored by how many points they accomplish. That is not a good
                way to operate a team.

                Ron Jeffries
                www.XProgramming.com
                www.xprogramming.com/blog
                Do I contradict myself? Very well then I contradict myself.
                (I am large, I contain multitudes.) --Walt Whitman



                ------------------------------------

                To Post a message, send it to:   scrumdevelopment@...
                To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

                <*> To visit your group on the web, go to:
                   http://groups.yahoo.com/group/scrumdevelopment/

                <*> Your email settings:
                   Individual Email | Traditional

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

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

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

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


              • Roy Morien
                The best way to get extra credit for development points is to re-evaluate your point scoring method, and re-estimate your Product Backlog. Instead of using a
                Message 7 of 19 , Aug 9, 2010
                • 0 Attachment
                  The best way to get extra credit for development points is to re-evaluate your point scoring method, and re-estimate your Product Backlog. Instead of using a 1-2-4-8 story points scale, use a 4-8-16-32 scale. That way your points score increases hugely, and your managers should be very pleased.
                   
                  Regards,
                  Roy Morien
                   

                  To: scrumdevelopment@yahoogroups.com
                  From: davewsmith@...
                  Date: Mon, 9 Aug 2010 11:03:59 -0700
                  Subject: Re: [scrumdevelopment] Discussion Point

                   
                  Wanting credit for extra effort and for bonus work can also be a warning flag
                  that the team is feeling under-appreciated for the effort they're putting in,
                  and that you have an underlying morale problem to deal with.

                  Dave


                  On Mon, Aug 9, 2010 at 5:34 AM, Ron Jeffries <ronjeffries@ acm.org> wrote:
                  Hello, Paul.  On Monday, August 9, 2010, at 8:15:59 AM, you wrote:

                  > I was led to believe in my agile training and readings that both those points
                  > were incorrect,. Am I correct or is it down to interpretation?

                  Both those things are incorrect. You are correct. I will write more
                  later if it seems to be needed.

                  Briefly, this kind of focus on points is evidence that the team is
                  being scored by how many points they accomplish. That is not a good
                  way to operate a team.

                  Ron Jeffries
                  www.XProgramming. com
                  www.xprogramming. com/blog
                  Do I contradict myself? Very well then I contradict myself.
                  (I am large, I contain multitudes.) --Walt Whitman



                  ------------ --------- --------- ------

                  To Post a message, send it to:   scrumdevelopment@ eGroups.com
                  To Unsubscribe, send a blank message to: scrumdevelopment- unsubscribe@ eGroups.comYahoo ! Groups Links

                  <*> To visit your group on the web, go to:
                     http://groups. yahoo.com/ group/scrumdevel opment/

                  <*> Your email settings:
                     Individual Email | Traditional

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

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

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

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



                • Ron Jeffries
                  ... Brilliant! Ron Jeffries www.XProgramming.com www.xprogramming.com/blog A lot of preconceptions can be dismissed when you actually try something out. --
                  Message 8 of 19 , Aug 9, 2010
                  • 0 Attachment
                    Hello, Roy. On Monday, August 9, 2010, at 10:59:15 PM, you wrote:

                    > The best way to get extra credit for development points is to
                    > re-evaluate your point scoring method, and re-estimate your
                    > Product Backlog. Instead of using a 1-2-4-8 story points scale,
                    > use a 4-8-16-32 scale. That way your points score increases
                    > hugely, and your managers should be very pleased.

                    Brilliant!

                    Ron Jeffries
                    www.XProgramming.com
                    www.xprogramming.com/blog
                    A lot of preconceptions can be dismissed when you actually
                    try something out. -- Bruce Eckel
                  • Paul Battisson
                    There seems to be no issue understanding that it is a relative system and that the number doesn t matter, but somewhere along the line a points to hours
                    Message 9 of 19 , Aug 10, 2010
                    • 0 Attachment
                      There seems to be no issue understanding that it is a relative system and that the number doesn't matter, but somewhere along the line a points to hours conversion seems to have slipped in. I am trying to squash that fallacy but such questions as the points I raised are asked - they are telling me "but that the way we were trained". 


                      From: Ron Jeffries <ronjeffries@...>
                      To: scrumdevelopment@yahoogroups.com
                      Sent: Tue, August 10, 2010 4:14:48 AM
                      Subject: Re: [scrumdevelopment] Discussion Point

                      Hello, Roy.  On Monday, August 9, 2010, at 10:59:15 PM, you wrote:

                      > The best way to get extra credit for development points is to
                      > re-evaluate your point scoring method, and re-estimate your
                      > Product Backlog. Instead of using a 1-2-4-8 story points scale,
                      > use a 4-8-16-32 scale. That way your points score increases
                      > hugely, and your managers should be very pleased.

                      Brilliant!

                      Ron Jeffries
                      www.XProgramming.com
                      www.xprogramming.com/blog
                      A lot of preconceptions can be dismissed when you actually
                      try something out. -- Bruce Eckel



                      ------------------------------------

                      To Post a message, send it to:  scrumdevelopment@...
                      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

                      <*> To visit your group on the web, go to:
                          http://groups.yahoo.com/group/scrumdevelopment/

                      <*> Your email settings:
                          Individual Email | Traditional

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

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

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

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


                    • Roy Morien
                      My grandfather was trained as a blacksmith ... he had a great career putting iron tyres on the wheels of carriages. Yes, that was the way he was trained. But
                      Message 10 of 19 , Aug 10, 2010
                      • 0 Attachment
                        My grandfather was trained as a blacksmith ... he had a great career putting iron 'tyres' on the wheels of carriages.
                         
                        Yes, that was the way he was trained.
                         
                        But when rubber tyres became common on cars, he stopped trying to put iron tyres on wheels, even though that was the way he was trained.
                         
                        Maybe there is a moral to this little story.
                         
                        Regards,
                        Roy Morien
                         

                        To: scrumdevelopment@yahoogroups.com
                        From: paulbattisson@...
                        Date: Tue, 10 Aug 2010 01:32:43 -0700
                        Subject: Re: [scrumdevelopment] Discussion Point

                         
                        There seems to be no issue understanding that it is a relative system and that the number doesn't matter, but somewhere along the line a points to hours conversion seems to have slipped in. I am trying to squash that fallacy but such questions as the points I raised are asked - they are telling me "but that the way we were trained". 


                        From: Ron Jeffries <ronjeffries@ acm.org>
                        To: scrumdevelopment@ yahoogroups. com
                        Sent: Tue, August 10, 2010 4:14:48 AM
                        Subject: Re: [scrumdevelopment] Discussion Point

                        Hello, Roy.  On Monday, August 9, 2010, at 10:59:15 PM, you wrote:

                        > The best way to get extra credit for development points is to
                        > re-evaluate your point scoring method, and re-estimate your
                        > Product Backlog. Instead of using a 1-2-4-8 story points scale,
                        > use a 4-8-16-32 scale. That way your points score increases
                        > hugely, and your managers should be very pleased.

                        Brilliant!

                        Ron Jeffries
                        www.XProgramming. com
                        www.xprogramming. com/blog
                        A lot of preconceptions can be dismissed when you actually
                        try something out. -- Bruce Eckel



                        ------------ --------- --------- ------

                        To Post a message, send it to:  scrumdevelopment@ eGroups.com
                        To Unsubscribe, send a blank message to: scrumdevelopment- unsubscribe@ eGroups.comYahoo! Groups Links

                        <*> To visit your group on the web, go to:
                            http://groups. yahoo.com/ group/scrumdevel opment/

                        <*> Your email settings:
                            Individual Email | Traditional

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

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

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

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



                      • pauloldfield1
                        (responding to Paul) I ll try to add to the good answers you already had. ... That doesn t help, because you are comparing against pre-existing estimations
                        Message 11 of 19 , Aug 10, 2010
                        • 0 Attachment
                          (responding to Paul)

                          I'll try to add to the good answers you already had.

                          > 1) If the team has a 5 point story and it is felt that they spent
                          > closer to 8 points of effort on it, we can change the claimed
                          > number of points to 8 once the story is complete

                          That doesn't help, because you are comparing against pre-existing
                          estimations that are equally likely to be equally accurate (or not).
                          If you have reason to believe things in the backlog have been "put
                          in the wrong bag size" then a re-estimate may be worth doing.
                          Normally it isn't worth doing (hint).

                          Your 'adjustment' for inaccuracies ideally happens at sprint
                          planning when, as a team, you decide how much to commit to. The
                          points give an idea of where you will be in a few iterations' time,
                          and if you try to use them for anything else you risk breaking
                          this mechanism.

                          > 2) If a team completes a bonus activity or story in a sprint,
                          > (for example in refactoring some work we manage to allow our
                          > self to extend the functionality of the product easily and
                          > cheaply as we had asked for in a future story) we can
                          > claim those bonus points for this sprint.

                          That (specific example) tells you you need to learn more about
                          splitting stories and sizing them... but again rather than
                          adjusting I would take the lessons learned to the retrospective.
                          Again you might find there's a generic situation with many
                          stories in the backlog, but if you adjust the backlog your
                          existing velocity is thrown in doubt. How important is it that
                          you need to predict well over the next few iterations? It may
                          take that long to get back to a velocity that is reasonably
                          reliable.

                          Hope this helps.
                          Paul Oldfield
                          Capgemini
                        • dave.barrett@lawpro.ca
                          Wow! This seems massively misguided to me. The Team s velocity is the Team s velocity. It s not something that incentives should be based on and they should
                          Message 12 of 19 , Aug 10, 2010
                          • 0 Attachment
                            Wow! This seems massively misguided to me.

                            The Team's velocity is the Team's velocity. It's not something that
                            incentives should be based on and they should never be scrambling to pick
                            up "points" after the fact.

                            That being said, the velocity is simply a planning tool. So you want it to
                            be as accurate as possible. Do you retroactively bump up the story points
                            for a really bad estimate? Maybe, if doing so is going to lead to more
                            accurate planning.

                            Dave Barrett
                            Project Manager
                            Lawyers' Professional Indemnity Company (LAWPRO®)
                            3101 - 250 Yonge Street
                            Toronto, Ontario M5B 2L7
                            Tel: 416-598-5800
                            Fax: 416-599-8341


                            This e-mail may be privileged and/or confidential, and the sender does not
                            waive any related rights and obligations. Any distribution, use or copying
                            of this e-mail or the information it contains by other than an intended
                            recipient is unauthorized. If you received this e-mail in error, please
                            delete it and advise me (by return e-mail or otherwise) immediately.

                            Ce courrier électronique est confidentiel et protégé. L'expéditeur ne
                            renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion,
                            utilisation ou copie de ce message ou des renseignements qu'il contient par
                            une personne autre que le (les) destinataire(s) désigné(s) est interdite.
                            Si vous recevez ce courrier électronique par erreur, veuillez le supprimer
                            et m'en aviser immédiatement, par retour de courrier électronique ou par un
                            autre moyen.
                          • extremeprogrammer
                            Woah! For less experienced agile teams, I suggest going to a 2-4-8-16 scale first. That 32 can be a little hard to handle. Regards, Lance
                            Message 13 of 19 , Aug 10, 2010
                            • 0 Attachment
                              Woah!

                              For less experienced agile teams, I suggest going to a 2-4-8-16 scale first. That 32 can be a little hard to handle.

                              Regards,

                              Lance

                              --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@...> wrote:
                              >
                              >
                              > The best way to get extra credit for development points is to re-evaluate your point scoring method, and re-estimate your Product Backlog. Instead of using a 1-2-4-8 story points scale, use a 4-8-16-32 scale. That way your points score increases hugely, and your managers should be very pleased.
                              >
                              >
                              >
                              > Regards,
                              >
                              > Roy Morien
                              >
                              >
                              >
                            • Roy Morien
                              If you try to go back and re-estimate retrospectively (if that is not a contradiction in terms), what are you trying to achieve, and what do you achieve? To
                              Message 14 of 19 , Aug 10, 2010
                              • 0 Attachment
                                If you try to go back and re-estimate retrospectively (if that is not a contradiction in terms), what are you trying to achieve, and what do you achieve?
                                 
                                To change the number of story points after the event for one User Story might change the apparent velocity of the team by a small fraction, because the contribution of the delta in story points to velocity is very very small. So it is pointless anyway.
                                 
                                If your intention is to measure a more 'accurate' velocity, then this is not worth doing. Velocity will converge on a reasonably valid predictive number over time (meaning, over more sprints).
                                 
                                If your intention is to make your points 'score' look good, then that is not very useful. Story points achieved is not some competitive value that can be used to determine the competence and efficiency of the team. If you want to do this, take my suggestion of upping your points scale to 4-8-16-32 .... this can really make you look good. But, be careful of 32! :)
                                 
                                Regards,
                                Roy Morien
                                 



                                To: scrumdevelopment@yahoogroups.com
                                From: dave.barrett@...
                                Date: Tue, 10 Aug 2010 09:33:18 -0400
                                Subject: [scrumdevelopment] Re:Discussion Point

                                 

                                Wow! This seems massively misguided to me.

                                The Team's velocity is the Team's velocity. It's not something that
                                incentives should be based on and they should never be scrambling to pick
                                up "points" after the fact.

                                That being said, the velocity is simply a planning tool. So you want it to
                                be as accurate as possible. Do you retroactively bump up the story points
                                for a really bad estimate? Maybe, if doing so is going to lead to more
                                accurate planning.

                                Dave Barrett
                                Project Manager
                                Lawyers' Professional Indemnity Company (LAWPRO®)
                                3101 - 250 Yonge Street
                                Toronto, Ontario M5B 2L7
                                Tel: 416-598-5800
                                Fax: 416-599-8341

                                This e-mail may be privileged and/or confidential, and the sender does not
                                waive any related rights and obligations. Any distribution, use or copying
                                of this e-mail or the information it contains by other than an intended
                                recipient is unauthorized. If you received this e-mail in error, please
                                delete it and advise me (by return e-mail or otherwise) immediately.

                                Ce courrier électronique est confidentiel et protégé. L'expéditeur ne
                                renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion,
                                utilisation ou copie de ce message ou des renseignements qu'il contient par
                                une personne autre que le (les) destinataire(s) désigné(s) est interdite.
                                Si vous recevez ce courrier électronique par erreur, veuillez le supprimer
                                et m'en aviser immédiatement, par retour de courrier électronique ou par un
                                autre moyen.


                              • Malcolm Anderson
                                Dave I agree with you, the teams velocity, tends to be a teams velocity, use it for what it is, a high accuracy, low precision planning tool. Because of that I
                                Message 15 of 19 , Aug 11, 2010
                                • 0 Attachment
                                  Dave

                                  I agree with you, the teams velocity, tends to be a teams velocity, use it for what it is, a high accuracy, low precision planning tool.

                                  Because of that I would be careful about the phrase "as accurate as possible."  I've seen it lead to seriously inappropriate attempts at precision.

                                  Precision is expensive and often a waste of time, energy and money.

                                  If I ask you how warm it is outside, all I want to know is do I need a coat, or sunscreen. 

                                  "Hot", "Warm", "Cool", or "Coooolllld" is all the precision I need (or can really use).

                                  I do not need to know if it's 73.8672199 degrees Fahrenheit out there.  Even if it really is 73.8672199 degrees out there at the time I ask the question, it will probably be a different number by the time I get out there.

                                  Most attempts at estimation that I've seen, seem to operate under the following assumption
                                  "If I can get a very precise set of estimation tools, then I can stop the weather from changing."

                                  Malcolm Anderson CSP





                                  On Tue, Aug 10, 2010 at 8:33 AM, <dave.barrett@...> wrote:
                                   


                                  Wow! This seems massively misguided to me.

                                  The Team's velocity is the Team's velocity. It's not something that
                                  incentives should be based on and they should never be scrambling to pick
                                  up "points" after the fact.

                                  That being said, the velocity is simply a planning tool. So you want it to
                                  be as accurate as possible. Do you retroactively bump up the story points
                                  for a really bad estimate? Maybe, if doing so is going to lead to more
                                  accurate planning.

                                  Dave Barrett


                                • petriheiramo
                                  Thanks Lance, ... I needed my daily fix of laughter. Thanks for delivering. Yours Sincerely, Petri
                                  Message 16 of 19 , Aug 11, 2010
                                  • 0 Attachment
                                    Thanks Lance,

                                    > For less experienced agile teams, I suggest going to a 2-4-8-16 scale first. That 32 can be a little hard to handle.

                                    I needed my daily fix of laughter. Thanks for delivering.


                                    Yours Sincerely, Petri

                                    > --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@> wrote:
                                    > >
                                    > >
                                    > > The best way to get extra credit for development points is to re-evaluate your point scoring method, and re-estimate your Product Backlog. Instead of using a 1-2-4-8 story points scale, use a 4-8-16-32 scale. That way your points score increases hugely, and your managers should be very pleased.
                                    > >
                                    > >
                                    > >
                                    > > Regards,
                                    > >
                                    > > Roy Morien
                                    > >
                                    > >
                                    > >
                                    >
                                  • Chris Poulton
                                    We have encountered similar issues throughout our Scrum implementation. The way we ve chosen to accommodate these issues is: 1) Planning I meeting - team
                                    Message 17 of 19 , Aug 11, 2010
                                    • 0 Attachment

                                      We have encountered similar issues throughout our Scrum implementation.  The way we’ve chosen to accommodate these issues is:

                                       

                                      1)      Planning I meeting – team and PO agree on PBIs (work commitment) and Goal for Sprint.  Planning II meeting – team breaks PBI work into individual tasks (SBIs) with hours estimates for each.  The team uses Planning Poker to estimate story point size of PBIs.  If after Planning Meeting II the team discovers the amount of real work to implement a story outweighs the allotted story points then we call the PO into the meeting to discuss options.  Options are – 1) do nothing, leave the story points/work as estimated.  2) adjust story points up/down to be more in-line with past PBI sizing.  3) alter (usually reduce) the scope of the PBI to be more commensurate with the estimated size of the PBI.

                                      2)      No concept of bonus points in Scrum.  If the team encounters work during the course of the Sprint we’ll discuss with the PO.  At a minimum it is recorded as a PBI for future attention.  In some instances it is a defect and can be logged as a production “bug” for future attention.  If it is refactoring work the team decides whether or not to accept the additional work with the committed items already in place for the Sprint.  …or create a technical debt PBI for future attention.

                                       

                                      Regarding item 1 above – in our two and a half year journey with Scrum we’ve change story points two times.   Usually this is because the estimating work was done several Sprints back and/or new awareness of issues during the actual work to breakdown the PBI into discrete tasks uncovers unexpected work.

                                       

                                      Our approach.  …your mileage may vary.

                                       

                                      Chris

                                       

                                      From: Paul Battisson [mailto:paulbattisson@...]
                                      Sent: Monday, August 09, 2010 8:16 AM
                                      To: scrumdevelopment@yahoogroups.com
                                      Subject: [scrumdevelopment] Discussion Point

                                       

                                       

                                      Hey everyone,

                                       

                                      At my organisation, a discussion has recently broken out that I would like some opinion/clarification on. At the end of a sprint, it is well understood that you can only claim points for completed stories, but from my understanding the following two things are not correct:

                                       

                                      1) If the team has a 5 point story and it is felt that they spent closer to 8 points of effort on it, we can change the claimed number of points to 8 once the story is complete (again provided it is in the same sprint).

                                      2) If a team completes a bonus activity or story in a sprint, (for example in refactoring some work we manage to allow our self to extend the functionality of the product easily and cheaply as we had asked for in a future story) we can claim those bonus points for this sprint. (Apologies for the example here, it is a bit naive but only meant to be illustrative).

                                       

                                      I was led to believe in my agile training and readings that both those points were incorrect,. Am I correct or is it down to interpretation?

                                       

                                      Thanks

                                       

                                      Paul

                                       

                                       

                                    • Morten Jespersen
                                      Hi all, It seems to me that the most important thing is being able to use the the storypoints and velocity as planning/prediction tools. Thus scoring extra
                                      Message 18 of 19 , Aug 11, 2010
                                      • 0 Attachment
                                        Hi all,

                                        It seems to me that the most important thing is being able to use the the storypoints and velocity as planning/prediction tools. Thus "scoring" extra story points in a sprint is by no means a desirable thing. It is (almost) as bad, as not reaching your sprint commitment, as it screws up the predictability just as much.

                                        Thus, I think that using "score" as a term for the amassed storypoints in a sprint is unfitting and counterproductive for what we are trying to acheive.

                                        If you absolutely crave some kind of score, maybe you could try to calculate the "off-target percentage" - meaning how much you miss your commitment by at each sprint. Given a sprint commitment of 100 Sp, both 90 and 110 sp would score 10%. A score of 0% is, of course, the bullseye we aim for.

                                        We'll hit the bullseye more and more frequently as we improve our process and planning skills... unless some annoying manager starts to fiddle with the darts or begins to shake the dart board with the darts in mid-flight.

                                        Regards,
                                        Morten


                                        --- In scrumdevelopment@yahoogroups.com, Paul Battisson <paulbattisson@...> wrote:
                                        >
                                        > Hey everyone,
                                        >
                                        > At my organisation, a discussion has recently broken out that I would like some
                                        > opinion/clarification on. At the end of a sprint, it is well understood that you
                                        > can only claim points for completed stories, but from my understanding the
                                        > following two things are not correct:
                                        >
                                        > 1) If the team has a 5 point story and it is felt that they spent closer to 8
                                        > points of effort on it, we can change the claimed number of points to 8 once the
                                        > story is complete (again provided it is in the same sprint).
                                        > 2) If a team completes a bonus activity or story in a sprint, (for example in
                                        > refactoring some work we manage to allow our self to extend the functionality of
                                        > the product easily and cheaply as we had asked for in a future story) we can
                                        > claim those bonus points for this sprint. (Apologies for the example here, it is
                                        > a bit naive but only meant to be illustrative).
                                        >
                                        > I was led to believe in my agile training and readings that both those points
                                        > were incorrect,. Am I correct or is it down to interpretation?
                                        >
                                        > Thanks
                                        >
                                        > Paul
                                        >
                                      • rasmus4200
                                        Hi Paul, It s natural when your first start out with agile to get excited about whether something is 5pts or 8pts. To claim extra story points or not. At the
                                        Message 19 of 19 , Aug 11, 2010
                                        • 0 Attachment
                                          Hi Paul,

                                          It's natural when your first start out with agile to get excited about whether something is 5pts or 8pts. To claim extra story points or not.

                                          At the end of the day it doesn't really matter.

                                          For every story point you claim 5pts when it was really worth 8pts, there will be an 8pt story that was really worth 5pts. So don't get too excited about that. It all comes out in the wash.

                                          Instead put yourself in your customers shoes.
                                          What do they really care about?

                                          Is it be whether you got 5 or 8 pts for a story?

                                          Or whether you shipped working software they could potentially put into production with the next release.

                                          Good luck - JR

                                          Twitter: @jrasmusson
                                          http://agilewarrior.wordpress.com
                                          The Agile Samurai - http://bit.ly/9wlCdz

                                          --- In scrumdevelopment@yahoogroups.com, Paul Battisson <paulbattisson@...> wrote:
                                          >
                                          > Hey everyone,
                                          >
                                          > At my organisation, a discussion has recently broken out that I would like some
                                          > opinion/clarification on. At the end of a sprint, it is well understood that you
                                          > can only claim points for completed stories, but from my understanding the
                                          > following two things are not correct:
                                          >
                                          > 1) If the team has a 5 point story and it is felt that they spent closer to 8
                                          > points of effort on it, we can change the claimed number of points to 8 once the
                                          > story is complete (again provided it is in the same sprint).
                                          > 2) If a team completes a bonus activity or story in a sprint, (for example in
                                          > refactoring some work we manage to allow our self to extend the functionality of
                                          > the product easily and cheaply as we had asked for in a future story) we can
                                          > claim those bonus points for this sprint. (Apologies for the example here, it is
                                          > a bit naive but only meant to be illustrative).
                                          >
                                          > I was led to believe in my agile training and readings that both those points
                                          > were incorrect,. Am I correct or is it down to interpretation?
                                          >
                                          > Thanks
                                          >
                                          > Paul
                                          >
                                        Your message has been successfully submitted and would be delivered to recipients shortly.