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

Stable Velocity?

Expand Messages
  • Ashish Mahajan
    http://ashish-the-agile-guy.com/2011/11/28/stable-velocity/
    Message 1 of 23 , Nov 27, 2011
    View Source
    • 0 Attachment
    • woynam
      We typically use a 3 month rolling average when calculating velocity. Given that a team gets zero points for a story that isn t finished at the end of Sprint,
      Message 2 of 23 , Nov 28, 2011
      View Source
      • 0 Attachment
        We typically use a 3 month rolling average when calculating velocity. Given that a team gets zero points for a story that isn't finished at the end of Sprint, it's not uncommon for the following Sprint to show a small increase in velocity, as the stories rolled over are credited to it.

        Averaging the velocity smooths out the bumps, and also help reduce the likelihood that someone would try to "game" the system, e.g. call a story done when it's not really ready. I'd rather have the story done-done, even if it means spending an extra day on it at the beginning of the subsequent iteration.

        Mark


        --- In scrumdevelopment@yahoogroups.com, Ashish Mahajan <agileashish@...> wrote:
        >
        > http://ashish-the-agile-guy.com/2011/11/28/stable-velocity/
        >
      • mj4scrum@gmail.com
        Agree. We d see better implementations of Scrum, with more of the benefits, if everyone focused a lot more on *done* and a lot less on velocity. --mj Sent from
        Message 3 of 23 , Nov 28, 2011
        View Source
        • 0 Attachment
          Agree. We'd see better implementations of Scrum, with more of the benefits, if everyone focused a lot more on *done* and a lot less on velocity. 

          --mj

          Sent from a phone that often corrects words I tapped to words I may not have meant. 

          On Nov 28, 2011, at 8:37 AM, "woynam" <woyna@...> wrote:

           


          We typically use a 3 month rolling average when calculating velocity. Given that a team gets zero points for a story that isn't finished at the end of Sprint, it's not uncommon for the following Sprint to show a small increase in velocity, as the stories rolled over are credited to it.

          Averaging the velocity smooths out the bumps, and also help reduce the likelihood that someone would try to "game" the system, e.g. call a story done when it's not really ready. I'd rather have the story done-done, even if it means spending an extra day on it at the beginning of the subsequent iteration.

          Mark

          --- In scrumdevelopment@yahoogroups.com, Ashish Mahajan <agileashish@...> wrote:
          >
          > http://ashish-the-agile-guy.com/2011/11/28/stable-velocity/
          >

        • Sten
          I do have an issue with the average velocity concept. In my team (I m a Scrum Master for one team of 9 people not including myself and the PO) they insist on
          Message 4 of 23 , Nov 29, 2011
          View Source
          • 0 Attachment
            I do have an issue with the average velocity concept. In my team (I'm a Scrum Master for one team of 9 people not including myself and the PO) they insist on keeping the estimate on stories the almost complete in one sprint to get the "correct payoff" of the whole story even though completing it in the sprint they are in amounts to a 1 or a 2 and the original estimate was a 5 or an 8.

            I argue that the definition of velocity is COMPLETED features per sprint - not the value of several user stories completed over several sprints.

            I think the team is viewing me as tha bad guy trying to take away their "pay" wich they believe is the velocity.

            They do have other issues as well - some having the result of US not being completed at the end of the sprint - like silo-thinking "my tasks are done, so I'm done", planning the sprint to make sure there are tasks for everyone in the team. Finishing all that are finshed the last two or three days of the sprint, working on their own and so on.

            The PO is seems to be accepting the teams excuses for not completing the user stories.

            Most of my efforts to help them change their approach seems to be viewed as an attempt to tell them what to do and how to do it, rather than taken in as something to reflect on.

            When accepting average velocity I let them keep on fooling themselves by thinking not completing userstories has no real negative impact because we'll complete it next sprint anyway.

            Thoughts?


            --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
            >
            >
            > We typically use a 3 month rolling average when calculating velocity. Given that a team gets zero points for a story that isn't finished at the end of Sprint, it's not uncommon for the following Sprint to show a small increase in velocity, as the stories rolled over are credited to it.
            >
            > Averaging the velocity smooths out the bumps, and also help reduce the likelihood that someone would try to "game" the system, e.g. call a story done when it's not really ready. I'd rather have the story done-done, even if it means spending an extra day on it at the beginning of the subsequent iteration.
            >
            > Mark
            >
            >
            > --- In scrumdevelopment@yahoogroups.com, Ashish Mahajan <agileashish@> wrote:
            > >
            > > http://ashish-the-agile-guy.com/2011/11/28/stable-velocity/
            > >
            >
          • Wouter Lagerweij
            Perhaps you can ask them what they think velocity is used for. Sprints are the unit of planning for a Scrum project. Velocity is used to find out after which
            Message 5 of 23 , Nov 29, 2011
            View Source
            • 0 Attachment
              Perhaps you can ask them what they think velocity is used for.

              Sprints are the unit of planning for a Scrum project. Velocity is used to find out after which sprint we can expect a story to be done. If a story is not really done sprint, it has no value, so counting part of that story's points for that sprint is completely useless. In fact, doing so means you will be structurally over-estimating!

              I actually mentioned this same issue in a blog post on ways to make velocity a useless number. (semi-shameless blog plug:-)

              Wouter


              On Tue, Nov 29, 2011 at 12:52 PM, Sten <steoj@...> wrote:
               

              I do have an issue with the average velocity concept. In my team (I'm a Scrum Master for one team of 9 people not including myself and the PO) they insist on keeping the estimate on stories the almost complete in one sprint to get the "correct payoff" of the whole story even though completing it in the sprint they are in amounts to a 1 or a 2 and the original estimate was a 5 or an 8.

              I argue that the definition of velocity is COMPLETED features per sprint - not the value of several user stories completed over several sprints.

              I think the team is viewing me as tha bad guy trying to take away their "pay" wich they believe is the velocity.

              They do have other issues as well - some having the result of US not being completed at the end of the sprint - like silo-thinking "my tasks are done, so I'm done", planning the sprint to make sure there are tasks for everyone in the team. Finishing all that are finshed the last two or three days of the sprint, working on their own and so on.

              The PO is seems to be accepting the teams excuses for not completing the user stories.

              Most of my efforts to help them change their approach seems to be viewed as an attempt to tell them what to do and how to do it, rather than taken in as something to reflect on.

              When accepting average velocity I let them keep on fooling themselves by thinking not completing userstories has no real negative impact because we'll complete it next sprint anyway.

              Thoughts?



              --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
              >
              >
              > We typically use a 3 month rolling average when calculating velocity. Given that a team gets zero points for a story that isn't finished at the end of Sprint, it's not uncommon for the following Sprint to show a small increase in velocity, as the stories rolled over are credited to it.
              >
              > Averaging the velocity smooths out the bumps, and also help reduce the likelihood that someone would try to "game" the system, e.g. call a story done when it's not really ready. I'd rather have the story done-done, even if it means spending an extra day on it at the beginning of the subsequent iteration.
              >
              > Mark
              >
              >
              > --- In scrumdevelopment@yahoogroups.com, Ashish Mahajan <agileashish@> wrote:
              > >
              > > http://ashish-the-agile-guy.com/2011/11/28/stable-velocity/
              > >
              >




              --
              Wouter Lagerweij         | wouter@...
            • jamesjhawkins
              ... Obliquely, I have had the same issue but as PO. It s depressing to feel that you re the only one that cares about quality. It seems to me that this
              Message 6 of 23 , Nov 29, 2011
              View Source
              • 0 Attachment
                --- In scrumdevelopment@yahoogroups.com, "Sten" <steoj@...> wrote:
                > I think the team is viewing me as tha bad guy trying to take away their "pay" wich they believe is the velocity.

                Obliquely, I have had the same issue but as PO. It's depressing to feel that you're the only one that cares about quality.

                It seems to me that this problem can occur in any team in which only one person is prepared to "wear the black hat", as Edward De Bono calls it.

                Sorry, I don't have a solution to offer.

                .Jim
              • RonJeffries
                Hi ... What are you people doing about your Definition of DONE? R ... Ron Jeffries www.XProgramming.com If another does not intend offense, it is wrong for me
                Message 7 of 23 , Nov 29, 2011
                View Source
                • 0 Attachment
                  Hi ...

                  What are you people doing about your Definition of DONE?

                  R
                  On Nov 29, 2011, at 11:21 AM, jamesjhawkins wrote:

                  --- In scrumdevelopment@yahoogroups.com, "Sten" <steoj@...> wrote:
                  I think the team is viewing me as tha bad guy trying to take away their "pay" wich they believe is the velocity.

                  Obliquely, I have had the same issue but as PO.  It's depressing to feel that you're the only one that cares about quality.

                  It seems to me that this problem can occur in any team in which only one person is prepared to "wear the black hat", as Edward De Bono calls it.

                  Sorry, I don't have a solution to offer.


                  Ron Jeffries
                  If another does not intend offense, it is wrong for me to seek it;
                  if another does indeed intend offense, it is foolish for me to permit it.
                    -- Kelly Easterley

                • David A Barrett
                  What do you do with this stable velocity ?? I find the the value of these kinds of numbers become counter-productive once you pretend that they have accuracy
                  Message 8 of 23 , Nov 29, 2011
                  View Source
                  • 0 Attachment
                    What do you do with this "stable velocity"??

                    I find the the value of these kinds of numbers become counter-productive once you pretend that they have accuracy better than, say, binary order of magnitude.  I'd say that it's worthwhile knowing if you can do 16 or 32 story points in a Sprint, but not worthwhile knowing if you can do 16 or 18 story points in a Sprint.  In the second case, just call it "16" and get on with the coding.

                    I have a sneaking suspicion that people are using these velocity numbers to do long range planning.  "Oh yes, we have 273 story points of features to complete for our next release 9 months from now, and velocity of 15.8 story points per Sprint equals guaranteed success that we can report to the board next week".  Yikes!

                    In a real Scrum world, those 273 story points are evolving.  30 points may evaporate in a month or two as the PO decides that the features aren't really needed, in light of how other features turned out.  50 other story points turned out to be 100, once it was discovered that the toolset the team was counting on doesn't work nicely with some other essential technical element.  Finally, the sales guys came back from their cross country prospecting trip and added 73 more story points of stuff nobody had thought of before, but are essential for good buy in from the customer base.

                    Thank God you've at least got stable velocity accurate to 3 decimal places, or else the whole plan would go down the toilet within 2 Sprints.  At least until one of the programmers has to take a month off to go look after his sick grandmother, and one of the testers starts going through an ugly divorce.



                    Dave Barrett

                    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.
                  • Pavel
                    ... [PVG] Velocity is used for release planning. But it is not used to sign a contract that yes, we will deliver these feature worth of 273 story points in 9
                    Message 9 of 23 , Nov 29, 2011
                    View Source
                    • 0 Attachment
                      --- In scrumdevelopment@yahoogroups.com, David A Barrett <dave.barrett@...> wrote:
                      >
                      > What do you do with this "stable velocity"??
                      >
                      > I find the the value of these kinds of numbers become counter-productive
                      > once you pretend that they have accuracy better than, say, binary order of
                      > magnitude. I'd say that it's worthwhile knowing if you can do 16 or 32
                      > story points in a Sprint, but not worthwhile knowing if you can do 16 or
                      > 18 story points in a Sprint. In the second case, just call it "16" and
                      > get on with the coding.
                      >
                      > I have a sneaking suspicion that people are using these velocity numbers
                      > to do long range planning.

                      [PVG] Velocity is used for release planning. But it is not used to sign a contract that "yes, we will deliver these feature worth of 273 story points in 9 months". It is just a rough, agile planning to give you a sense of where you are.

                      "Oh yes, we have 273 story points of features
                      > to complete for our next release 9 months from now, and velocity of 15.8
                      > story points per Sprint equals guaranteed success that we can report to
                      > the board next week". Yikes!
                      >
                      > In a real Scrum world, those 273 story points are evolving.

                      [PVG] Yes they are. That's why you re-estimate the backlog once in a while because as you go you learn more and your estimates become more accurate.

                      30 points may
                      > evaporate in a month or two as the PO decides that the features aren't
                      > really needed, in light of how other features turned out. 50 other story
                      > points turned out to be 100, once it was discovered that the toolset the
                      > team was counting on doesn't work nicely with some other essential
                      > technical element.

                      [PVG] Risk Management should be part of your Release Planning. So you should know this pretty early in the release. You re-estimate and now you have 350 SP instead of 273. Based on your velocity you can take a good guess that you will not finish all these stories in the release time frame and something needs to be changed (you add resources, cut the scope of some of the feature or even take whole features out of the release.

                      Finally, the sales guys came back from their cross
                      > country prospecting trip and added 73 more story points of stuff nobody
                      > had thought of before, but are essential for good buy in from the customer
                      > base.
                      >
                      > Thank God you've at least got stable velocity accurate to 3 decimal
                      > places, or else the whole plan would go down the toilet within 2 Sprints.
                      > At least until one of the programmers has to take a month off to go look
                      > after his sick grandmother, and one of the testers starts going through an
                      > ugly divorce.

                      [PVG] Risk Management again....
                      >
                      >
                      >
                      > Dave Barrett
                      >
                      > 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.
                      >
                    • Charles Bradley - Scrum Coach CSM PSM I
                      Sten, ... Scrum Master for one team of 9 people not including myself and the PO) they insist on keeping the estimate on stories the almost complete in one
                      Message 10 of 23 , Nov 29, 2011
                      View Source
                      • 0 Attachment
                        Sten,

                        > I do have an issue with the average velocity concept. In my team (I'm a Scrum Master for one team of 9 people not including myself and the PO) they insist on keeping the estimate on stories the almost complete in one sprint to get the "correct payoff" of the whole story even though completing it in the sprint they are in amounts to a 1 or a 2 and the original estimate was a 5 or an 8.

                        I had a heckuva time following what you're saying here... are you saying that the team carries stories over and finishes them early in the next sprint? What's so wrong with this?  A concrete example would help -- hard for me to tell whether you're doing the correct thing or not.

                         
                        -------
                        Charles Bradley, CSM, PSM I
                        Experienced Scrum Coach
                        My blog: http://scrumcrazy.wordpress.com/

                        From: Sten <steoj@...>
                        To: scrumdevelopment@yahoogroups.com
                        Sent: Tuesday, November 29, 2011 4:52 AM
                        Subject: [scrumdevelopment] Re: Stable Velocity?

                        I do have an issue with the average velocity concept. In my team (I'm a Scrum Master for one team of 9 people not including myself and the PO) they insist on keeping the estimate on stories the almost complete in one sprint to get the "correct payoff" of the whole story even though completing it in the sprint they are in amounts to a 1 or a 2 and the original estimate was a 5 or an 8.

                        I argue that the definition of velocity is COMPLETED features per sprint - not the value of several user stories completed over several sprints.

                        I think the team is viewing me as tha bad guy trying to take away their "pay" wich they believe is the velocity.

                        They do have other issues as well - some having the result of US not being completed at the end of the sprint - like silo-thinking "my tasks are done, so I'm done", planning the sprint to make sure there are tasks for everyone in the team. Finishing all that are finshed the last two or three days of the sprint, working on their own and so on.

                        The PO is seems to be accepting the teams excuses for not completing the user stories.

                        Most of my efforts to help them change their approach seems to be viewed as an attempt to tell them what to do and how to do it, rather than taken in as something to reflect on.

                        When accepting average velocity I let them keep on fooling themselves by thinking not completing userstories has no real negative impact because we'll complete it next sprint anyway.

                        Thoughts?


                        --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
                        >
                        >
                        > We typically use a 3 month rolling average when calculating velocity. Given that a team gets zero points for a story that isn't finished at the end of Sprint, it's not uncommon for the following Sprint to show a small increase in velocity, as the stories rolled over are credited to it.
                        >
                        > Averaging the velocity smooths out the bumps, and also help reduce the likelihood that someone would try to "game" the system, e.g. call a story done when it's not really ready. I'd rather have the story done-done, even if it means spending an extra day on it at the beginning of the subsequent iteration.
                        >
                        > Mark
                        >
                        >
                        > --- In scrumdevelopment@yahoogroups.com, Ashish Mahajan <agileashish@> wrote:
                        > >
                        > >  http://ashish-the-agile-guy.com/2011/11/28/stable-velocity/
                        > >
                        >




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

                        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/



                      • brendabao321
                        Velocity is not meant to be accurate. It s accuracy is only from statistical point of view. I think it s better use the number as a source of retrospective,
                        Message 11 of 23 , Nov 29, 2011
                        View Source
                        • 0 Attachment
                          Velocity is not meant to be accurate. It's accuracy is only from statistical point of view. I think it's better use the number as a source of retrospective, and a reference for doing better planning.

                          --- In scrumdevelopment@yahoogroups.com, David A Barrett <dave.barrett@...> wrote:
                          >
                          > What do you do with this "stable velocity"??
                          >
                          > I find the the value of these kinds of numbers become counter-productive
                          > once you pretend that they have accuracy better than, say, binary order of
                          > magnitude. I'd say that it's worthwhile knowing if you can do 16 or 32
                          > story points in a Sprint, but not worthwhile knowing if you can do 16 or
                          > 18 story points in a Sprint. In the second case, just call it "16" and
                          > get on with the coding.
                          >
                          > I have a sneaking suspicion that people are using these velocity numbers
                          > to do long range planning. "Oh yes, we have 273 story points of features
                          > to complete for our next release 9 months from now, and velocity of 15.8
                          > story points per Sprint equals guaranteed success that we can report to
                          > the board next week". Yikes!
                          >
                          > In a real Scrum world, those 273 story points are evolving. 30 points may
                          > evaporate in a month or two as the PO decides that the features aren't
                          > really needed, in light of how other features turned out. 50 other story
                          > points turned out to be 100, once it was discovered that the toolset the
                          > team was counting on doesn't work nicely with some other essential
                          > technical element. Finally, the sales guys came back from their cross
                          > country prospecting trip and added 73 more story points of stuff nobody
                          > had thought of before, but are essential for good buy in from the customer
                          > base.
                          >
                          > Thank God you've at least got stable velocity accurate to 3 decimal
                          > places, or else the whole plan would go down the toilet within 2 Sprints.
                          > At least until one of the programmers has to take a month off to go look
                          > after his sick grandmother, and one of the testers starts going through an
                          > ugly divorce.
                          >
                          >
                          >
                          > Dave Barrett
                          >
                          > 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.
                          >
                        • Michael James
                          While it can provide some benefits, in the hands of Tayloristic/PMP managers the velocity concept has done more harm than good in practice -- like the Sprint
                          Message 12 of 23 , Nov 29, 2011
                          View Source
                          • 0 Attachment
                            While it can provide some benefits, in the hands of Tayloristic/PMP managers the velocity concept has done more harm than good in practice -- like the Sprint burndown chart.  I'm reluctant to even teach these things because of how I've seen them abused. 

                            --mj


                            On Nov 29, 2011, at 9:18 PM, "brendabao321" <central_boat@...> wrote:

                             

                            Velocity is not meant to be accurate. It's accuracy is only from statistical point of view. I think it's better use the number as a source of retrospective, and a reference for doing better planning.

                            --- In scrumdevelopment@yahoogroups.com, David A Barrett <dave.barrett@...> wrote:
                            >
                            > What do you do with this "stable velocity"??
                            >
                            > I find the the value of these kinds of numbers become counter-productive
                            > once you pretend that they have accuracy better than, say, binary order of
                            > magnitude. I'd say that it's worthwhile knowing if you can do 16 or 32
                            > story points in a Sprint, but not worthwhile knowing if you can do 16 or
                            > 18 story points in a Sprint. In the second case, just call it "16" and
                            > get on with the coding.
                            >
                            > I have a sneaking suspicion that people are using these velocity numbers
                            > to do long range planning. "Oh yes, we have 273 story points of features
                            > to complete for our next release 9 months from now, and velocity of 15.8
                            > story points per Sprint equals guaranteed success that we can report to
                            > the board next week". Yikes!
                            >
                            > In a real Scrum world, those 273 story points are evolving. 30 points may
                            > evaporate in a month or two as the PO decides that the features aren't
                            > really needed, in light of how other features turned out. 50 other story
                            > points turned out to be 100, once it was discovered that the toolset the
                            > team was counting on doesn't work nicely with some other essential
                            > technical element. Finally, the sales guys came back from their cross
                            > country prospecting trip and added 73 more story points of stuff nobody
                            > had thought of before, but are essential for good buy in from the customer
                            > base.
                            >
                            > Thank God you've at least got stable velocity accurate to 3 decimal
                            > places, or else the whole plan would go down the toilet within 2 Sprints.
                            > At least until one of the programmers has to take a month off to go look
                            > after his sick grandmother, and one of the testers starts going through an
                            > ugly divorce.
                            >
                            >
                            >
                            > Dave Barrett
                            >
                            > 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.
                            >

                          • mcleaper
                            Charles, I believe what Sten is saying is that the team has a story of 13 points and does not complete the story during the sprint but guesses that they have
                            Message 13 of 23 , Nov 29, 2011
                            View Source
                            • 0 Attachment
                              Charles,

                              I believe what Sten is saying is that the team has a story of 13 points and does not complete the story during the sprint but "guesses" that they have finished enough of the story to get "credit" for 7 points.

                              I assume the team finishes the story in the next sprint and receives the remaining 6 points in that sprint.

                              My team uses the all or nothing view when it comes to story points completed during a sprint. If the Done criteria is not completed for a story the team get 0 points in that sprint for the story.

                              I think either method works over the long run but I believe it is easier and wastes less time to use the all or nothing approach.

                              Regards,
                              Mike



                              --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
                              >
                              > Sten,
                              >
                              > > I do have an issue with the average velocity concept. In my team (I'm a
                              > Scrum Master for one team of 9 people not including myself and the PO)
                              > they insist on keeping the estimate on stories the almost complete in
                              > one sprint to get the "correct payoff" of the whole story even though
                              > completing it in the sprint they are in amounts to a 1 or a 2 and the
                              > original estimate was a 5 or an 8.
                              >
                              > I had a heckuva time following what you're saying here... are you saying that the team carries stories over and finishes them early in the next sprint? What's so wrong with this?  A concrete example would help -- hard for me to tell whether you're doing the correct thing or not.
                              >
                              >  
                              > -------
                              > Charles Bradley, CSM, PSM I
                              > Experienced Scrum Coach
                              > My blog: http://scrumcrazy.wordpress.com/
                              >
                              >
                              > >________________________________
                              > > From: Sten <steoj@...>
                              > >To: scrumdevelopment@yahoogroups.com
                              > >Sent: Tuesday, November 29, 2011 4:52 AM
                              > >Subject: [scrumdevelopment] Re: Stable Velocity?
                              > >
                              > >I do have an issue with the average velocity concept. In my team (I'm a Scrum Master for one team of 9 people not including myself and the PO) they insist on keeping the estimate on stories the almost complete in one sprint to get the "correct payoff" of the whole story even though completing it in the sprint they are in amounts to a 1 or a 2 and the original estimate was a 5 or an 8.
                              > >
                              > >I argue that the definition of velocity is COMPLETED features per sprint - not the value of several user stories completed over several sprints.
                              > >
                              > >I think the team is viewing me as tha bad guy trying to take away their "pay" wich they believe is the velocity.
                              > >
                              > >They do have other issues as well - some having the result of US not being completed at the end of the sprint - like silo-thinking "my tasks are done, so I'm done", planning the sprint to make sure there are tasks for everyone in the team. Finishing all that are finshed the last two or three days of the sprint, working on their own and so on.
                              > >
                              > >The PO is seems to be accepting the teams excuses for not completing the user stories.
                              > >
                              > >Most of my efforts to help them change their approach seems to be viewed as an attempt to tell them what to do and how to do it, rather than taken in as something to reflect on.
                              > >
                              > >When accepting average velocity I let them keep on fooling themselves by thinking not completing userstories has no real negative impact because we'll complete it next sprint anyway.
                              > >
                              > >Thoughts?
                              > >
                              > >
                              > >--- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
                              > >>
                              > >>
                              > >> We typically use a 3 month rolling average when calculating velocity. Given that a team gets zero points for a story that isn't finished at the end of Sprint, it's not uncommon for the following Sprint to show a small increase in velocity, as the stories rolled over are credited to it.
                              > >>
                              > >> Averaging the velocity smooths out the bumps, and also help reduce the likelihood that someone would try to "game" the system, e.g. call a story done when it's not really ready. I'd rather have the story done-done, even if it means spending an extra day on it at the beginning of the subsequent iteration.
                              > >>
                              > >> Mark
                              > >>
                              > >>
                              > >> --- In scrumdevelopment@yahoogroups.com, Ashish Mahajan <agileashish@> wrote:
                              > >> >
                              > >> >  http://ashish-the-agile-guy.com/2011/11/28/stable-velocity/
                              > >> >
                              > >>
                              > >
                              > >
                              > >
                              > >
                              > >------------------------------------
                              > >
                              > >To Post a message, send it to:  scrumdevelopment@...
                              > >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                              > >
                              > >
                              > >
                              > >
                              > >
                              > >
                              >
                            • chrischany
                              Is the goal to deliver story points or high value quality software?
                              Message 14 of 23 , Nov 30, 2011
                              View Source
                              • 0 Attachment
                                Is the goal to deliver story points or high value quality software?
                              • Sten
                                Delivering value to the business is always a good thing - even if it happens at the beginning of the next sprint. I think we totally agree there. What happens
                                Message 15 of 23 , Nov 30, 2011
                                View Source
                                • 0 Attachment
                                  Delivering value to the business is always a good thing - even if it happens at the beginning of the next sprint. I think we totally agree there.
                                  What happens in my team is that they take on a user story during sprint planning. So far everything is good.
                                  Then sprint is started, and so is the implementation of the user story - mostly by one team member with a few tasks at the end for the QA. Actually most of the user stories are in progress from the beginning of the sprint and usually worked on by one person, that hands it over to the QA person within the team for completion. QA's have a lot of work to do at the end of the sprint - if the user story is completed in time.
                                  If not, the story is bled over to the next sprint - because the PO still thinks it is important - and believes the team when they say it's just a few hours left of it even if it is a Medium user story originally.
                                  Then they continue with the user story in the next sprint and starts another when they have done "their" part of it. If they finish "their" user story before the sprint end, they agree with the product owner to pick another high priority one from the Product backlog that fits their competence. That is not a bad thing, but they seem not to care if they can finish it within the sprint or if the team in total is done with all other user stories they have committed in the sprint.

                                  To me it is obvious that they think it is far more efficient to work on something they know, rather than help someone with something the know less about. Keeping the estimates of userstories that bleeds over from one sprint ot another I do not think is helping them see how important it is for them to work together - as a team.

                                  Hope this sheds some more light on what I am trying to describe.

                                  /Sten

                                  --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
                                  >
                                  > Sten,
                                  >
                                  > > I do have an issue with the average velocity concept. In my team (I'm a
                                  > Scrum Master for one team of 9 people not including myself and the PO)
                                  > they insist on keeping the estimate on stories the almost complete in
                                  > one sprint to get the "correct payoff" of the whole story even though
                                  > completing it in the sprint they are in amounts to a 1 or a 2 and the
                                  > original estimate was a 5 or an 8.
                                  >
                                  > I had a heckuva time following what you're saying here... are you saying that the team carries stories over and finishes them early in the next sprint? What's so wrong with this?  A concrete example would help -- hard for me to tell whether you're doing the correct thing or not.
                                  >
                                  >  
                                  > -------
                                  > Charles Bradley, CSM, PSM I
                                  > Experienced Scrum Coach
                                  > My blog: http://scrumcrazy.wordpress.com/
                                  >
                                  >
                                  > >________________________________
                                  > > From: Sten <steoj@...>
                                  > >To: scrumdevelopment@yahoogroups.com
                                  > >Sent: Tuesday, November 29, 2011 4:52 AM
                                  > >Subject: [scrumdevelopment] Re: Stable Velocity?
                                  > >
                                  > >I do have an issue with the average velocity concept. In my team (I'm a Scrum Master for one team of 9 people not including myself and the PO) they insist on keeping the estimate on stories the almost complete in one sprint to get the "correct payoff" of the whole story even though completing it in the sprint they are in amounts to a 1 or a 2 and the original estimate was a 5 or an 8.
                                  > >
                                  > >I argue that the definition of velocity is COMPLETED features per sprint - not the value of several user stories completed over several sprints.
                                  > >
                                  > >I think the team is viewing me as tha bad guy trying to take away their "pay" wich they believe is the velocity.
                                  > >
                                  > >They do have other issues as well - some having the result of US not being completed at the end of the sprint - like silo-thinking "my tasks are done, so I'm done", planning the sprint to make sure there are tasks for everyone in the team. Finishing all that are finshed the last two or three days of the sprint, working on their own and so on.
                                  > >
                                  > >The PO is seems to be accepting the teams excuses for not completing the user stories.
                                  > >
                                  > >Most of my efforts to help them change their approach seems to be viewed as an attempt to tell them what to do and how to do it, rather than taken in as something to reflect on.
                                  > >
                                  > >When accepting average velocity I let them keep on fooling themselves by thinking not completing userstories has no real negative impact because we'll complete it next sprint anyway.
                                  > >
                                  > >Thoughts?
                                  > >
                                  > >
                                  > >--- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
                                  > >>
                                  > >>
                                  > >> We typically use a 3 month rolling average when calculating velocity. Given that a team gets zero points for a story that isn't finished at the end of Sprint, it's not uncommon for the following Sprint to show a small increase in velocity, as the stories rolled over are credited to it.
                                  > >>
                                  > >> Averaging the velocity smooths out the bumps, and also help reduce the likelihood that someone would try to "game" the system, e.g. call a story done when it's not really ready. I'd rather have the story done-done, even if it means spending an extra day on it at the beginning of the subsequent iteration.
                                  > >>
                                  > >> Mark
                                  > >>
                                  > >>
                                  > >> --- In scrumdevelopment@yahoogroups.com, Ashish Mahajan <agileashish@> wrote:
                                  > >> >
                                  > >> >  http://ashish-the-agile-guy.com/2011/11/28/stable-velocity/
                                  > >> >
                                  > >>
                                  > >
                                  > >
                                  > >
                                  > >
                                  > >------------------------------------
                                  > >
                                  > >To Post a message, send it to:  scrumdevelopment@...
                                  > >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                                  > >
                                  > >
                                  > >
                                  > >
                                  > >
                                  > >
                                  >
                                • RonJeffries
                                  Hi Sten, ... Yes. I believe that continuous flow, as it is called, is probably more productive than Sprints / Iterations, but only in the hands of teams with
                                  Message 16 of 23 , Nov 30, 2011
                                  View Source
                                  • 0 Attachment
                                    Hi Sten,

                                    On Nov 30, 2011, at 9:32 AM, Sten wrote:

                                    To me it is obvious that they think it is far more efficient to work on something they know, rather than help someone with something the know less about. Keeping the estimates of userstories that bleeds over from one sprint ot another I do not think is helping them see how important it is for them to work together - as a team.

                                    Yes. I believe that continuous flow, as it is called, is probably more productive than Sprints / Iterations, but only in the hands of teams with great skill. 

                                    The value of the Sprint is in learning how to get things done in finite time. The timebox gives the team the ability to see the need for and impact of things like:
                                    • Continuous QA
                                    • TDD and ATDD
                                    • Improved cross-functionality
                                    • Helping each other

                                    Working on a very few stories until they are really done exposes concerns, teaches important lessons, and gives the business people better ability to project progress. The team you describe is probably missing out on at least some of the available learning, and is probably missing opportunities to improve their personal and team capability.

                                    Ron Jeffries
                                    I'm really pissed off by what people are passing off as "agile" these days.
                                    You may have a red car, but that does not make it a Ferrari.
                                      -- Steve Hayes

                                  • Wouter Lagerweij
                                    Hi Sten, One thing that might help you here is to make sure you have smaller stories. Learning how to split-up user stories can be difficult, but can carry a
                                    Message 17 of 23 , Nov 30, 2011
                                    View Source
                                    • 0 Attachment
                                      Hi Sten,

                                      One thing that might help you here is to make sure you have smaller stories. Learning how to split-up user stories can be difficult, but can carry a great reward. Smaller stories (that one or two people finish in two or three days) can make much clearer what needs to be done, and when you're finished. They also help in spreading testing work throughout the sprint, even if the tester is not pairing with a developer. And it suddenly isn't much of a problem if *one or two* stories are not finished at the end of the sprint: that will only be a small part of the work done in the sprint. 

                                      Smaller stories also make it easier for someone else to work in the same area of functionality, spreading knowledge throughout the team.

                                      Wouter

                                      On Wed, Nov 30, 2011 at 3:32 PM, Sten <steoj@...> wrote:
                                       

                                      Delivering value to the business is always a good thing - even if it happens at the beginning of the next sprint. I think we totally agree there.
                                      What happens in my team is that they take on a user story during sprint planning. So far everything is good.
                                      Then sprint is started, and so is the implementation of the user story - mostly by one team member with a few tasks at the end for the QA. Actually most of the user stories are in progress from the beginning of the sprint and usually worked on by one person, that hands it over to the QA person within the team for completion. QA's have a lot of work to do at the end of the sprint - if the user story is completed in time.
                                      If not, the story is bled over to the next sprint - because the PO still thinks it is important - and believes the team when they say it's just a few hours left of it even if it is a Medium user story originally.
                                      Then they continue with the user story in the next sprint and starts another when they have done "their" part of it. If they finish "their" user story before the sprint end, they agree with the product owner to pick another high priority one from the Product backlog that fits their competence. That is not a bad thing, but they seem not to care if they can finish it within the sprint or if the team in total is done with all other user stories they have committed in the sprint.

                                      To me it is obvious that they think it is far more efficient to work on something they know, rather than help someone with something the know less about. Keeping the estimates of userstories that bleeds over from one sprint ot another I do not think is helping them see how important it is for them to work together - as a team.

                                      Hope this sheds some more light on what I am trying to describe.

                                      /Sten



                                      --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
                                      >
                                      > Sten,
                                      >
                                      > > I do have an issue with the average velocity concept. In my team (I'm a
                                      > Scrum Master for one team of 9 people not including myself and the PO)
                                      > they insist on keeping the estimate on stories the almost complete in
                                      > one sprint to get the "correct payoff" of the whole story even though
                                      > completing it in the sprint they are in amounts to a 1 or a 2 and the
                                      > original estimate was a 5 or an 8.
                                      >
                                      > I had a heckuva time following what you're saying here... are you saying that the team carries stories over and finishes them early in the next sprint? What's so wrong with this?  A concrete example would help -- hard for me to tell whether you're doing the correct thing or not.
                                      >
                                      >  
                                      > -------
                                      > Charles Bradley, CSM, PSM I
                                      > Experienced Scrum Coach
                                      > My blog: http://scrumcrazy.wordpress.com/
                                      >
                                      >
                                      > >________________________________
                                      > > From: Sten <steoj@...>

                                      > >To: scrumdevelopment@yahoogroups.com
                                      > >Sent: Tuesday, November 29, 2011 4:52 AM
                                      > >Subject: [scrumdevelopment] Re: Stable Velocity?
                                      > >
                                      > >I do have an issue with the average velocity concept. In my team (I'm a Scrum Master for one team of 9 people not including myself and the PO) they insist on keeping the estimate on stories the almost complete in one sprint to get the "correct payoff" of the whole story even though completing it in the sprint they are in amounts to a 1 or a 2 and the original estimate was a 5 or an 8.
                                      > >
                                      > >I argue that the definition of velocity is COMPLETED features per sprint - not the value of several user stories completed over several sprints.
                                      > >
                                      > >I think the team is viewing me as tha bad guy trying to take away their "pay" wich they believe is the velocity.
                                      > >
                                      > >They do have other issues as well - some having the result of US not being completed at the end of the sprint - like silo-thinking "my tasks are done, so I'm done", planning the sprint to make sure there are tasks for everyone in the team. Finishing all that are finshed the last two or three days of the sprint, working on their own and so on.
                                      > >
                                      > >The PO is seems to be accepting the teams excuses for not completing the user stories.
                                      > >
                                      > >Most of my efforts to help them change their approach seems to be viewed as an attempt to tell them what to do and how to do it, rather than taken in as something to reflect on.
                                      > >
                                      > >When accepting average velocity I let them keep on fooling themselves by thinking not completing userstories has no real negative impact because we'll complete it next sprint anyway.
                                      > >
                                      > >Thoughts?
                                      > >
                                      > >
                                      > >--- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
                                      > >>
                                      > >>
                                      > >> We typically use a 3 month rolling average when calculating velocity. Given that a team gets zero points for a story that isn't finished at the end of Sprint, it's not uncommon for the following Sprint to show a small increase in velocity, as the stories rolled over are credited to it.
                                      > >>
                                      > >> Averaging the velocity smooths out the bumps, and also help reduce the likelihood that someone would try to "game" the system, e.g. call a story done when it's not really ready. I'd rather have the story done-done, even if it means spending an extra day on it at the beginning of the subsequent iteration.
                                      > >>
                                      > >> Mark
                                      > >>
                                      > >>
                                      > >> --- In scrumdevelopment@yahoogroups.com, Ashish Mahajan <agileashish@> wrote:
                                      > >> >
                                      > >> >  http://ashish-the-agile-guy.com/2011/11/28/stable-velocity/
                                      > >> >
                                      > >>
                                      > >
                                      > >
                                      > >
                                      > >
                                      > >------------------------------------
                                      > >
                                      > >To Post a message, send it to:  scrumdevelopment@...
                                      > >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                                      > >
                                      > >
                                      > >
                                      > >
                                      > >
                                      > >
                                      >




                                      --
                                      Wouter Lagerweij         | wouter@...
                                    • Charles Bradley - Scrum Coach CSM PSM I
                                      ... Is your team trying to take partial credit for stories as Mike suggests?   ... Charles Bradley, CSM, PSM I Experienced Scrum Coach My blog:
                                      Message 18 of 23 , Nov 30, 2011
                                      View Source
                                      • 0 Attachment
                                        Sten, you've given a lot more background which has highlighted some other risky practices... but I still don't understand what this means:

                                        > Keeping the estimates of userstories that bleeds over from one sprint ot another I do not think is helping them

                                        Is your team trying to take partial credit for stories as Mike suggests?
                                         
                                        -------
                                        Charles Bradley, CSM, PSM I
                                        Experienced Scrum Coach
                                        My blog: http://scrumcrazy.wordpress.com/

                                        From: Sten <steoj@...>
                                        To: scrumdevelopment@yahoogroups.com
                                        Sent: Wednesday, November 30, 2011 7:32 AM
                                        Subject: [scrumdevelopment] Re: Stable Velocity?

                                        Delivering value to the business is always a good thing - even if it happens at the beginning of the next sprint. I think we totally agree there.
                                        What happens in my team is that they take on a user story during sprint planning. So far everything is good.
                                        Then sprint is started, and so is the implementation of the user story - mostly by one team member with a few tasks at the end for the QA. Actually most of the user stories are in progress from the beginning of the sprint and usually worked on by one person, that hands it over to the QA person within the team for completion. QA's have a lot of work to do at the end of the sprint - if the user story is completed in time.
                                        If not, the story is bled over to the next sprint - because the PO still thinks it is important - and believes the team when they say it's just a few hours left of it even if it is a Medium user story originally.
                                        Then they continue with the user story in the next sprint and starts another when they have done "their" part of it. If they finish "their" user story before the sprint end, they agree with the product owner to pick another high priority one from the Product backlog that fits their competence. That is not a bad thing, but they seem not to care if they can finish it within the sprint or if the team in total is done with all other user stories they have committed in the sprint.

                                        To me it is obvious that they think it is far more efficient to work on something they know, rather than help someone with something the know less about. Keeping the estimates of userstories that bleeds over from one sprint ot another I do not think is helping them see how important it is for them to work together - as a team.

                                        Hope this sheds some more light on what I am trying to describe.

                                        /Sten

                                        --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
                                        >
                                        > Sten,
                                        >
                                        > > I do have an issue with the average velocity concept. In my team (I'm a
                                        > Scrum Master for one team of 9 people not including myself and the PO)
                                        > they insist on keeping the estimate on stories the almost complete in
                                        > one sprint to get the "correct payoff" of the whole story even though
                                        > completing it in the sprint they are in amounts to a 1 or a 2 and the
                                        > original estimate was a 5 or an 8.
                                        >
                                        > I had a heckuva time following what you're saying here... are you saying that the team carries stories over and finishes them early in the next sprint? What's so wrong with this?  A concrete example would help -- hard for me to tell whether you're doing the correct thing or not.
                                        >
                                        >  
                                        > -------
                                        > Charles Bradley, CSM, PSM I
                                        > Experienced Scrum Coach
                                        > My blog: http://scrumcrazy.wordpress.com/
                                        >
                                        >
                                        > >________________________________
                                        > > From: Sten <steoj@...>
                                        > >To: scrumdevelopment@yahoogroups.com
                                        > >Sent: Tuesday, November 29, 2011 4:52 AM
                                        > >Subject: [scrumdevelopment] Re: Stable Velocity?
                                        > >
                                        > >I do have an issue with the average velocity concept. In my team (I'm a Scrum Master for one team of 9 people not including myself and the PO) they insist on keeping the estimate on stories the almost complete in one sprint to get the "correct payoff" of the whole story even though completing it in the sprint they are in amounts to a 1 or a 2 and the original estimate was a 5 or an 8.
                                        > >
                                        > >I argue that the definition of velocity is COMPLETED features per sprint - not the value of several user stories completed over several sprints.
                                        > >
                                        > >I think the team is viewing me as tha bad guy trying to take away their "pay" wich they believe is the velocity.
                                        > >
                                        > >They do have other issues as well - some having the result of US not being completed at the end of the sprint - like silo-thinking "my tasks are done, so I'm done", planning the sprint to make sure there are tasks for everyone in the team. Finishing all that are finshed the last two or three days of the sprint, working on their own and so on.
                                        > >
                                        > >The PO is seems to be accepting the teams excuses for not completing the user stories.
                                        > >
                                        > >Most of my efforts to help them change their approach seems to be viewed as an attempt to tell them what to do and how to do it, rather than taken in as something to reflect on.
                                        > >
                                        > >When accepting average velocity I let them keep on fooling themselves by thinking not completing userstories has no real negative impact because we'll complete it next sprint anyway.
                                        > >
                                        > >Thoughts?
                                        > >
                                        > >
                                        > >--- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
                                        > >>
                                        > >>
                                        > >> We typically use a 3 month rolling average when calculating velocity. Given that a team gets zero points for a story that isn't finished at the end of Sprint, it's not uncommon for the following Sprint to show a small increase in velocity, as the stories rolled over are credited to it.
                                        > >>
                                        > >> Averaging the velocity smooths out the bumps, and also help reduce the likelihood that someone would try to "game" the system, e.g. call a story done when it's not really ready. I'd rather have the story done-done, even if it means spending an extra day on it at the beginning of the subsequent iteration.
                                        > >>
                                        > >> Mark
                                        > >>
                                        > >>
                                        > >> --- In scrumdevelopment@yahoogroups.com, Ashish Mahajan <agileashish@> wrote:
                                        > >> >
                                        > >> >  http://ashish-the-agile-guy.com/2011/11/28/stable-velocity/
                                        > >> >
                                        > >>
                                        > >
                                        > >
                                        > >
                                        > >
                                        > >------------------------------------
                                        > >
                                        > >To Post a message, send it to:  scrumdevelopment@...
                                        > >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                                        > >
                                        > >
                                        > >
                                        > >
                                        > >
                                        > >
                                        >




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

                                        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/



                                      • Charles Bradley - Scrum Coach CSM PSM I
                                        Another thing that would be interesting to know is how many stories usually bleed over.  It should rarely be more than 1. The overall tone of what Sten
                                        Message 19 of 23 , Nov 30, 2011
                                        View Source
                                        • 0 Attachment
                                          Another thing that would be interesting to know is how many stories usually "bleed" over.  It should rarely be more than 1.

                                          The overall tone of what Sten describes is that of a group of individuals, not a team.  The way this seems to be accepted as "business as usual" by the dev team smacks of a different dysfunction, like the individuals reporting to a manager who thinks the "parallel silo" thing is totally ok and doesn't give a flip about true teamwork.  Further, you have a QA sub-team which is also a no-no according to the Scrum Guide(though I realize many teams struggle with that).  On top of that, we have the throw it over the wall to QA at end of sprint thing which smells like Scrummerfall.

                                          Hard to know where to start here, but the biggest smell of them all is of the team working in parallel silos.  

                                          Other interesting questions:  How many devs?  Roughly how many (non bleed over)stories are usually brought into the Sprint at Sprint Planning?
                                           
                                          -------
                                          Charles Bradley, CSM, PSM I
                                          Experienced Scrum Coach
                                          My blog: http://scrumcrazy.wordpress.com/

                                          From: Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...>
                                          To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
                                          Sent: Wednesday, November 30, 2011 11:00 AM
                                          Subject: Re: [scrumdevelopment] Re: Stable Velocity?



                                          Sten, you've given a lot more background which has highlighted some other risky practices... but I still don't understand what this means:

                                          > Keeping the estimates of userstories that bleeds over from one sprint ot another I do not think is helping them

                                          Is your team trying to take partial credit for stories as Mike suggests?
                                           
                                          -------
                                          Charles Bradley, CSM, PSM I
                                          Experienced Scrum Coach
                                          My blog: http://scrumcrazy.wordpress.com/

                                          From: Sten <steoj@...>
                                          To: scrumdevelopment@yahoogroups.com
                                          Sent: Wednesday, November 30, 2011 7:32 AM
                                          Subject: [scrumdevelopment] Re: Stable Velocity?

                                          Delivering value to the business is always a good thing - even if it happens at the beginning of the next sprint. I think we totally agree there.
                                          What happens in my team is that they take on a user story during sprint planning. So far everything is good.
                                          Then sprint is started, and so is the implementation of the user story - mostly by one team member with a few tasks at the end for the QA. Actually most of the user stories are in progress from the beginning of the sprint and usually worked on by one person, that hands it over to the QA person within the team for completion. QA's have a lot of work to do at the end of the sprint - if the user story is completed in time.
                                          If not, the story is bled over to the next sprint - because the PO still thinks it is important - and believes the team when they say it's just a few hours left of it even if it is a Medium user story originally.
                                          Then they continue with the user story in the next sprint and starts another when they have done "their" part of it. If they finish "their" user story before the sprint end, they agree with the product owner to pick another high priority one from the Product backlog that fits their competence. That is not a bad thing, but they seem not to care if they can finish it within the sprint or if the team in total is done with all other user stories they have committed in the sprint.

                                          To me it is obvious that they think it is far more efficient to work on something they know, rather than help someone with something the know less about. Keeping the estimates of userstories that bleeds over from one sprint ot another I do not think is helping them see how important it is for them to work together - as a team.

                                          Hope this sheds some more light on what I am trying to describe.

                                          /Sten

                                          --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
                                          >
                                          > Sten,
                                          >
                                          > > I do have an issue with the average velocity concept. In my team (I'm a
                                          > Scrum Master for one team of 9 people not including myself and the PO)
                                          > they insist on keeping the estimate on stories the almost complete in
                                          > one sprint to get the "correct payoff" of the whole story even though
                                          > completing it in the sprint they are in amounts to a 1 or a 2 and the
                                          > original estimate was a 5 or an 8.
                                          >
                                          > I had a heckuva time following what you're saying here... are you saying that the team carries stories over and finishes them early in the next sprint? What's so wrong with this?  A concrete example would help -- hard for me to tell whether you're doing the correct thing or not.
                                          >
                                          >  
                                          > -------
                                          > Charles Bradley, CSM, PSM I
                                          > Experienced Scrum Coach
                                          > My blog: http://scrumcrazy.wordpress.com/
                                          >
                                          >
                                          > >________________________________
                                          > > From: Sten <steoj@...>
                                          > >To: scrumdevelopment@yahoogroups.com
                                          > >Sent: Tuesday, November 29, 2011 4:52 AM
                                          > >Subject: [scrumdevelopment] Re: Stable Velocity?
                                          > >
                                          > >I do have an issue with the average velocity concept. In my team (I'm a Scrum Master for one team of 9 people not including myself and the PO) they insist on keeping the estimate on stories the almost complete in one sprint to get the "correct payoff" of the whole story even though completing it in the sprint they are in amounts to a 1 or a 2 and the original estimate was a 5 or an 8.
                                          > >
                                          > >I argue that the definition of velocity is COMPLETED features per sprint - not the value of several user stories completed over several sprints.
                                          > >
                                          > >I think the team is viewing me as tha bad guy trying to take away their "pay" wich they believe is the velocity.
                                          > >
                                          > >They do have other issues as well - some having the result of US not being completed at the end of the sprint - like silo-thinking "my tasks are done, so I'm done", planning the sprint to make sure there are tasks for everyone in the team. Finishing all that are finshed the last two or three days of the sprint, working on their own and so on.
                                          > >
                                          > >The PO is seems to be accepting the teams excuses for not completing the user stories.
                                          > >
                                          > >Most of my efforts to help them change their approach seems to be viewed as an attempt to tell them what to do and how to do it, rather than taken in as something to reflect on.
                                          > >
                                          > >When accepting average velocity I let them keep on fooling themselves by thinking not completing userstories has no real negative impact because we'll complete it next sprint anyway.
                                          > >
                                          > >Thoughts?
                                          > >
                                          > >
                                          > >--- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
                                          > >>
                                          > >>
                                          > >> We typically use a 3 month rolling average when calculating velocity. Given that a team gets zero points for a story that isn't finished at the end of Sprint, it's not uncommon for the following Sprint to show a small increase in velocity, as the stories rolled over are credited to it.
                                          > >>
                                          > >> Averaging the velocity smooths out the bumps, and also help reduce the likelihood that someone would try to "game" the system, e.g. call a story done when it's not really ready. I'd rather have the story done-done, even if it means spending an extra day on it at the beginning of the subsequent iteration.
                                          > >>
                                          > >> Mark
                                          > >>
                                          > >>
                                          > >> --- In scrumdevelopment@yahoogroups.com, Ashish Mahajan <agileashish@> wrote:
                                          > >> >
                                          > >> >  http://ashish-the-agile-guy.com/2011/11/28/stable-velocity/
                                          > >> >
                                          > >>
                                          > >
                                          > >
                                          > >
                                          > >
                                          > >------------------------------------
                                          > >
                                          > >To Post a message, send it to:  scrumdevelopment@...
                                          > >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                                          > >
                                          > >
                                          > >
                                          > >
                                          > >
                                          > >
                                          >




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

                                          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/







                                        • JackM
                                          You folks are 100% correct. The reason why you don t get partial points is precisely to get the teams to understand what the meaning of done is. I find that
                                          Message 20 of 23 , Nov 30, 2011
                                          View Source
                                          • 0 Attachment
                                            You folks are 100% correct. The reason why you don't get partial points is precisely to get the teams to understand what the meaning of done is. I find that this works really well in practice. The bottom line is if it's not done, it just causes a ripple effect through the release. And you never come right after that. So it's not a punishment, it's just a reality.

                                            Now some teams give partial points and it can work as long as you are consistent. But honestly if there are two things i would not give up, that is 1. don't ever lengthen a sprint, don't get points for partial completion.

                                            Stay tough!
                                            Jack
                                            www.agilebuddy.com
                                            blog.agilebuddy.com
                                            twitter.agielbuddy.com

                                            --- In scrumdevelopment@yahoogroups.com, Wouter Lagerweij <wouter@...> wrote:
                                            >
                                            > Perhaps you can ask them what they think velocity is used for.
                                            >
                                            > Sprints are the unit of planning for a Scrum project. Velocity is used to
                                            > find out after which sprint we can expect a story to be done. If a story is
                                            > not really done sprint, it has no value, so counting part of that story's
                                            > points for that sprint is completely useless. In fact, doing so means you
                                            > will be structurally over-estimating!
                                            >
                                            > I actually mentioned this same issue in a blog post on ways to make
                                            > velocity a useless
                                            > number<http://www.lagerweij.com/2011/07/08/5-ways-to-make-sure-velocity-is-useless/>.
                                            > (semi-shameless blog plug:-)
                                            >
                                            > Wouter
                                            >
                                            >
                                            > On Tue, Nov 29, 2011 at 12:52 PM, Sten <steoj@...> wrote:
                                            >
                                            > > **
                                            > >
                                            > >
                                            > > I do have an issue with the average velocity concept. In my team (I'm a
                                            > > Scrum Master for one team of 9 people not including myself and the PO) they
                                            > > insist on keeping the estimate on stories the almost complete in one sprint
                                            > > to get the "correct payoff" of the whole story even though completing it in
                                            > > the sprint they are in amounts to a 1 or a 2 and the original estimate was
                                            > > a 5 or an 8.
                                            > >
                                            > > I argue that the definition of velocity is COMPLETED features per sprint -
                                            > > not the value of several user stories completed over several sprints.
                                            > >
                                            > > I think the team is viewing me as tha bad guy trying to take away their
                                            > > "pay" wich they believe is the velocity.
                                            > >
                                            > > They do have other issues as well - some having the result of US not being
                                            > > completed at the end of the sprint - like silo-thinking "my tasks are done,
                                            > > so I'm done", planning the sprint to make sure there are tasks for everyone
                                            > > in the team. Finishing all that are finshed the last two or three days of
                                            > > the sprint, working on their own and so on.
                                            > >
                                            > > The PO is seems to be accepting the teams excuses for not completing the
                                            > > user stories.
                                            > >
                                            > > Most of my efforts to help them change their approach seems to be viewed
                                            > > as an attempt to tell them what to do and how to do it, rather than taken
                                            > > in as something to reflect on.
                                            > >
                                            > > When accepting average velocity I let them keep on fooling themselves by
                                            > > thinking not completing userstories has no real negative impact because
                                            > > we'll complete it next sprint anyway.
                                            > >
                                            > > Thoughts?
                                            > >
                                            > >
                                            > > --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
                                            > > >
                                            > > >
                                            > > > We typically use a 3 month rolling average when calculating velocity.
                                            > > Given that a team gets zero points for a story that isn't finished at the
                                            > > end of Sprint, it's not uncommon for the following Sprint to show a small
                                            > > increase in velocity, as the stories rolled over are credited to it.
                                            > > >
                                            > > > Averaging the velocity smooths out the bumps, and also help reduce the
                                            > > likelihood that someone would try to "game" the system, e.g. call a story
                                            > > done when it's not really ready. I'd rather have the story done-done, even
                                            > > if it means spending an extra day on it at the beginning of the subsequent
                                            > > iteration.
                                            > > >
                                            > > > Mark
                                            > > >
                                            > > >
                                            > > > --- In scrumdevelopment@yahoogroups.com, Ashish Mahajan <agileashish@>
                                            > > wrote:
                                            > > > >
                                            > > > > http://ashish-the-agile-guy.com/2011/11/28/stable-velocity/
                                            > > > >
                                            > > >
                                            > >
                                            > >
                                            > >
                                            >
                                            >
                                            >
                                            > --
                                            > Wouter Lagerweij | wouter@...
                                            > http://www.lagerweij.com | @wouterla <http://twitter.com/#!/wouterla>
                                            >
                                          • jamesjhawkins
                                            Yes, Definition of Done should be part of the solution to this problem. However, if the team refuses to own quality, they will probably refuse to set a useful
                                            Message 21 of 23 , Dec 1, 2011
                                            View Source
                                            • 0 Attachment
                                              Yes, Definition of Done should be part of the solution to this problem.

                                              However, if the team refuses to own quality, they will probably refuse to set a useful DoD too :)

                                              Cheers, Jim
                                            • Sten
                                              The last sprint was probably more or less typical - at least they seem not to be particularly worried about it: Sprint 36 (Yes, two week sprints) the team took
                                              Message 22 of 23 , Dec 2, 2011
                                              View Source
                                              • 0 Attachment
                                                The last sprint was probably more or less typical - at least they seem not to be particularly worried about it:
                                                Sprint 36 (Yes, two week sprints) the team took on Story1, Story2, Story4, Story6, Story7, Story8, Story9, Story10, Story11, Story12 and Story13, totalling 30 storypoints.
                                                In addition they were spiking Story 3 and Story 5.

                                                The PO needed some help from the team (!) to clarify what userstories was actually done and the PO and the team conlcuded only Story7, Story9 and Story11 was done, totalling 7 story points.
                                                The team all agreed it was a good sprint thoug, because they did get a lot of work done.

                                                During sprint planning part I Story12 was postponed to a later sprint but other than that all unfinished stories from sprint 36 was continued to sprint 37.

                                                For sprint 37, the team added Stories 14 through 26, the spiked stories from 36 (Story3 and Story5) in addition to the uncompleted ones from sprint 36, totalling 56 storypoints.
                                                As I'm writing this, (end of sprint on Wednesday next week) Story3, Story4, Story5, Story6 and Story8 is done (13 sp). The rest (all of them) is ongoing - a handful of them waiting for QA to pick up.

                                                The team has 9 members, two scripters, two QA and five Business Analysts in addition to full-time SM and PO.

                                                The project is high profile within the company. We've been working for 18 months and no release to production yet. We are not writing much code, more configuring an off-the-shelf product (that is not a result of Agile development - average bug fix time on core product is 105 days) to suit the business. The product is core business and quality is essential.
                                                Up to this sprint, the project has asked the PO's to report progress in terms of percent of target scope (!). For some time during the project my team has felt as the bad apple in the project (there are 4 other teams) where velocity has been an issue.

                                                I have taken over the SM responsibilities of this team since roughly 5-6 sprints ago. My predecessor - an experienced SM - was literally sacked from the team after beeing very pushy on agile practices. It seems they perceived almost every suggestion he shared as critisism to the way they worked.

                                                I have decided to lay low (remember: A dead SM is a bad SM) and stroke them by the hairs for a while. I believe they behave like this for several reasons, amongst them the way the project is structured. In addition no-one in the team are really experienced in agile practices and quickly concludes that "it is not possible" beeing finishing small user stories quicker within a sprint, splitting them in a user-oriented way or pairing to learn of eachother.

                                                My point in the original post was that keeping the estimate of the stories bleeding over from the previous sprint might "hide" the issues a little. I'm thinking the unfinished should be re-estimated prior to the sprint they are taken into so the PO will have a fair chance at doing the ordering properly. It would mean that the total storypoints taken into this sprint is a little lower - maybe a little over 40? - but at least it would be more obvious to the team (I hope) that changing the way they work might be a good idea.

                                                We are a good team of SM's focusing a lot on how the project organisation - not to mention the obvious lack of releases to production - is affecting the teams performance and the overall progress.

                                                This became a little longer than I had anticipated, but hope it clarifies my situation a little.

                                                /Sten

                                                --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
                                                >
                                                > Another thing that would be interesting to know is how many stories usually "bleed" over.  It should rarely be more than 1.
                                                >
                                                > The overall tone of what Sten describes is that of a group of individuals, not a team.  The way this seems to be accepted as "business as usual" by the dev team smacks of a different dysfunction, like the individuals reporting to a manager who thinks the "parallel silo" thing is totally ok and doesn't give a flip about true teamwork.  Further, you have a QA sub-team which is also a no-no according to the Scrum Guide(though I realize many teams struggle with that).  On top of that, we have the throw it over the wall to QA at end of sprint thing which smells like Scrummerfall.
                                                >
                                                > Hard to know where to start here, but the biggest smell of them all is of the team working in parallel silos.  
                                                >
                                                > Other interesting questions:  How many devs?  Roughly how many (non bleed over)stories are usually brought into the Sprint at Sprint Planning?
                                                >
                                                >  
                                                > -------
                                                > Charles Bradley, CSM, PSM I
                                                > Experienced Scrum Coach
                                                > My blog: http://scrumcrazy.wordpress.com/
                                                >
                                                >
                                                > >________________________________
                                                > > From: Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...>
                                                > >To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
                                                > >Sent: Wednesday, November 30, 2011 11:00 AM
                                                > >Subject: Re: [scrumdevelopment] Re: Stable Velocity?
                                                > >
                                                > >
                                                > >
                                                > >
                                                > >
                                                > >
                                                > >Sten, you've given a lot more background which has highlighted some other risky practices... but I still don't understand what this means:
                                                > >
                                                > >
                                                > >> Keeping the estimates of userstories that bleeds over from one sprint ot another I do not think is helping them
                                                > >
                                                > >
                                                > >Is your team trying to take partial credit for stories as Mike suggests?
                                                > >
                                                > > 
                                                > >-------
                                                > >Charles Bradley, CSM, PSM I
                                                > >Experienced Scrum Coach
                                                > >My blog: http://scrumcrazy.wordpress.com/
                                                > >
                                                > >
                                                > >>________________________________
                                                > >> From: Sten <steoj@...>
                                                > >>To: scrumdevelopment@yahoogroups.com
                                                > >>Sent: Wednesday, November 30, 2011 7:32 AM
                                                > >>Subject: [scrumdevelopment] Re: Stable Velocity?
                                                > >>
                                                > >>Delivering value to the business is always a good thing - even if it happens at the beginning of the next sprint. I think we totally agree there.
                                                > >>What happens in my team is that they take on a user story during sprint planning. So far everything is good.
                                                > >>Then sprint is started, and so is the implementation of the user story - mostly by one team member with a few tasks at the end for the QA. Actually most of the user stories are in progress from the beginning of the sprint and usually worked on by one person, that hands it over to
                                                > the QA person within the team for completion. QA's have a lot of work to do at the end of the sprint - if the user story is completed in time.
                                                > >>If not, the story is bled over to the next sprint - because the PO still thinks it is important - and believes the team when they say it's just a few hours left of it even if it is a Medium user story originally.
                                                > >>Then they continue with the user story in the next sprint and starts another when they have done "their" part of it. If they finish "their" user story before the sprint end, they agree with the product owner to pick another high priority one from the Product backlog that fits their competence. That is not a bad thing, but they seem not to care if they can finish it within the sprint or if the team in total is done with all other user stories they have committed in the sprint.
                                                > >>
                                                > >>To me it is obvious that they think it is far more efficient to work on something they know, rather than help
                                                > someone with something the know less about. Keeping the estimates of userstories that bleeds over from one sprint ot another I do not think is helping them see how important it is for them to work together - as a team.
                                                > >>
                                                > >>Hope this sheds some more light on what I am trying to describe.
                                                > >>
                                                > >>/Sten
                                                > >>
                                                > >>--- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@> wrote:
                                                > >>>
                                                > >>> Sten,
                                                > >>>
                                                > >>> > I do have an issue with the average velocity concept. In my team (I'm a
                                                > >>> Scrum Master for one team of 9 people not including myself and the PO)
                                                > >>> they insist on keeping the estimate on stories the almost complete in
                                                > >>> one sprint to get the "correct payoff" of the whole story even though
                                                > >>> completing it in the sprint they are in amounts to a 1 or a 2 and the
                                                > >>> original estimate was a 5 or an 8.
                                                > >>>
                                                > >>> I had a heckuva time following what you're saying here... are you saying that the team carries stories over and finishes them early in the next sprint? What's so wrong with this?  A concrete example would help -- hard for me to tell whether you're doing the correct thing or not.
                                                > >>>
                                                > >>>  
                                                > >>> -------
                                                > >>> Charles Bradley, CSM, PSM I
                                                > >>> Experienced Scrum Coach
                                                > >>> My blog: http://scrumcrazy.wordpress.com/
                                                > >>>
                                                > >>>
                                                > >>> >________________________________
                                                > >>> > From: Sten <steoj@>
                                                > >>> >To: scrumdevelopment@yahoogroups.com
                                                > >>> >Sent: Tuesday, November 29, 2011 4:52 AM
                                                > >>> >Subject: [scrumdevelopment] Re: Stable Velocity?
                                                > >>> >
                                                > >>>
                                                > >I do have an issue with the average velocity concept. In my team (I'm a Scrum Master for one team of 9 people not including myself and the PO) they insist on keeping the estimate on stories the almost complete in one sprint to get the "correct payoff" of the whole story even though completing it in the sprint they are in amounts to a 1 or a 2 and the original estimate was a 5 or an 8.
                                                > >>> >
                                                > >>> >I argue that the definition of velocity is COMPLETED features per sprint - not the value of several user stories completed over several sprints.
                                                > >>> >
                                                > >>> >I think the team is viewing me as tha bad guy trying to take away their "pay" wich they believe is the velocity.
                                                > >>> >
                                                > >>> >They do have other issues as well - some having the result of US not being completed at the end of the sprint - like silo-thinking "my tasks are done, so I'm done", planning the sprint to make sure there are tasks for everyone in the team.
                                                > Finishing all that are finshed the last two or three days of the sprint, working on their own and so on.
                                                > >>> >
                                                > >>> >The PO is seems to be accepting the teams excuses for not completing the user stories.
                                                > >>> >
                                                > >>> >Most of my efforts to help them change their approach seems to be viewed as an attempt to tell them what to do and how to do it, rather than taken in as something to reflect on.
                                                > >>> >
                                                > >>> >When accepting average velocity I let them keep on fooling themselves by thinking not completing userstories has no real negative impact because we'll complete it next sprint anyway.
                                                > >>> >
                                                > >>> >Thoughts?
                                                > >>> >
                                                > >>> >
                                                > >>> >--- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
                                                > >>> >>
                                                > >>> >>
                                                > >>> >> We typically use a 3 month rolling
                                                > average when calculating velocity. Given that a team gets zero points for a story that isn't finished at the end of Sprint, it's not uncommon for the following Sprint to show a small increase in velocity, as the stories rolled over are credited to it.
                                                > >>> >>
                                                > >>> >> Averaging the velocity smooths out the bumps, and also help reduce the likelihood that someone would try to "game" the system, e.g. call a story done when it's not really ready. I'd rather have the story done-done, even if it means spending an extra day on it at the beginning of the subsequent iteration.
                                                > >>> >>
                                                > >>> >> Mark
                                                > >>> >>
                                                > >>> >>
                                                > >>> >> --- In scrumdevelopment@yahoogroups.com, Ashish Mahajan <agileashish@> wrote:
                                                > >>> >> >
                                                > >>> >> >  http://ashish-the-agile-guy.com/2011/11/28/stable-velocity/
                                                > >>> >> >
                                                > >>> >>
                                                > >>> >
                                                > >>> >
                                                > >>> >
                                                > >>> >
                                                > >>> >------------------------------------
                                                > >>> >
                                                > >>> >To Post a message, send it to:  scrumdevelopment@
                                                > >>> >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@! Groups Links
                                                > >>> >
                                                > >>> >
                                                > >>> >
                                                > >>> >
                                                > >>> >
                                                > >>> >
                                                > >>>
                                                > >>
                                                > >>
                                                > >>
                                                > >>
                                                > >>------------------------------------
                                                > >>
                                                > >>To Post a message, send it to:  scrumdevelopment@...
                                                > >>To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                                                > >>
                                                > >>
                                                > >>
                                                > >>
                                                > >>
                                                > >>
                                                > >
                                                > >
                                                > >
                                                > >
                                                > >
                                                >
                                              • Wouter Lagerweij
                                                Hi Sten, It seems your team is not very comfortable with working in sprints, yet. A Question: You say the team has felt as a bad apple about their velocity?
                                                Message 23 of 23 , Dec 2, 2011
                                                View Source
                                                • 0 Attachment
                                                  Hi Sten,

                                                  It seems your team is not very comfortable with working in sprints, yet. 

                                                  A Question: You say the team has felt as a 'bad apple' about their velocity? Is there any direct pressure on them to increase their velocity? This could be (one of) the underlying issue for wanting to count partially done stories.

                                                  Does the team themselves feel that there is a problem? You say they felt they had a good sprint, but did they see not finishing many stories as an issue in the retrospective? 

                                                  From what you say, I'd probable work first on getting the team focused on preparing the stories for each sprint (do you do grooming session or something similar?). Ensuring stories have Acceptance Criteria defined *before* you take them into the sprint will make things much clearer within the sprint. It will also get your QA guys involved more and earlier. And usually, as soon as you start defining ACs, some possibilities for splitting up stories will automatically present themselves.

                                                  Plus, by agreeing with the team that this should be worked on, they should be more willing to take less into the sprint, as the time reserved for backlog grooming is taken into account.

                                                  Note that this is something separate from defining a Definition of Done, which is the generic checklist for every story, while the ACs are story-specific.

                                                  Wouter



                                                  On Fri, Dec 2, 2011 at 9:21 AM, Sten <steoj@...> wrote:
                                                   

                                                  The last sprint was probably more or less typical - at least they seem not to be particularly worried about it:
                                                  Sprint 36 (Yes, two week sprints) the team took on Story1, Story2, Story4, Story6, Story7, Story8, Story9, Story10, Story11, Story12 and Story13, totalling 30 storypoints.
                                                  In addition they were spiking Story 3 and Story 5.

                                                  The PO needed some help from the team (!) to clarify what userstories was actually done and the PO and the team conlcuded only Story7, Story9 and Story11 was done, totalling 7 story points.
                                                  The team all agreed it was a good sprint thoug, because they did get a lot of work done.

                                                  During sprint planning part I Story12 was postponed to a later sprint but other than that all unfinished stories from sprint 36 was continued to sprint 37.

                                                  For sprint 37, the team added Stories 14 through 26, the spiked stories from 36 (Story3 and Story5) in addition to the uncompleted ones from sprint 36, totalling 56 storypoints.
                                                  As I'm writing this, (end of sprint on Wednesday next week) Story3, Story4, Story5, Story6 and Story8 is done (13 sp). The rest (all of them) is ongoing - a handful of them waiting for QA to pick up.

                                                  The team has 9 members, two scripters, two QA and five Business Analysts in addition to full-time SM and PO.

                                                  The project is high profile within the company. We've been working for 18 months and no release to production yet. We are not writing much code, more configuring an off-the-shelf product (that is not a result of Agile development - average bug fix time on core product is 105 days) to suit the business. The product is core business and quality is essential.
                                                  Up to this sprint, the project has asked the PO's to report progress in terms of percent of target scope (!). For some time during the project my team has felt as the bad apple in the project (there are 4 other teams) where velocity has been an issue.

                                                  I have taken over the SM responsibilities of this team since roughly 5-6 sprints ago. My predecessor - an experienced SM - was literally sacked from the team after beeing very pushy on agile practices. It seems they perceived almost every suggestion he shared as critisism to the way they worked.

                                                  I have decided to lay low (remember: A dead SM is a bad SM) and stroke them by the hairs for a while. I believe they behave like this for several reasons, amongst them the way the project is structured. In addition no-one in the team are really experienced in agile practices and quickly concludes that "it is not possible" beeing finishing small user stories quicker within a sprint, splitting them in a user-oriented way or pairing to learn of eachother.

                                                  My point in the original post was that keeping the estimate of the stories bleeding over from the previous sprint might "hide" the issues a little. I'm thinking the unfinished should be re-estimated prior to the sprint they are taken into so the PO will have a fair chance at doing the ordering properly. It would mean that the total storypoints taken into this sprint is a little lower - maybe a little over 40? - but at least it would be more obvious to the team (I hope) that changing the way they work might be a good idea.

                                                  We are a good team of SM's focusing a lot on how the project organisation - not to mention the obvious lack of releases to production - is affecting the teams performance and the overall progress.

                                                  This became a little longer than I had anticipated, but hope it clarifies my situation a little.



                                                  /Sten

                                                  --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
                                                  >
                                                  > Another thing that would be interesting to know is how many stories usually "bleed" over.  It should rarely be more than 1.
                                                  >
                                                  > The overall tone of what Sten describes is that of a group of individuals, not a team.  The way this seems to be accepted as "business as usual" by the dev team smacks of a different dysfunction, like the individuals reporting to a manager who thinks the "parallel silo" thing is totally ok and doesn't give a flip about true teamwork.  Further, you have a QA sub-team which is also a no-no according to the Scrum Guide(though I realize many teams struggle with that).  On top of that, we have the throw it over the wall to QA at end of sprint thing which smells like Scrummerfall.
                                                  >
                                                  > Hard to know where to start here, but the biggest smell of them all is of the team working in parallel silos.  
                                                  >
                                                  > Other interesting questions:  How many devs?  Roughly how many (non bleed over)stories are usually brought into the Sprint at Sprint Planning?
                                                  >
                                                  >  
                                                  > -------
                                                  > Charles Bradley, CSM, PSM I
                                                  > Experienced Scrum Coach
                                                  > My blog: http://scrumcrazy.wordpress.com/
                                                  >
                                                  >
                                                  > >________________________________
                                                  > > From: Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...>

                                                  > >To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
                                                  > >Sent: Wednesday, November 30, 2011 11:00 AM
                                                  > >Subject: Re: [scrumdevelopment] Re: Stable Velocity?
                                                  > >
                                                  > >
                                                  > >
                                                  > >
                                                  > >
                                                  > >
                                                  > >Sten, you've given a lot more background which has highlighted some other risky practices... but I still don't understand what this means:
                                                  > >
                                                  > >
                                                  > >> Keeping the estimates of userstories that bleeds over from one sprint ot another I do not think is helping them
                                                  > >
                                                  > >
                                                  > >Is your team trying to take partial credit for stories as Mike suggests?
                                                  > >
                                                  > > 
                                                  > >-------
                                                  > >Charles Bradley, CSM, PSM I
                                                  > >Experienced Scrum Coach
                                                  > >My blog: http://scrumcrazy.wordpress.com/
                                                  > >
                                                  > >
                                                  > >>________________________________
                                                  > >> From: Sten <steoj@...>

                                                  > >>To: scrumdevelopment@yahoogroups.com
                                                  > >>Sent: Wednesday, November 30, 2011 7:32 AM
                                                  > >>Subject: [scrumdevelopment] Re: Stable Velocity?
                                                  > >>
                                                  > >>Delivering value to the business is always a good thing - even if it happens at the beginning of the next sprint. I think we totally agree there.
                                                  > >>What happens in my team is that they take on a user story during sprint planning. So far everything is good.
                                                  > >>Then sprint is started, and so is the implementation of the user story - mostly by one team member with a few tasks at the end for the QA. Actually most of the user stories are in progress from the beginning of the sprint and usually worked on by one person, that hands it over to
                                                  > the QA person within the team for completion. QA's have a lot of work to do at the end of the sprint - if the user story is completed in time.
                                                  > >>If not, the story is bled over to the next sprint - because the PO still thinks it is important - and believes the team when they say it's just a few hours left of it even if it is a Medium user story originally.
                                                  > >>Then they continue with the user story in the next sprint and starts another when they have done "their" part of it. If they finish "their" user story before the sprint end, they agree with the product owner to pick another high priority one from the Product backlog that fits their competence. That is not a bad thing, but they seem not to care if they can finish it within the sprint or if the team in total is done with all other user stories they have committed in the sprint.
                                                  > >>
                                                  > >>To me it is obvious that they think it is far more efficient to work on something they know, rather than help
                                                  > someone with something the know less about. Keeping the estimates of userstories that bleeds over from one sprint ot another I do not think is helping them see how important it is for them to work together - as a team.
                                                  > >>
                                                  > >>Hope this sheds some more light on what I am trying to describe.
                                                  > >>
                                                  > >>/Sten
                                                  > >>
                                                  > >>--- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@> wrote:
                                                  > >>>
                                                  > >>> Sten,
                                                  > >>>
                                                  > >>> > I do have an issue with the average velocity concept. In my team (I'm a
                                                  > >>> Scrum Master for one team of 9 people not including myself and the PO)
                                                  > >>> they insist on keeping the estimate on stories the almost complete in
                                                  > >>> one sprint to get the "correct payoff" of the whole story even though
                                                  > >>> completing it in the sprint they are in amounts to a 1 or a 2 and the
                                                  > >>> original estimate was a 5 or an 8.
                                                  > >>>
                                                  > >>> I had a heckuva time following what you're saying here... are you saying that the team carries stories over and finishes them early in the next sprint? What's so wrong with this?  A concrete example would help -- hard for me to tell whether you're doing the correct thing or not.
                                                  > >>>
                                                  > >>>  
                                                  > >>> -------
                                                  > >>> Charles Bradley, CSM, PSM I
                                                  > >>> Experienced Scrum Coach
                                                  > >>> My blog: http://scrumcrazy.wordpress.com/
                                                  > >>>
                                                  > >>>
                                                  > >>> >________________________________
                                                  > >>> > From: Sten <steoj@>
                                                  > >>> >To: scrumdevelopment@yahoogroups.com
                                                  > >>> >Sent: Tuesday, November 29, 2011 4:52 AM
                                                  > >>> >Subject: [scrumdevelopment] Re: Stable Velocity?
                                                  > >>> >
                                                  > >>>
                                                  > >I do have an issue with the average velocity concept. In my team (I'm a Scrum Master for one team of 9 people not including myself and the PO) they insist on keeping the estimate on stories the almost complete in one sprint to get the "correct payoff" of the whole story even though completing it in the sprint they are in amounts to a 1 or a 2 and the original estimate was a 5 or an 8.
                                                  > >>> >
                                                  > >>> >I argue that the definition of velocity is COMPLETED features per sprint - not the value of several user stories completed over several sprints.
                                                  > >>> >
                                                  > >>> >I think the team is viewing me as tha bad guy trying to take away their "pay" wich they believe is the velocity.
                                                  > >>> >
                                                  > >>> >They do have other issues as well - some having the result of US not being completed at the end of the sprint - like silo-thinking "my tasks are done, so I'm done", planning the sprint to make sure there are tasks for everyone in the team.
                                                  > Finishing all that are finshed the last two or three days of the sprint, working on their own and so on.
                                                  > >>> >
                                                  > >>> >The PO is seems to be accepting the teams excuses for not completing the user stories.
                                                  > >>> >
                                                  > >>> >Most of my efforts to help them change their approach seems to be viewed as an attempt to tell them what to do and how to do it, rather than taken in as something to reflect on.
                                                  > >>> >
                                                  > >>> >When accepting average velocity I let them keep on fooling themselves by thinking not completing userstories has no real negative impact because we'll complete it next sprint anyway.
                                                  > >>> >
                                                  > >>> >Thoughts?
                                                  > >>> >
                                                  > >>> >
                                                  > >>> >--- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
                                                  > >>> >>
                                                  > >>> >>
                                                  > >>> >> We typically use a 3 month rolling
                                                  > average when calculating velocity. Given that a team gets zero points for a story that isn't finished at the end of Sprint, it's not uncommon for the following Sprint to show a small increase in velocity, as the stories rolled over are credited to it.
                                                  > >>> >>
                                                  > >>> >> Averaging the velocity smooths out the bumps, and also help reduce the likelihood that someone would try to "game" the system, e.g. call a story done when it's not really ready. I'd rather have the story done-done, even if it means spending an extra day on it at the beginning of the subsequent iteration.
                                                  > >>> >>
                                                  > >>> >> Mark
                                                  > >>> >>
                                                  > >>> >>
                                                  > >>> >> --- In scrumdevelopment@yahoogroups.com, Ashish Mahajan <agileashish@> wrote:
                                                  > >>> >> >
                                                  > >>> >> >  http://ashish-the-agile-guy.com/2011/11/28/stable-velocity/
                                                  > >>> >> >
                                                  > >>> >>
                                                  > >>> >
                                                  > >>> >
                                                  > >>> >
                                                  > >>> >
                                                  > >>> >------------------------------------
                                                  > >>> >
                                                  > >>> >To Post a message, send it to:  scrumdevelopment@
                                                  > >>> >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@! Groups Links

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




                                                  --
                                                  Wouter Lagerweij         | wouter@...
                                                Your message has been successfully submitted and would be delivered to recipients shortly.