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

Sprint Goal and extra stories

Expand Messages
  • Gercel Silva
    Hi folks, What do you guys think about having a story that the team did not forecast to deliver in the Sprint Backlog just because the team might have it
    Message 1 of 24 , Oct 25, 2012
    • 0 Attachment
      Hi folks,

      What do you guys think about having a story that the team did not forecast to deliver in the Sprint Backlog just because the team 'might' have it done by the end of the Sprint? I've seen it happen recently and people say that the whole sprint is what is 'possible' and the goal should match only a subset of the stories in it, which the team is commited to deliver.

      The burndown chart includes those 'extra stories' since the beginning and it is not uncommom that by the end of the sprint they are untouched. The sprint is considered sucessfull but the sprint backlog/burndown show that there is still work to be done (extra stories that go to the next sprint).

      How would you advise people in this situation?

      Regards,
      Gercel Silva
    • RonJeffries
      Gercel, In Scrum, the team forecasts (or commits, if you prefer) to what they really expect to accomplish. Putting more than that on the backlog just makes
      Message 2 of 24 , Oct 25, 2012
      • 0 Attachment
        Gercel,
        In Scrum, the team forecasts (or commits, if you prefer) to what they really expect to accomplish. Putting more than that on the backlog just makes success look like failure.
        R
        On Oct 25, 2012, at 6:38 AM, Gercel Silva <gercel@...> wrote:

        What do you guys think about having a story that the team did not forecast to deliver in the Sprint Backlog just because the team 'might' have it done by the end of the Sprint? I've seen it happen recently and people say that the whole sprint is what is 'possible' and the goal should match only a subset of the stories in it, which the team is commited to deliver.

        The burndown chart includes those 'extra stories' since the beginning and it is not uncommom that by the end of the sprint they are untouched. The sprint is considered sucessfull but the sprint backlog/burndown show that there is still work to be done (extra stories that go to the next sprint).

        How would you advise people in this situation?


        Ron Jeffries
        www.XProgramming.com
        Sometimes I give myself admirable advice, but I am incapable of taking it.
        -- Mary Wortley Montagu



      • Adam Sroka
        Ron is 100% correct for Scrum. However, you might be interested in investigating the way XP teams or Kanban teams approach this. I generally recommend that
        Message 3 of 24 , Oct 25, 2012
        • 0 Attachment
          Ron is 100% correct for Scrum. 

          However, you might be interested in investigating the way XP teams or Kanban teams approach this. I generally recommend that teams work on stories serially, and then once they develop an intuitive sense for how long stories take we start prepping them just before we need them. That only seems to work for very small teams without a lot of bureacracy, though. 

          On Thu, Oct 25, 2012 at 1:35 PM, RonJeffries <ronjeffries@...> wrote:
           

          Gercel,

          In Scrum, the team forecasts (or commits, if you prefer) to what they really expect to accomplish. Putting more than that on the backlog just makes success look like failure.
          R
          On Oct 25, 2012, at 6:38 AM, Gercel Silva <gercel@...> wrote:

          What do you guys think about having a story that the team did not forecast to deliver in the Sprint Backlog just because the team 'might' have it done by the end of the Sprint? I've seen it happen recently and people say that the whole sprint is what is 'possible' and the goal should match only a subset of the stories in it, which the team is commited to deliver.

          The burndown chart includes those 'extra stories' since the beginning and it is not uncommom that by the end of the sprint they are untouched. The sprint is considered sucessfull but the sprint backlog/burndown show that there is still work to be done (extra stories that go to the next sprint).

          How would you advise people in this situation?


          Ron Jeffries
          www.XProgramming.com
          Sometimes I give myself admirable advice, but I am incapable of taking it.
          -- Mary Wortley Montagu




        • RonJeffries
          Hi Adam, ... This is a good way to work for a reasonably expert team. It is a very Kanban thing to do. XP includes an Iteration Planning Meeting that is the
          Message 4 of 24 , Oct 25, 2012
          • 0 Attachment
            Hi Adam,

            On Oct 25, 2012, at 5:02 PM, Adam Sroka <adam.sroka@...> wrote:

            However, you might be interested in investigating the way XP teams or Kanban teams approach this. I generally recommend that teams work on stories serially, and then once they develop an intuitive sense for how long stories take we start prepping them just before we need them. That only seems to work for very small teams without a lot of bureacracy, though. 

            This is a good way to work for a reasonably expert team. It is a very "Kanban" thing to do. XP includes an Iteration Planning Meeting that is the exact analog of the Sprint Planning Meeting, and creates the same sort of plan for N stories.

            In a Scrum context, single piece flow is outside the Scrum framework and I would not recommend that teams starting with Scrum start there. Naturally, if they're not doing Scrum, they can start anywhere.
            If not now, when? -- Rabbi Hillel

          • Kevin Callahan
            Additional work can always be pulled in if needed. If a story is important enough that there is pressure to put it into the current sprint, then perhaps the
            Message 5 of 24 , Oct 25, 2012
            • 0 Attachment
              Additional work can always be pulled in if needed. If a story is important enough that there is pressure to put it into the current sprint, then perhaps the backlog order is not accurately prioritized? Hard to know with such a thin slice of the situation...

              -kevin

              On Oct 25, 2012, at 4:35 PM, RonJeffries wrote:

               

              Gercel,

              In Scrum, the team forecasts (or commits, if you prefer) to what they really expect to accomplish. Putting more than that on the backlog just makes success look like failure.
              R
              On Oct 25, 2012, at 6:38 AM, Gercel Silva <gercel@...> wrote:

              What do you guys think about having a story that the team did not forecast to deliver in the Sprint Backlog just because the team 'might' have it done by the end of the Sprint? I've seen it happen recently and people say that the whole sprint is what is 'possible' and the goal should match only a subset of the stories in it, which the team is commited to deliver.

              The burndown chart includes those 'extra stories' since the beginning and it is not uncommom that by the end of the sprint they are untouched. The sprint is considered sucessfull but the sprint backlog/burndown show that there is still work to be done (extra stories that go to the next sprint).

              How would you advise people in this situation?


              Ron Jeffries
              www.XProgramming.com
              Sometimes I give myself admirable advice, but I am incapable of taking it.
              -- Mary Wortley Montagu





              LiveWorld
              Kevin Callahan
              Scrum Master & Agile Coach
              LiveWorld Inc.
              Direct+1 (207) 691-2997
              Skypekevmocal
              Follow UsFacebook Twitter LinkedIn



            • Steve
              Hello Garcel There are 2 schools of thought about this; Ron has already given you his take on it which is what many people do. My take is different. Firstly
              Message 6 of 24 , Oct 25, 2012
              • 0 Attachment
                Hello Garcel

                There are 2 schools of thought about this; Ron has already given you his take on it which is what many people do.

                My take is different. Firstly the subject of commitment. It is my understanding from the Sprint documentation that the Development Team commit to the Sprint Goal set by and agreed with the Product Owner; they do not commit to all the selected User Stories.

                Let us look at the situation where the Development Team have estimated that they could develop all the stories and commit to them.

                You woud now have the situation where you have a fixed team (fixed cost), fixed time and fixed requirements. This is a recipe for failure; the Team may run out of requirements before the end of the Sprint (unlikely) or they do not finish all the requirements; they were only estimates!

                So I ask the Development Team to select the User Stories that they think they can complete in agreement with the PO and then they agree the minimum that would meet the Sprint Goal; the rest are the contingency (we only do honest estimates).

                I usually advise that the minimum requirements for the Sprint should reprsent about 60-65% of the estimated effort of all the selected User Stories. Many of the non-minimum User Stories will get 'done' but it is not a failure if all of them are not 'done'

                So, yes, the Sprint burndown charts will rarely tend to zero work left to do.

                Part of the Sprint Review process is to discuss the requirements that were not done and what to do with them.

                My take - it works - but there are other approaches as I said; mine stems from a different interpretation of the word commitment in the context of the Sprint.

                --- In scrumdevelopment@yahoogroups.com, Gercel Silva <gercel@...> wrote:
                >
                > Hi folks,
                >
                > What do you guys think about having a story that the team did not forecast
                > to deliver in the Sprint Backlog just because the team 'might' have it done
                > by the end of the Sprint? I've seen it happen recently and people say that
                > the whole sprint is what is 'possible' and the goal should match only a
                > subset of the stories in it, which the team is commited to deliver.
                >
                > The burndown chart includes those 'extra stories' since the beginning and
                > it is not uncommom that by the end of the sprint they are untouched. The
                > sprint is considered sucessfull but the sprint backlog/burndown show that
                > there is still work to be done (extra stories that go to the next sprint).
                >
                > How would you advise people in this situation?
                >
                > Regards,
                > Gercel Silva
                >
              • Adam Sroka
                It is a very low ceremony kind of Kanban. Industrial Logic/Joshua Kerievsky recommend something similar and call it Ultra Lean. However, during my time there
                Message 7 of 24 , Oct 25, 2012
                • 0 Attachment
                  It is a very low ceremony kind of Kanban. Industrial Logic/Joshua Kerievsky recommend something similar and call it "Ultra Lean." However, during my time there we did something a bit more complex because the team membership was very dynamic from week to week. 

                  When I worked with Bob Payne in 2004-ish we would designate a story as "kicker" to be started only if we finished everything else and agreed there was time left. I don't know where that practice originated, but we were otherwise fairly strictly following the XP practices. 

                  On Thu, Oct 25, 2012 at 2:06 PM, RonJeffries <ronjeffries@...> wrote:
                   

                  Hi Adam,


                  On Oct 25, 2012, at 5:02 PM, Adam Sroka <adam.sroka@...> wrote:

                  However, you might be interested in investigating the way XP teams or Kanban teams approach this. I generally recommend that teams work on stories serially, and then once they develop an intuitive sense for how long stories take we start prepping them just before we need them. That only seems to work for very small teams without a lot of bureacracy, though. 

                  This is a good way to work for a reasonably expert team. It is a very "Kanban" thing to do. XP includes an Iteration Planning Meeting that is the exact analog of the Sprint Planning Meeting, and creates the same sort of plan for N stories.

                  In a Scrum context, single piece flow is outside the Scrum framework and I would not recommend that teams starting with Scrum start there. Naturally, if they're not doing Scrum, they can start anywhere.
                  If not now, when? -- Rabbi Hillel


                • RonJeffries
                  Hi Adam, ... Yes. My only point is that Scrum expects a commitment (or at least a forecast) of the work to be accomplished in a time-boxed Sprint. Ron Jeffries
                  Message 8 of 24 , Oct 25, 2012
                  • 0 Attachment
                    Hi Adam,

                    On Oct 25, 2012, at 5:14 PM, Adam Sroka <adam.sroka@...> wrote:

                    It is a very low ceremony kind of Kanban. Industrial Logic/Joshua Kerievsky recommend something similar and call it "Ultra Lean." However, during my time there we did something a bit more complex because the team membership was very dynamic from week to week. 

                    Yes. My only point is that Scrum expects a commitment (or at least a forecast) of the work to be accomplished in a time-boxed Sprint.

                    Ron Jeffries
                    I'm not bad, I'm just drawn that way.  -- Jessica Rabbit

                  • Alan Dayley
                    My advice: This practice makes it look like the sprint is never successful, as Ron said. Don t do that. This practice makes it normal to carry over
                    Message 9 of 24 , Oct 25, 2012
                    • 0 Attachment
                      My advice:

                      This practice makes it look like the sprint is never successful, as Ron said.  Don't do that.

                      This practice makes it normal to carry over uncompleted stories straight into the next sprint.  This creates a feel of a treadmill instead of a rhythm of getting done regularly.  This also creates a feeling that not getting things done is OK.  Don't do that.

                      This practice redefines the acceptable amount of work as a quantity less than the possible amount of work.  Don't do that.

                      This practice can remove the transparency of seeing when work is blocked or regularly slower than it should be because it's OK to not get everything done. So some organizational, skill or other impediments will remain hidden.  Don't do that.

                      Instead, have a story or two on the Product Backlog ready to be worked on IF there is time in the sprint to get them done.  If there is time, pull it in and finish it.  Only put it on the Sprint Backlog and the Burndown at the time it gets pulled in, not before. This emphasizes how wonderful it is to get additional work done when you are able to do it.  Do that!

                      Alan

                      On Thu, Oct 25, 2012 at 3:38 AM, Gercel Silva <gercel@...> wrote:
                       

                      Hi folks,


                      What do you guys think about having a story that the team did not forecast to deliver in the Sprint Backlog just because the team 'might' have it done by the end of the Sprint? I've seen it happen recently and people say that the whole sprint is what is 'possible' and the goal should match only a subset of the stories in it, which the team is commited to deliver.

                      The burndown chart includes those 'extra stories' since the beginning and it is not uncommom that by the end of the sprint they are untouched. The sprint is considered sucessfull but the sprint backlog/burndown show that there is still work to be done (extra stories that go to the next sprint).

                      How would you advise people in this situation?

                      Regards,
                      Gercel Silva


                    • Adam Sroka
                      All good points. As Ron pointed out it is very advanced to be able to get to done quickly enough that worrying about how long it takes disappears. When you are
                      Message 10 of 24 , Oct 25, 2012
                      • 0 Attachment
                        All good points. 

                        As Ron pointed out it is very advanced to be able to get to done quickly enough that worrying about how long it takes disappears. When you are still struggling to get deliveries under two weeks it makes sense to pay closer attention. 

                        As a coach most of the teams I encounter initially aren't even delivering monthly yet, and rarely get things to a state I would call done in two weeks. In these circumstances they need the kind of discipline you are describing. 

                        However, I think it is important to know what others in the industry are achieving so that we can set or sights sufficiently high. I would find working as a team member on a product that deployed less than weekly to be painfully tedious. I would be far more likely to take them as a coaching client than join them. 

                        Once you are deploying daily or more I don't feel like maintaining a strict sprint boundary is very important (Other than having a regular cadence for getting together with folks outside the team.) While it's true that you wouldn't really be doing Scrum at this point, I don't think that really matters. Scrum isn't the end of the road. 

                        On Thu, Oct 25, 2012 at 2:30 PM, Alan Dayley <alandd@...> wrote:
                         

                        My advice:

                        This practice makes it look like the sprint is never successful, as Ron said.  Don't do that.

                        This practice makes it normal to carry over uncompleted stories straight into the next sprint.  This creates a feel of a treadmill instead of a rhythm of getting done regularly.  This also creates a feeling that not getting things done is OK.  Don't do that.

                        This practice redefines the acceptable amount of work as a quantity less than the possible amount of work.  Don't do that.

                        This practice can remove the transparency of seeing when work is blocked or regularly slower than it should be because it's OK to not get everything done. So some organizational, skill or other impediments will remain hidden.  Don't do that.

                        Instead, have a story or two on the Product Backlog ready to be worked on IF there is time in the sprint to get them done.  If there is time, pull it in and finish it.  Only put it on the Sprint Backlog and the Burndown at the time it gets pulled in, not before. This emphasizes how wonderful it is to get additional work done when you are able to do it.  Do that!

                        Alan


                        On Thu, Oct 25, 2012 at 3:38 AM, Gercel Silva <gercel@...> wrote:
                         

                        Hi folks,


                        What do you guys think about having a story that the team did not forecast to deliver in the Sprint Backlog just because the team 'might' have it done by the end of the Sprint? I've seen it happen recently and people say that the whole sprint is what is 'possible' and the goal should match only a subset of the stories in it, which the team is commited to deliver.

                        The burndown chart includes those 'extra stories' since the beginning and it is not uncommom that by the end of the sprint they are untouched. The sprint is considered sucessfull but the sprint backlog/burndown show that there is still work to be done (extra stories that go to the next sprint).

                        How would you advise people in this situation?

                        Regards,
                        Gercel Silva



                      • PAUL
                        Hi Alan, ... Great advice. This post made my smile. There are no hard and fast rules, do what ever makes you feel good. Clearing the decks and getting done
                        Message 11 of 24 , Oct 25, 2012
                        • 0 Attachment
                          Hi Alan,

                          >This emphasizes how wonderful it is
                          > to get additional work done when you are able to do it. Do that!
                          >

                          Great advice. This post made my smile. There are no hard and fast rules, do what ever makes you feel good.

                          Clearing the decks and getting done what I had planned feels good for me too...

                          Paul.


                          > Alan
                          >
                          > On Thu, Oct 25, 2012 at 3:38 AM, Gercel Silva <gercel@...> wrote:
                          >
                          > > **
                          > >
                          > >
                          > > Hi folks,
                          > >
                          > > What do you guys think about having a story that the team did not forecast
                          > > to deliver in the Sprint Backlog just because the team 'might' have it done
                          > > by the end of the Sprint? I've seen it happen recently and people say that
                          > > the whole sprint is what is 'possible' and the goal should match only a
                          > > subset of the stories in it, which the team is commited to deliver.
                          > >
                          > > The burndown chart includes those 'extra stories' since the beginning and
                          > > it is not uncommom that by the end of the sprint they are untouched. The
                          > > sprint is considered sucessfull but the sprint backlog/burndown show that
                          > > there is still work to be done (extra stories that go to the next sprint).
                          > >
                          > > How would you advise people in this situation?
                          > >
                          > > Regards,
                          > > Gercel Silva
                          > >
                          > >
                          > >
                          >
                        • Steve
                          Hi Kevin Your post implies that the selected stories always get don and that sometimes when we get finished early, we can take something else of the PB and
                          Message 12 of 24 , Oct 25, 2012
                          • 0 Attachment
                            Hi Kevin

                            Your post implies that the selected stories always get don and that sometimes when 'we' get finished early, 'we'can take something else of the PB and work on that.

                            Is the implication I take correct?

                            Does it never happen that all of the chosen stories are NOT completed in the Sprint?

                            --- In scrumdevelopment@yahoogroups.com, Kevin Callahan <kcallahan@...> wrote:
                            >
                            > Additional work can always be pulled in if needed. If a story is important enough that there is pressure to put it into the current sprint, then perhaps the backlog order is not accurately prioritized? Hard to know with such a thin slice of the situation...
                            >
                            > -kevin
                            >
                            > On Oct 25, 2012, at 4:35 PM, RonJeffries wrote:
                            >
                            > > Gercel,
                            > >
                            > > In Scrum, the team forecasts (or commits, if you prefer) to what they really expect to accomplish. Putting more than that on the backlog just makes success look like failure.
                            > > R
                            > > On Oct 25, 2012, at 6:38 AM, Gercel Silva <gercel@...> wrote:
                            > >
                            > >> What do you guys think about having a story that the team did not forecast to deliver in the Sprint Backlog just because the team 'might' have it done by the end of the Sprint? I've seen it happen recently and people say that the whole sprint is what is 'possible' and the goal should match only a subset of the stories in it, which the team is commited to deliver.
                            > >>
                            > >> The burndown chart includes those 'extra stories' since the beginning and it is not uncommom that by the end of the sprint they are untouched. The sprint is considered sucessfull but the sprint backlog/burndown show that there is still work to be done (extra stories that go to the next sprint).
                            > >>
                            > >> How would you advise people in this situation?
                            > >
                            > >
                            > > Ron Jeffries
                            > > www.XProgramming.com
                            > > Sometimes I give myself admirable advice, but I am incapable of taking it.
                            > > -- Mary Wortley Montagu
                            > >
                            > >
                            > >
                            > >
                            > >
                            >
                            >
                            > Kevin Callahan
                            > Scrum Master & Agile Coach
                            > LiveWorld Inc.
                            >
                            > Direct +1 (207) 691-2997
                            > Skype kevmocal
                            >
                            > Follow Us
                            >
                          • Kevin Callahan
                            Oh that would be a lovely world if true :) In the world of my teams, no, it s a moving target and sprints are frequently missed. I believe there are a lot of
                            Message 13 of 24 , Oct 25, 2012
                            • 0 Attachment
                              Oh that would be a lovely world if true :) In the world of my teams, no, it's a moving target and sprints are frequently missed. I believe there are a lot of reasons for this, some of them are more clear than others. 

                              Velocity is highly imperfect; the whole thing is a guessing game. In recent other threads Ron and some others had some excellent ideas of how to dial in the accuracy of what can likely be complete in a sprint, though that's again another *huge* topic ;)

                              I appreciate your checking the implication as that's certainly not what I was suggesting. To clarify, my point is that in the case when a team does complete work early, which most often I've seen when stories get carried into the next sprint and estimated velocity remains constant (whatever that really means), that when the committed work is complete the team pulls the next high priority item from the top of the product backlog into the sprint.

                              -kevin


                              On Oct 25, 2012, at 6:43 PM, Steve wrote:

                               

                              Hi Kevin

                              Your post implies that the selected stories always get don and that sometimes when 'we' get finished early, 'we'can take something else of the PB and work on that.

                              Is the implication I take correct?

                              Does it never happen that all of the chosen stories are NOT completed in the Sprint?

                              --- In scrumdevelopment@yahoogroups.com, Kevin Callahan <kcallahan@...> wrote:
                              >
                              > Additional work can always be pulled in if needed. If a story is important enough that there is pressure to put it into the current sprint, then perhaps the backlog order is not accurately prioritized? Hard to know with such a thin slice of the situation...
                              >
                              > -kevin
                              >
                              > On Oct 25, 2012, at 4:35 PM, RonJeffries wrote:
                              >
                              > > Gercel,
                              > >
                              > > In Scrum, the team forecasts (or commits, if you prefer) to what they really expect to accomplish. Putting more than that on the backlog just makes success look like failure.
                              > > R
                              > > On Oct 25, 2012, at 6:38 AM, Gercel Silva <gercel@...> wrote:
                              > >
                              > >> What do you guys think about having a story that the team did not forecast to deliver in the Sprint Backlog just because the team 'might' have it done by the end of the Sprint? I've seen it happen recently and people say that the whole sprint is what is 'possible' and the goal should match only a subset of the stories in it, which the team is commited to deliver.
                              > >>
                              > >> The burndown chart includes those 'extra stories' since the beginning and it is not uncommom that by the end of the sprint they are untouched. The sprint is considered sucessfull but the sprint backlog/burndown show that there is still work to be done (extra stories that go to the next sprint).
                              > >>
                              > >> How would you advise people in this situation?
                              > >
                              > >
                              > > Ron Jeffries
                              > > www.XProgramming.com
                              > > Sometimes I give myself admirable advice, but I am incapable of taking it.
                              > > -- Mary Wortley Montagu
                              > >
                              > >
                              > >
                              > >
                              > >
                              >
                              >
                              > Kevin Callahan
                              > Scrum Master & Agile Coach
                              > LiveWorld Inc.
                              >
                              > Direct +1 (207) 691-2997
                              > Skype kevmocal
                              >
                              > Follow Us
                              >


                              LiveWorld
                              Kevin Callahan
                              Scrum Master & Agile Coach
                              LiveWorld Inc.
                              Direct+1 (207) 691-2997
                              Skypekevmocal
                              Follow UsFacebook Twitter LinkedIn



                            • Alan Dayley
                              Thanks, Paul. Smiles are great! Alan
                              Message 14 of 24 , Oct 25, 2012
                              • 0 Attachment
                                Thanks, Paul.  Smiles are great!

                                Alan

                                On Thu, Oct 25, 2012 at 3:12 PM, PAUL <beckfordp@...> wrote:
                                 

                                Hi Alan,



                                >This emphasizes how wonderful it is
                                > to get additional work done when you are able to do it. Do that!
                                >

                                Great advice. This post made my smile. There are no hard and fast rules, do what ever makes you feel good.

                                Clearing the decks and getting done what I had planned feels good for me too...

                                Paul.

                                > Alan
                                >
                                > On Thu, Oct 25, 2012 at 3:38 AM, Gercel Silva <gercel@...> wrote:
                                >
                                > > **

                                > >
                                > >
                                > > Hi folks,
                                > >
                                > > What do you guys think about having a story that the team did not forecast
                                > > to deliver in the Sprint Backlog just because the team 'might' have it done
                                > > by the end of the Sprint? I've seen it happen recently and people say that
                                > > the whole sprint is what is 'possible' and the goal should match only a
                                > > subset of the stories in it, which the team is commited to deliver.
                                > >
                                > > The burndown chart includes those 'extra stories' since the beginning and
                                > > it is not uncommom that by the end of the sprint they are untouched. The
                                > > sprint is considered sucessfull but the sprint backlog/burndown show that
                                > > there is still work to be done (extra stories that go to the next sprint).
                                > >
                                > > How would you advise people in this situation?
                                > >
                                > > Regards,
                                > > Gercel Silva
                                > >
                                > >
                                > >
                                >


                              • Adam Sroka
                                ... And, of course, you are completely correct on that point.
                                Message 15 of 24 , Oct 25, 2012
                                • 0 Attachment
                                  On Thu, Oct 25, 2012 at 2:23 PM, RonJeffries <ronjeffries@...> wrote:
                                  >
                                  >
                                  >
                                  > Hi Adam,
                                  >
                                  >
                                  > On Oct 25, 2012, at 5:14 PM, Adam Sroka <adam.sroka@...> wrote:
                                  >
                                  > It is a very low ceremony kind of Kanban. Industrial Logic/Joshua Kerievsky recommend something similar and call it "Ultra Lean." However, during my time there we did something a bit more complex because the team membership was very dynamic from week to week.
                                  >
                                  >
                                  > Yes. My only point is that Scrum expects a commitment (or at least a forecast) of the work to be accomplished in a time-boxed Sprint.
                                  >

                                  And, of course, you are completely correct on that point.
                                • Steve
                                  I am confused about why commitment and forecast seem to be used as synonyms! If you commit to something and do not complete some aspect of that
                                  Message 16 of 24 , Oct 26, 2012
                                  • 0 Attachment
                                    I am confused about why 'commitment' and 'forecast' seem to be used as synonyms!

                                    If you 'commit' to something and do not complete some aspect of that commitment, you have failed; if you forecast something you are acknowledging that you do not have all the facts and that you may not complete some aspect of it.

                                    I can forecast the weather but even the UK Met Office only gets it right about 65% of the time!

                                    Even he latest Scrum Guide has replaced 'commit' with 'forecast'; they are not the same thing.

                                    --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
                                    >
                                    > On Thu, Oct 25, 2012 at 2:23 PM, RonJeffries <ronjeffries@...> wrote:
                                    > > It is a very low ceremony kind of Kanban. Industrial Logic/Joshua Kerievsky recommend something similar and call it "Ultra Lean." However, during my time there we did something a bit more complex because the team membership was very dynamic from week to week.
                                    > >
                                    > >
                                    > > Yes. My only point is that Scrum expects a commitment (or at least a forecast) of the work to be accomplished in a time-boxed Sprint.
                                    > >
                                    >
                                    > And, of course, you are completely correct on that point.
                                    >
                                  • RonJeffries
                                    Hello Steve, ... They are not used as synonyms. They are used at the same place in the sentence, depending on which you choose to use, namely forecasting or
                                    Message 17 of 24 , Oct 26, 2012
                                    • 0 Attachment
                                      Hello Steve,

                                      On Oct 26, 2012, at 5:46 AM, "Steve" <steve@...> wrote:

                                      I am confused about why 'commitment' and 'forecast' seem to be used as synonyms!
                                      [MOVED]: Even the latest Scrum Guide has replaced 'commit' with 'forecast'; they are not the same thing. 

                                      They are not used as synonyms. They are used at the same place in the sentence, depending on which you choose to use, namely forecasting or committing.

                                      If you 'commit' to something and do not complete some aspect of that commitment, you have failed;  if you forecast something you are acknowledging that you do not have all the facts and that you may not complete some aspect of it.

                                      That is the concern with the word "commit", namely that some people focus on succeed / fail kinds of thinking. The result of this is that teams who use commitment in the presence of succeed/fail thinking can become too focused on not "failing" and will cut corners so as to report that they are done. This leads to what is properly called shoddy work. The product will be tested less extensively than it needs or polished less than it needs. Often individuals on a team become less helpful lest "their own" work suffer.

                                      I can forecast the weather but even the UK Met Office only gets it right about 65% of the time!

                                      You have just nicely articulated the corresponding concern with the word "forecast", namely that some people become quite blasé about their forecasts, as if after all what the team gets done is like weather, pretty random and you never know what might blow in. Oddly, as far as I know, this relaxation of pressure does not seem to provide improved testing or better code. It does not seem to provide better teamwork.

                                      I imagine that the S.G. has switched from commit to forecast in hopes that it will result in less improper pressure not to "fail", and more understanding that no one really knows how much work will get done two weeks from now. Many of us still prefer the notion of commitment, because we believe that, used properly, it gives better results.

                                      My own views on this have changed and continue to change. More and more I favor a style of work where the team pulls items in when they are truly ready to work on them, and marks them as complete when they are truly complete. This is more of a continuous flow model, or a "Kanban" style of working. However, Scrum, as defined, follows more of a "batch" planning style, with a time boxed interval, the Sprint, where things are done at the end, but need not be done every day.

                                      The Sprint style may be easier to learn with, and in any case, if you're going to do Scrum, you need to work that way. The batch style is certainly not always best in the hands of a really effective team. I consider it an advanced approach for now. Proponents of other methods, such as Kanban System, think that the more continuous model is always better. I'm not convinced of that.
                                      Wisdom begins when we understand the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell

                                    • Cass Dalton
                                      I believe that replacement is on purpose. The term commitment is a hold over from the predictive waterfall world. As an emperical process, scrum know that
                                      Message 18 of 24 , Oct 26, 2012
                                      • 0 Attachment

                                        I believe that replacement is on purpose.  The term commitment is a hold over from the predictive waterfall world.  As an emperical process, scrum know that @$%! happens and even the best laid plans don't always go the way you expect.  So calling the work to be done a commitment implies that you can completely predict how much work is going to get done in a sprint.  Calling it a forecast is calling it what it is: your best educated guess at how much work will get done.  So you are right, they are not synonyms.  You are mistaken that everyone is actually using them as synonyms.  I think Ron's use of the terms together was a nod to the new vocabulary, and almost a poke at the fact that they are NOT synonyms and how that relates to the discussion.  If you still consider the assigned work to be done as a commitment, then "committing" to stretch goals will often lead to an appearance of failure even when the sprint was very successful.  This was, in fact, one of Ron's first points.

                                        On Oct 26, 2012 5:48 AM, "Steve" <steve@...> wrote:
                                         

                                        I am confused about why 'commitment' and 'forecast' seem to be used as synonyms!

                                        If you 'commit' to something and do not complete some aspect of that commitment, you have failed; if you forecast something you are acknowledging that you do not have all the facts and that you may not complete some aspect of it.

                                        I can forecast the weather but even the UK Met Office only gets it right about 65% of the time!

                                        Even he latest Scrum Guide has replaced 'commit' with 'forecast'; they are not the same thing.

                                        --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
                                        >
                                        > On Thu, Oct 25, 2012 at 2:23 PM, RonJeffries <ronjeffries@...> wrote:
                                        > > It is a very low ceremony kind of Kanban. Industrial Logic/Joshua Kerievsky recommend something similar and call it "Ultra Lean." However, during my time there we did something a bit more complex because the team membership was very dynamic from week to week.
                                        > >
                                        > >
                                        > > Yes. My only point is that Scrum expects a commitment (or at least a forecast) of the work to be accomplished in a time-boxed Sprint.
                                        > >
                                        >
                                        > And, of course, you are completely correct on that point.
                                        >

                                      • Steve
                                        Thank you Ron for your clarification; it the damned written word that caused my confusion; I tend to interpret things like ... forecast (commitment) ... as
                                        Message 19 of 24 , Oct 26, 2012
                                        • 0 Attachment
                                          Thank you Ron for your clarification; it the 'damned' written word that caused my confusion; I tend to interpret things like '... forecast (commitment) ...' as the writer meaning these words are synonyms.

                                          I agree with what you say may happen with forecast (people could get blase when they do not have a target to meet). That is why I always suggest that teams have a 'minimum' to be done, based on the Sprint Goal, that is about 60-65% of the total estimated work.

                                          I agree that a more continuous approach is probably more 'honest' (even within a development timeboxed environment such as Sprints) but how do you stop Stakeholders asking questions like 'What am I going to get by when?'.

                                          --- In scrumdevelopment@yahoogroups.com, RonJeffries <ronjeffries@...> wrote:
                                          >
                                          > Hello Steve,
                                          >
                                          > On Oct 26, 2012, at 5:46 AM, "Steve" <steve@...> wrote:
                                          >
                                          > > I am confused about why 'commitment' and 'forecast' seem to be used as synonyms!
                                          > > [MOVED]: Even the latest Scrum Guide has replaced 'commit' with 'forecast'; they are not the same thing.
                                          >
                                          > They are not used as synonyms. They are used at the same place in the sentence, depending on which you choose to use, namely forecasting or committing.
                                          > >
                                          > > If you 'commit' to something and do not complete some aspect of that commitment, you have failed; if you forecast something you are acknowledging that you do not have all the facts and that you may not complete some aspect of it.
                                          >
                                          > That is the concern with the word "commit", namely that some people focus on succeed / fail kinds of thinking. The result of this is that teams who use commitment in the presence of succeed/fail thinking can become too focused on not "failing" and will cut corners so as to report that they are done. This leads to what is properly called shoddy work. The product will be tested less extensively than it needs or polished less than it needs. Often individuals on a team become less helpful lest "their own" work suffer.
                                          > >
                                          > > I can forecast the weather but even the UK Met Office only gets it right about 65% of the time!
                                          >
                                          > You have just nicely articulated the corresponding concern with the word "forecast", namely that some people become quite blasé about their forecasts, as if after all what the team gets done is like weather, pretty random and you never know what might blow in. Oddly, as far as I know, this relaxation of pressure does not seem to provide improved testing or better code. It does not seem to provide better teamwork.
                                          >
                                          > I imagine that the S.G. has switched from commit to forecast in hopes that it will result in less improper pressure not to "fail", and more understanding that no one really knows how much work will get done two weeks from now. Many of us still prefer the notion of commitment, because we believe that, used properly, it gives better results.
                                          >
                                          > My own views on this have changed and continue to change. More and more I favor a style of work where the team pulls items in when they are truly ready to work on them, and marks them as complete when they are truly complete. This is more of a continuous flow model, or a "Kanban" style of working. However, Scrum, as defined, follows more of a "batch" planning style, with a time boxed interval, the Sprint, where things are done at the end, but need not be done every day.
                                          >
                                          > The Sprint style may be easier to learn with, and in any case, if you're going to do Scrum, you need to work that way. The batch style is certainly not always best in the hands of a really effective team. I consider it an advanced approach for now. Proponents of other methods, such as Kanban System, think that the more continuous model is always better. I'm not convinced of that.
                                          >
                                          > Ron Jeffries
                                          > www.XProgramming.com
                                          > Wisdom begins when we understand the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell
                                          >
                                        • Steve
                                          Hi Cass - thanks for the reply See my reply to Ron as to why I thought that people are using the words as synonyms. Those in the know could probabbly see
                                          Message 20 of 24 , Oct 26, 2012
                                          • 0 Attachment
                                            Hi Cass - thanks for the reply

                                            See my reply to Ron as to why I thought that people are using the words as synonyms.

                                            'Those in the know' could probabbly see 'Ron's poke'; I am concerned that there are many people not 'in the know' who read these posts who may consider that words in brackets are alternatives or synonyms and become confused.

                                            That was all the point of my post was.

                                            --- In scrumdevelopment@yahoogroups.com, Cass Dalton <cassdalton73@...> wrote:
                                            >
                                            > I believe that replacement is on purpose. The term commitment is a hold
                                            > over from the predictive waterfall world. As an emperical process, scrum
                                            > know that @$%! happens and even the best laid plans don't always go the way
                                            > you expect. So calling the work to be done a commitment implies that you
                                            > can completely predict how much work is going to get done in a sprint.
                                            > Calling it a forecast is calling it what it is: your best educated guess at
                                            > how much work will get done. So you are right, they are not synonyms. You
                                            > are mistaken that everyone is actually using them as synonyms. I think
                                            > Ron's use of the terms together was a nod to the new vocabulary, and almost
                                            > a poke at the fact that they are NOT synonyms and how that relates to the
                                            > discussion. If you still consider the assigned work to be done as a
                                            > commitment, then "committing" to stretch goals will often lead to an
                                            > appearance of failure even when the sprint was very successful. This was,
                                            > in fact, one of Ron's first points.
                                            > On Oct 26, 2012 5:48 AM, "Steve" <steve@...> wrote:
                                            >
                                            > > **
                                            > >
                                            > >
                                            > > I am confused about why 'commitment' and 'forecast' seem to be used as
                                            > > synonyms!
                                            > >
                                            > > If you 'commit' to something and do not complete some aspect of that
                                            > > commitment, you have failed; if you forecast something you are
                                            > > acknowledging that you do not have all the facts and that you may not
                                            > > complete some aspect of it.
                                            > >
                                            > > I can forecast the weather but even the UK Met Office only gets it right
                                            > > about 65% of the time!
                                            > >
                                            > > Even he latest Scrum Guide has replaced 'commit' with 'forecast'; they are
                                            > > not the same thing.
                                            > >
                                            > > --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@>
                                            > > wrote:
                                            > > >
                                            > > > On Thu, Oct 25, 2012 at 2:23 PM, RonJeffries <ronjeffries@> wrote:
                                            > > > > It is a very low ceremony kind of Kanban. Industrial Logic/Joshua
                                            > > Kerievsky recommend something similar and call it "Ultra Lean." However,
                                            > > during my time there we did something a bit more complex because the team
                                            > > membership was very dynamic from week to week.
                                            > > > >
                                            > > > >
                                            > > > > Yes. My only point is that Scrum expects a commitment (or at least a
                                            > > forecast) of the work to be accomplished in a time-boxed Sprint.
                                            > > > >
                                            > > >
                                            > > > And, of course, you are completely correct on that point.
                                            > > >
                                            > >
                                            > >
                                            > >
                                            >
                                          • PAUL
                                            Hi Cass, No you make a good point. Th problem with things like the Scrum Guide is they seldom say I don t know . They try to offer universal prescriptions
                                            Message 21 of 24 , Oct 26, 2012
                                            • 0 Attachment
                                              Hi Cass,

                                              No you make a good point. Th problem with things like the Scrum Guide is they seldom say "I don't know". They try to offer universal prescriptions where none exist.

                                              Like your question:

                                              >but how do you stop
                                              Stakeholders asking questions like 'What am I going to get by when?'.

                                              I don't know :) I've been at this over 20 years now and I still haven't worked out the answer to that one, and my guess is I never will ;)

                                              The serious point is that there are no hard and fast rules here. We are talking about open complex adaptive systems involving people, and people are anything but deterministic and predictable.

                                              There isn't one answer that will fit all teams at all times. You are better off relying on the underlying principles and values to come to a judgement, and of course your own common sense.

                                              Paul.




                                              --- In scrumdevelopment@yahoogroups.com, "Steve" <steve@...> wrote:
                                              >
                                              > Hi Cass - thanks for the reply
                                              >
                                              > See my reply to Ron as to why I thought that people are using the words as synonyms.
                                              >
                                              > 'Those in the know' could probabbly see 'Ron's poke'; I am concerned that there are many people not 'in the know' who read these posts who may consider that words in brackets are alternatives or synonyms and become confused.
                                              >
                                              > That was all the point of my post was.
                                              >
                                              > --- In scrumdevelopment@yahoogroups.com, Cass Dalton <cassdalton73@> wrote:
                                              > >
                                              > > I believe that replacement is on purpose. The term commitment is a hold
                                              > > over from the predictive waterfall world. As an emperical process, scrum
                                              > > know that @$%! happens and even the best laid plans don't always go the way
                                              > > you expect. So calling the work to be done a commitment implies that you
                                              > > can completely predict how much work is going to get done in a sprint.
                                              > > Calling it a forecast is calling it what it is: your best educated guess at
                                              > > how much work will get done. So you are right, they are not synonyms. You
                                              > > are mistaken that everyone is actually using them as synonyms. I think
                                              > > Ron's use of the terms together was a nod to the new vocabulary, and almost
                                              > > a poke at the fact that they are NOT synonyms and how that relates to the
                                              > > discussion. If you still consider the assigned work to be done as a
                                              > > commitment, then "committing" to stretch goals will often lead to an
                                              > > appearance of failure even when the sprint was very successful. This was,
                                              > > in fact, one of Ron's first points.
                                              > > On Oct 26, 2012 5:48 AM, "Steve" <steve@> wrote:
                                              > >
                                              > > > **
                                              > > >
                                              > > >
                                              > > > I am confused about why 'commitment' and 'forecast' seem to be used as
                                              > > > synonyms!
                                              > > >
                                              > > > If you 'commit' to something and do not complete some aspect of that
                                              > > > commitment, you have failed; if you forecast something you are
                                              > > > acknowledging that you do not have all the facts and that you may not
                                              > > > complete some aspect of it.
                                              > > >
                                              > > > I can forecast the weather but even the UK Met Office only gets it right
                                              > > > about 65% of the time!
                                              > > >
                                              > > > Even he latest Scrum Guide has replaced 'commit' with 'forecast'; they are
                                              > > > not the same thing.
                                              > > >
                                              > > > --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@>
                                              > > > wrote:
                                              > > > >
                                              > > > > On Thu, Oct 25, 2012 at 2:23 PM, RonJeffries <ronjeffries@> wrote:
                                              > > > > > It is a very low ceremony kind of Kanban. Industrial Logic/Joshua
                                              > > > Kerievsky recommend something similar and call it "Ultra Lean." However,
                                              > > > during my time there we did something a bit more complex because the team
                                              > > > membership was very dynamic from week to week.
                                              > > > > >
                                              > > > > >
                                              > > > > > Yes. My only point is that Scrum expects a commitment (or at least a
                                              > > > forecast) of the work to be accomplished in a time-boxed Sprint.
                                              > > > > >
                                              > > > >
                                              > > > > And, of course, you are completely correct on that point.
                                              > > > >
                                              > > >
                                              > > >
                                              > > >
                                              > >
                                              >
                                            • PAUL
                                              Sorry. I addressed this to Cass, I meant Steve of course. My apologies, Paul.
                                              Message 22 of 24 , Oct 26, 2012
                                              • 0 Attachment
                                                Sorry. I addressed this to Cass, I meant Steve of course.

                                                My apologies,

                                                Paul.
                                                --- In scrumdevelopment@yahoogroups.com, "PAUL" <beckfordp@...> wrote:
                                                >
                                                > Hi Cass,
                                                >
                                                > No you make a good point. Th problem with things like the Scrum Guide is they seldom say "I don't know". They try to offer universal prescriptions where none exist.
                                                >
                                                > Like your question:
                                                >
                                                > >but how do you stop
                                                > Stakeholders asking questions like 'What am I going to get by when?'.
                                                >
                                                > I don't know :) I've been at this over 20 years now and I still haven't worked out the answer to that one, and my guess is I never will ;)
                                                >
                                                > The serious point is that there are no hard and fast rules here. We are talking about open complex adaptive systems involving people, and people are anything but deterministic and predictable.
                                                >
                                                > There isn't one answer that will fit all teams at all times. You are better off relying on the underlying principles and values to come to a judgement, and of course your own common sense.
                                                >
                                                > Paul.
                                                >
                                                >
                                                >
                                                >
                                                > --- In scrumdevelopment@yahoogroups.com, "Steve" <steve@> wrote:
                                                > >
                                                > > Hi Cass - thanks for the reply
                                                > >
                                                > > See my reply to Ron as to why I thought that people are using the words as synonyms.
                                                > >
                                                > > 'Those in the know' could probabbly see 'Ron's poke'; I am concerned that there are many people not 'in the know' who read these posts who may consider that words in brackets are alternatives or synonyms and become confused.
                                                > >
                                                > > That was all the point of my post was.
                                                > >
                                                > > --- In scrumdevelopment@yahoogroups.com, Cass Dalton <cassdalton73@> wrote:
                                                > > >
                                                > > > I believe that replacement is on purpose. The term commitment is a hold
                                                > > > over from the predictive waterfall world. As an emperical process, scrum
                                                > > > know that @$%! happens and even the best laid plans don't always go the way
                                                > > > you expect. So calling the work to be done a commitment implies that you
                                                > > > can completely predict how much work is going to get done in a sprint.
                                                > > > Calling it a forecast is calling it what it is: your best educated guess at
                                                > > > how much work will get done. So you are right, they are not synonyms. You
                                                > > > are mistaken that everyone is actually using them as synonyms. I think
                                                > > > Ron's use of the terms together was a nod to the new vocabulary, and almost
                                                > > > a poke at the fact that they are NOT synonyms and how that relates to the
                                                > > > discussion. If you still consider the assigned work to be done as a
                                                > > > commitment, then "committing" to stretch goals will often lead to an
                                                > > > appearance of failure even when the sprint was very successful. This was,
                                                > > > in fact, one of Ron's first points.
                                                > > > On Oct 26, 2012 5:48 AM, "Steve" <steve@> wrote:
                                                > > >
                                                > > > > **
                                                > > > >
                                                > > > >
                                                > > > > I am confused about why 'commitment' and 'forecast' seem to be used as
                                                > > > > synonyms!
                                                > > > >
                                                > > > > If you 'commit' to something and do not complete some aspect of that
                                                > > > > commitment, you have failed; if you forecast something you are
                                                > > > > acknowledging that you do not have all the facts and that you may not
                                                > > > > complete some aspect of it.
                                                > > > >
                                                > > > > I can forecast the weather but even the UK Met Office only gets it right
                                                > > > > about 65% of the time!
                                                > > > >
                                                > > > > Even he latest Scrum Guide has replaced 'commit' with 'forecast'; they are
                                                > > > > not the same thing.
                                                > > > >
                                                > > > > --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@>
                                                > > > > wrote:
                                                > > > > >
                                                > > > > > On Thu, Oct 25, 2012 at 2:23 PM, RonJeffries <ronjeffries@> wrote:
                                                > > > > > > It is a very low ceremony kind of Kanban. Industrial Logic/Joshua
                                                > > > > Kerievsky recommend something similar and call it "Ultra Lean." However,
                                                > > > > during my time there we did something a bit more complex because the team
                                                > > > > membership was very dynamic from week to week.
                                                > > > > > >
                                                > > > > > >
                                                > > > > > > Yes. My only point is that Scrum expects a commitment (or at least a
                                                > > > > forecast) of the work to be accomplished in a time-boxed Sprint.
                                                > > > > > >
                                                > > > > >
                                                > > > > > And, of course, you are completely correct on that point.
                                                > > > > >
                                                > > > >
                                                > > > >
                                                > > > >
                                                > > >
                                                > >
                                                >
                                              • Gercel Silva
                                                Thank you very much for your insights. You hava all made good points. I think the situation I described is caused by a few misunderstandings about the
                                                Message 23 of 24 , Oct 29, 2012
                                                • 0 Attachment
                                                  Thank you very much for your insights. You hava all  made good points. I think the situation I described is caused by a few misunderstandings about the concepts of sprint backlog and sprint goal.

                                                  I agree that the goal can be met without actually finishing all stories in the sprint but that should be an exception, not the rule. What I've seen is that people intentionally set a goal that doesn't include all stories and add extra stories to have some space for unexpected delays or early delivery. Since there is no product backlog grooming, they feel that additional stories have to be discussed and planned during the sprint planning.

                                                  Gercel



                                                  On Fri, Oct 26, 2012 at 7:48 PM, PAUL <beckfordp@...> wrote:
                                                   


                                                  Sorry. I addressed this to Cass, I meant Steve of course.

                                                  My apologies,

                                                  Paul.


                                                  --- In scrumdevelopment@yahoogroups.com, "PAUL" <beckfordp@...> wrote:
                                                  >
                                                  > Hi Cass,
                                                  >
                                                  > No you make a good point. Th problem with things like the Scrum Guide is they seldom say "I don't know". They try to offer universal prescriptions where none exist.
                                                  >
                                                  > Like your question:
                                                  >
                                                  > >but how do you stop
                                                  > Stakeholders asking questions like 'What am I going to get by when?'.
                                                  >
                                                  > I don't know :) I've been at this over 20 years now and I still haven't worked out the answer to that one, and my guess is I never will ;)
                                                  >
                                                  > The serious point is that there are no hard and fast rules here. We are talking about open complex adaptive systems involving people, and people are anything but deterministic and predictable.
                                                  >
                                                  > There isn't one answer that will fit all teams at all times. You are better off relying on the underlying principles and values to come to a judgement, and of course your own common sense.
                                                  >
                                                  > Paul.
                                                  >
                                                  >
                                                  >
                                                  >
                                                  > --- In scrumdevelopment@yahoogroups.com, "Steve" <steve@> wrote:
                                                  > >
                                                  > > Hi Cass - thanks for the reply
                                                  > >
                                                  > > See my reply to Ron as to why I thought that people are using the words as synonyms.
                                                  > >
                                                  > > 'Those in the know' could probabbly see 'Ron's poke'; I am concerned that there are many people not 'in the know' who read these posts who may consider that words in brackets are alternatives or synonyms and become confused.
                                                  > >
                                                  > > That was all the point of my post was.
                                                  > >
                                                  > > --- In scrumdevelopment@yahoogroups.com, Cass Dalton <cassdalton73@> wrote:
                                                  > > >
                                                  > > > I believe that replacement is on purpose. The term commitment is a hold
                                                  > > > over from the predictive waterfall world. As an emperical process, scrum
                                                  > > > know that @$%! happens and even the best laid plans don't always go the way
                                                  > > > you expect. So calling the work to be done a commitment implies that you
                                                  > > > can completely predict how much work is going to get done in a sprint.
                                                  > > > Calling it a forecast is calling it what it is: your best educated guess at
                                                  > > > how much work will get done. So you are right, they are not synonyms. You
                                                  > > > are mistaken that everyone is actually using them as synonyms. I think
                                                  > > > Ron's use of the terms together was a nod to the new vocabulary, and almost
                                                  > > > a poke at the fact that they are NOT synonyms and how that relates to the
                                                  > > > discussion. If you still consider the assigned work to be done as a
                                                  > > > commitment, then "committing" to stretch goals will often lead to an
                                                  > > > appearance of failure even when the sprint was very successful. This was,
                                                  > > > in fact, one of Ron's first points.
                                                  > > > On Oct 26, 2012 5:48 AM, "Steve" <steve@> wrote:
                                                  > > >
                                                  > > > > **
                                                  > > > >
                                                  > > > >
                                                  > > > > I am confused about why 'commitment' and 'forecast' seem to be used as
                                                  > > > > synonyms!
                                                  > > > >
                                                  > > > > If you 'commit' to something and do not complete some aspect of that
                                                  > > > > commitment, you have failed; if you forecast something you are
                                                  > > > > acknowledging that you do not have all the facts and that you may not
                                                  > > > > complete some aspect of it.
                                                  > > > >
                                                  > > > > I can forecast the weather but even the UK Met Office only gets it right
                                                  > > > > about 65% of the time!
                                                  > > > >
                                                  > > > > Even he latest Scrum Guide has replaced 'commit' with 'forecast'; they are
                                                  > > > > not the same thing.
                                                  > > > >
                                                  > > > > --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@>
                                                  > > > > wrote:
                                                  > > > > >
                                                  > > > > > On Thu, Oct 25, 2012 at 2:23 PM, RonJeffries <ronjeffries@> wrote:
                                                  > > > > > > It is a very low ceremony kind of Kanban. Industrial Logic/Joshua
                                                  > > > > Kerievsky recommend something similar and call it "Ultra Lean." However,
                                                  > > > > during my time there we did something a bit more complex because the team
                                                  > > > > membership was very dynamic from week to week.
                                                  > > > > > >
                                                  > > > > > >
                                                  > > > > > > Yes. My only point is that Scrum expects a commitment (or at least a
                                                  > > > > forecast) of the work to be accomplished in a time-boxed Sprint.
                                                  > > > > > >
                                                  > > > > >
                                                  > > > > > And, of course, you are completely correct on that point.
                                                  > > > > >
                                                  > > > >
                                                  > > > >
                                                  > > > >
                                                  > > >
                                                  > >
                                                  >


                                                • JackM
                                                  What we do is we select buffer stories which we don t sign up for but if we finish ahead of time, we pull them in. But we don t add it to the burndown until we
                                                  Message 24 of 24 , Oct 29, 2012
                                                  • 0 Attachment
                                                    What we do is we select buffer stories which we don't sign up for but if we finish ahead of time, we pull them in.

                                                    But we don't add it to the burndown until we pull it in.

                                                    Hope this helps
                                                    Jack

                                                    www.agilebuddy.com
                                                    blog.agilebuddy.com

                                                    --- In scrumdevelopment@yahoogroups.com, Gercel Silva <gercel@...> wrote:
                                                    >
                                                    > Hi folks,
                                                    >
                                                    > What do you guys think about having a story that the team did not forecast
                                                    > to deliver in the Sprint Backlog just because the team 'might' have it done
                                                    > by the end of the Sprint? I've seen it happen recently and people say that
                                                    > the whole sprint is what is 'possible' and the goal should match only a
                                                    > subset of the stories in it, which the team is commited to deliver.
                                                    >
                                                    > The burndown chart includes those 'extra stories' since the beginning and
                                                    > it is not uncommom that by the end of the sprint they are untouched. The
                                                    > sprint is considered sucessfull but the sprint backlog/burndown show that
                                                    > there is still work to be done (extra stories that go to the next sprint).
                                                    >
                                                    > How would you advise people in this situation?
                                                    >
                                                    > Regards,
                                                    > Gercel Silva
                                                    >
                                                  Your message has been successfully submitted and would be delivered to recipients shortly.