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

Sprint Goal and user stories

Expand Messages
  • Gercel Silva
    Hi! Maybe you could help me understand something about how to use the sprint goal when the backlog is described with user stories. The Scrum Guide says: The
    Message 1 of 8 , Mar 12 4:50 PM
    • 0 Attachment
      Hi!
       
      Maybe you could help me understand something about how to use the sprint goal when the backlog is described with user stories. The Scrum Guide says:
       
       "The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint."
       
      I understand that the goal is crafted after the dev team has selected the functionality they forecast to deliver by the end of the sprint. I also understand that the team may negotiate with the PO the scope of the sprint backlog as they learn more about the product.
       
      Having said that, I have 3 questions:
       
      1) How often stories are added/removed from the sprint in the teams you work with?
       
      2) Should every story be linked to the sprint goal?
       
      3) How would you relate the sprint goal with the delivery of stories according to the definition of done?
       
      Regards
    • Jesse Houwing
      1) not really relevant 2) Preferably yes. Otherwise, what is the story doing in that sprint, as it doesn t serve the overall goal. A set of stories with a
      Message 2 of 8 , Mar 15 2:38 PM
      • 0 Attachment
        1) not really relevant
        2) Preferably yes. Otherwise, what is the story doing in that sprint, as it doesn't serve the overall goal. A set of stories with a common goal help to provide focus to the team and therefore reduce the amount of context switches.
        3) Sprint Goal and Definition of Done are unrelated. The Definition of Done requires that all user stories that are completed are actually completely done. All stories can be completed according to the DoD, but you might still not meet the sprint goal. Or you might only be able to finish 1 out of 3 stories and still meet the sprint goal. Whenever a sprint goal becomes obsolete, the sprint should be cancelled (should not happen often).

        Look at it like this, if the sprint goal is to enable user registration for your application, and you have a set of stories that are related to this goal, one allowing email registration and web registration. Then you would meet the goal when one of these stories is completed according to the definition of done. When the team cannot implement any of these scenarios in the sprint, but they might be able to provide a phone based registration system in the interim, then that solution would still fit the sprint goal and it can be proposed to the Product Owner as a viable solution.

        So where Sprint Goal provides direction to the team to keep them focussed, the DoD serves as a means to ensure high quality delivery.


        On Tue, Mar 12, 2013 at 5:50 PM, Gercel Silva <gercel@...> wrote:


        Hi!
         
        Maybe you could help me understand something about how to use the sprint goal when the backlog is described with user stories. The Scrum Guide says:
         
         "The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint."
         
        I understand that the goal is crafted after the dev team has selected the functionality they forecast to deliver by the end of the sprint. I also understand that the team may negotiate with the PO the scope of the sprint backlog as they learn more about the product.
         
        Having said that, I have 3 questions:
         
        1) How often stories are added/removed from the sprint in the teams you work with?
         
        2) Should every story be linked to the sprint goal?
         
        3) How would you relate the sprint goal with the delivery of stories according to the definition of done?
         
        Regards



      • Bob Boyd
        Hi Gercel, To answer your questions from one point of view: 1) How often stories are added/removed from the sprint in the teams you work with? In my experience
        Message 3 of 8 , Mar 15 4:24 PM
        • 0 Attachment
          Hi Gercel,

          To answer your questions from one point of view:

          1) How often stories are added/removed from the sprint in the teams you work with?

          In my experience this rarely happened after the team matured. In the beginning, the team tended to over-commit and stories would be removed. However, after a while they were better judging what they could do during the sprint and stories were rarely removed. Stories would generally only be added to a sprint if it was business critical. In this case a story would probably be removed or modified to make room.

          2) Should every story be linked to the sprint goal?

          This is not necessary and if done can make being flexible during the sprint hard. In our case, if a business critical story would be introduced and all stories were necessary to meet the goal, then the goal would likely be unachievable. However, if the goal is not too specific i.e., goal is negotiable, then this shouldn't present a problem.


          3) How would you relate the sprint goal with the delivery of stories according to the definition of done?

          I wouldn't think the sprint goal has any relationship with the definition of done; the definition of done being separate from the goals of the sprint. I think the goal is geared toward adding value for the customer rather than a technical definition.


          Bob Boyd


          --- In scrumdevelopment@yahoogroups.com, Gercel Silva <gercel@...> wrote:
          >
          > Hi!
          >
          > Maybe you could help me understand something about how to use the sprint
          > goal when the backlog is described with user stories. The Scrum Guide says:
          >
          > "The Sprint Goal gives the Development Team some flexibility regarding the
          > functionality implemented within the Sprint."
          >
          > I understand that the goal is crafted after the dev team has selected the
          > functionality they forecast to deliver by the end of the sprint. I also
          > understand that the team may negotiate with the PO the scope of the sprint
          > backlog as they learn more about the product.
          >
          > Having said that, I have 3 questions:
          >
          > 1) How often stories are added/removed from the sprint in the teams you
          > work with?
          >
          > 2) Should every story be linked to the sprint goal?
          >
          > 3) How would you relate the sprint goal with the delivery of stories
          > according to the definition of done?
          >
          > Regards
          >
        • Gercel Silva
          Jesse and Bob: thanks for taking the time to reply. I can see that the DoD should be a clear definition about what is expected of each story in terms of
          Message 4 of 8 , Mar 21 4:38 AM
          • 0 Attachment

            Jesse and Bob: thanks for taking the time to reply. I can see that the DoD should be a clear definition about what is expected of each story in terms of quality and is not related to the sprint goal. It should not change during a sprint but evolves as a team matures. The sprint goal and user stories however aren't supposed to be as rigid. Let's focus on those two:

            - Stories should be negotiable
            When does this negotiation take place? Only at the sprint planning or anytime along the sprint? What can change about a user story - its acceptance criteria maybe?

            - Goal should be flexible
            Should the goal be intentionally ambigous and remain unchanged? Or should it be written in terms of a minimum subset of the sprint backlog items that the team expects to deliver? I guess the sencond choice wouldn't be wise because a) the goal should be business-driven; and b) it takes away the team's freedom to self-organise and meet important business goals.

            Can you share your thoughs about that?

            Thanks!

             

             



            On Fri, Mar 15, 2013 at 8:24 PM, Bob Boyd <bobbatemansbay@...> wrote:
             



            Hi Gercel,

            To answer your questions from one point of view:



            1) How often stories are added/removed from the sprint in the teams you work with?

            In my experience this rarely happened after the team matured. In the beginning, the team tended to over-commit and stories would be removed. However, after a while they were better judging what they could do during the sprint and stories were rarely removed. Stories would generally only be added to a sprint if it was business critical. In this case a story would probably be removed or modified to make room.


            2) Should every story be linked to the sprint goal?

            This is not necessary and if done can make being flexible during the sprint hard. In our case, if a business critical story would be introduced and all stories were necessary to meet the goal, then the goal would likely be unachievable. However, if the goal is not too specific i.e., goal is negotiable, then this shouldn't present a problem.


            3) How would you relate the sprint goal with the delivery of stories according to the definition of done?

            I wouldn't think the sprint goal has any relationship with the definition of done; the definition of done being separate from the goals of the sprint. I think the goal is geared toward adding value for the customer rather than a technical definition.

            Bob Boyd


            --- In scrumdevelopment@yahoogroups.com, Gercel Silva <gercel@...> wrote:
            >
            > Hi!
            >
            > Maybe you could help me understand something about how to use the sprint
            > goal when the backlog is described with user stories. The Scrum Guide says:
            >
            > "The Sprint Goal gives the Development Team some flexibility regarding the
            > functionality implemented within the Sprint."
            >
            > I understand that the goal is crafted after the dev team has selected the
            > functionality they forecast to deliver by the end of the sprint. I also
            > understand that the team may negotiate with the PO the scope of the sprint
            > backlog as they learn more about the product.
            >
            > Having said that, I have 3 questions:
            >
            > 1) How often stories are added/removed from the sprint in the teams you
            > work with?
            >
            > 2) Should every story be linked to the sprint goal?
            >
            > 3) How would you relate the sprint goal with the delivery of stories
            > according to the definition of done?
            >
            > Regards
            >


          • Charles Bradley - Professional Scrum Trai
            Gercel, ... Only at sprint planning or anytime... Stories, not technically part of Scrum, but one of several ways to represent PBI s in Scrum, are always
            Message 5 of 8 , Mar 26 9:08 AM
            • 0 Attachment
              Gercel,

              > - Stories should be negotiable, When does this negotiation take place?
              Only at sprint planning or anytime...

              Stories, not technically part of Scrum, but one of several ways to represent PBI's in Scrum, are always negotiable in any aspect, up until the end of Sprint Planning.  After Sprint Planning, it gets a little bit trickier.  Scrum does not say anything terribly specific on this topic, so for that case, you might find this strategy useful:
              "One Way to Handle Mid-Sprint Scope Changes in Scrum"
              http://www.scrumcrazy.com/scope


              -------
              Charles Bradley
              Scrum Coach-in-Chief
              ScrumCrazy.com




              From: Gercel Silva <gercel@...>
              To: scrumdevelopment@yahoogroups.com
              Sent: Thursday, March 21, 2013 5:38 AM
              Subject: Re: [scrumdevelopment] Re: Sprint Goal and user stories



              Jesse and Bob: thanks for taking the time to reply. I can see that the DoD should be a clear definition about what is expected of each story in terms of quality and is not related to the sprint goal. It should not change during a sprint but evolves as a team matures. The sprint goal and user stories however aren't supposed to be as rigid. Let's focus on those two:
              - Stories should be negotiable
              When does this negotiation take place? Only at the sprint planning or anytime along the sprint? What can change about a user story - its acceptance criteria maybe?
              - Goal should be flexible
              Should the goal be intentionally ambigous and remain unchanged? Or should it be written in terms of a minimum subset of the sprint backlog items that the team expects to deliver? I guess the sencond choice wouldn't be wise because a) the goal should be business-driven; and b) it takes away the team's freedom to self-organise and meet important business goals.
              Can you share your thoughs about that?
              Thanks!
               
               


              On Fri, Mar 15, 2013 at 8:24 PM, Bob Boyd <bobbatemansbay@...> wrote:
               


              Hi Gercel,

              To answer your questions from one point of view:


              1) How often stories are added/removed from the sprint in the teams you work with?

              In my experience this rarely happened after the team matured. In the beginning, the team tended to over-commit and stories would be removed. However, after a while they were better judging what they could do during the sprint and stories were rarely removed. Stories would generally only be added to a sprint if it was business critical. In this case a story would probably be removed or modified to make room.


              2) Should every story be linked to the sprint goal?

              This is not necessary and if done can make being flexible during the sprint hard. In our case, if a business critical story would be introduced and all stories were necessary to meet the goal, then the goal would likely be unachievable. However, if the goal is not too specific i.e., goal is negotiable, then this shouldn't present a problem.


              3) How would you relate the sprint goal with the delivery of stories according to the definition of done?

              I wouldn't think the sprint goal has any relationship with the definition of done; the definition of done being separate from the goals of the sprint. I think the goal is geared toward adding value for the customer rather than a technical definition.

              Bob Boyd


              --- In scrumdevelopment@yahoogroups.com, Gercel Silva <gercel@...> wrote:
              >
              > Hi!
              >
              > Maybe you could help me understand something about how to use the sprint
              > goal when the backlog is described with user stories. The Scrum Guide says:
              >
              > "The Sprint Goal gives the Development Team some flexibility regarding the
              > functionality implemented within the Sprint."
              >
              > I understand that the goal is crafted after the dev team has selected the
              > functionality they forecast to deliver by the end of the sprint. I also
              > understand that the team may negotiate with the PO the scope of the sprint
              > backlog as they learn more about the product.
              >
              > Having said that, I have 3 questions:
              >
              > 1) How often stories are added/removed from the sprint in the teams you
              > work with?
              >
              > 2) Should every story be linked to the sprint goal?
              >
              > 3) How would you relate the sprint goal with the delivery of stories
              > according to the definition of done?
              >
              > Regards
              >






            • Wouter Lagerweij
              Hi Gercel, Stories should be negotiable, in that the way to get to a specific functionality can vary. If the team can deliver the business value in a simpler
              Message 6 of 8 , Mar 26 1:18 PM
              • 0 Attachment
                Hi Gercel,

                Stories should be negotiable, in that the way to get to a specific functionality can vary. If the team can deliver the business value in a simpler way, they should be able to discuss that with the product owner. Even if this is not exactly what he had in mind, he could prefer it because it would be cheaper to implement. Or the inverse: if could be  nicer way to get the functionality for not much more effort. If it's simpler, the more extensive/expensive version could be split off into a new story, that can then be separately prioritised.

                In general, this kind of negotiation will happen before the stories is taken into the sprint. Once in development, the story and acceptance criteria should not change. Especially the acceptance criteria, which are the best way to determine if a story is done.
                Of course, there can still be open questions during development, which can turn into negotiations. But those would be smaller items, that do not influence the defined acceptance criteria. Like 'does that button really have to be a different color from the rest?'.

                The sprint goal should give the team context so that they can make informed decisions about the work they're doing that sprint. Stories that don't directly contribute to the sprint goal are the first to consider dropping from scope should such a thing be necessary. Within stories that do contribute, the goal / why of the story is clear because it is in support of the sprint goal, and parts of the story that don't exhibit that support can be negotiated away. And if the PO is not available, the team can make decisions about these things on their own because the goal is clearly defined.

                Wouter


                On Thu, Mar 21, 2013 at 12:38 PM, Gercel Silva <gercel@...> wrote:
                 

                Jesse and Bob: thanks for taking the time to reply. I can see that the DoD should be a clear definition about what is expected of each story in terms of quality and is not related to the sprint goal. It should not change during a sprint but evolves as a team matures. The sprint goal and user stories however aren't supposed to be as rigid. Let's focus on those two:

                - Stories should be negotiable
                When does this negotiation take place? Only at the sprint planning or anytime along the sprint? What can change about a user story - its acceptance criteria maybe?

                - Goal should be flexible
                Should the goal be intentionally ambigous and remain unchanged? Or should it be written in terms of a minimum subset of the sprint backlog items that the team expects to deliver? I guess the sencond choice wouldn't be wise because a) the goal should be business-driven; and b) it takes away the team's freedom to self-organise and meet important business goals.

                Can you share your thoughs about that?

                Thanks!

                 

                 



                On Fri, Mar 15, 2013 at 8:24 PM, Bob Boyd <bobbatemansbay@...> wrote:
                 



                Hi Gercel,

                To answer your questions from one point of view:



                1) How often stories are added/removed from the sprint in the teams you work with?

                In my experience this rarely happened after the team matured. In the beginning, the team tended to over-commit and stories would be removed. However, after a while they were better judging what they could do during the sprint and stories were rarely removed. Stories would generally only be added to a sprint if it was business critical. In this case a story would probably be removed or modified to make room.


                2) Should every story be linked to the sprint goal?

                This is not necessary and if done can make being flexible during the sprint hard. In our case, if a business critical story would be introduced and all stories were necessary to meet the goal, then the goal would likely be unachievable. However, if the goal is not too specific i.e., goal is negotiable, then this shouldn't present a problem.


                3) How would you relate the sprint goal with the delivery of stories according to the definition of done?

                I wouldn't think the sprint goal has any relationship with the definition of done; the definition of done being separate from the goals of the sprint. I think the goal is geared toward adding value for the customer rather than a technical definition.

                Bob Boyd


                --- In scrumdevelopment@yahoogroups.com, Gercel Silva <gercel@...> wrote:
                >
                > Hi!
                >
                > Maybe you could help me understand something about how to use the sprint
                > goal when the backlog is described with user stories. The Scrum Guide says:
                >
                > "The Sprint Goal gives the Development Team some flexibility regarding the
                > functionality implemented within the Sprint."
                >
                > I understand that the goal is crafted after the dev team has selected the
                > functionality they forecast to deliver by the end of the sprint. I also
                > understand that the team may negotiate with the PO the scope of the sprint
                > backlog as they learn more about the product.
                >
                > Having said that, I have 3 questions:
                >
                > 1) How often stories are added/removed from the sprint in the teams you
                > work with?
                >
                > 2) Should every story be linked to the sprint goal?
                >
                > 3) How would you relate the sprint goal with the delivery of stories
                > according to the definition of done?
                >
                > Regards
                >





                --
                Wouter Lagerweij         | wouter@...
              • Jim
                @Wouter - Well said. I appreciate and echo the value of the sprint goal(s) for the very reasons you stated. One very challenging team I led, together with
                Message 7 of 8 , Mar 26 3:40 PM
                • 0 Attachment
                  @Wouter - Well said. I appreciate and echo the value of the sprint goal(s) for the very reasons you stated.

                  One very challenging team I led, together with their functional/resource manager, [both] told me they thought the stories making up the sprint commitment(plan) were [alone] good enough to serve as the sprint "goal(s)", and having a contextual business goal was redundant. I nearly bit my tongue completely off on this team!

                  I appreciate how you present the decision-guiding value of the sprint goal at eliminating wasteful wait time navigating the small negotiables, as well as sprint scoping and perhaps even story swapping, during the sprint in the PO's absence. Kudos. Thank you!!

                  Having said all this, do you feel the measure of the sprint goal value is respective to the team's agile-maturity? i.e., the lower the maturity, the higher its value? Or is its inherent value irrespective of how disciplined the team is with agile/scrum?

                  Thanks,
                  JimBo

                  --- In scrumdevelopment@yahoogroups.com, Wouter Lagerweij <wouter@...> wrote:
                  >
                  > Hi Gercel,
                  >
                  > Stories should be negotiable, in that the way to get to a specific
                  > functionality can vary. If the team can deliver the business value in a
                  > simpler way, they should be able to discuss that with the product owner.
                  > Even if this is not exactly what he had in mind, he could prefer it because
                  > it would be cheaper to implement. Or the inverse: if could be nicer way to
                  > get the functionality for not much more effort. If it's simpler, the more
                  > extensive/expensive version could be split off into a new story, that can
                  > then be separately prioritised.
                  >
                  > In general, this kind of negotiation will happen before the stories is
                  > taken into the sprint. Once in development, the story and acceptance
                  > criteria should not change. Especially the acceptance criteria, which are
                  > the best way to determine if a story is done.
                  > Of course, there can still be open questions during development, which can
                  > turn into negotiations. But those would be smaller items, that do not
                  > influence the defined acceptance criteria. Like 'does that button really
                  > have to be a different color from the rest?'.
                  >
                  > The sprint goal should give the team context so that they can make informed
                  > decisions about the work they're doing that sprint. Stories that don't
                  > directly contribute to the sprint goal are the first to consider dropping
                  > from scope should such a thing be necessary. Within stories that do
                  > contribute, the goal / why of the story is clear because it is in support
                  > of the sprint goal, and parts of the story that don't exhibit that support
                  > can be negotiated away. And if the PO is not available, the team can make
                  > decisions about these things on their own because the goal is clearly
                  > defined.
                  >
                  > Wouter
                  >
                  >
                  > On Thu, Mar 21, 2013 at 12:38 PM, Gercel Silva <gercel@...> wrote:
                  >
                  > > **
                  > >
                  > >
                  > > Jesse and Bob: thanks for taking the time to reply. I can see that the DoD
                  > > should be a clear definition about what is expected of each story in terms
                  > > of quality and is not related to the sprint goal. It should not change
                  > > during a sprint but evolves as a team matures. The sprint goal and user
                  > > stories however aren't supposed to be as rigid. Let's focus on those two:
                  > >
                  > > - Stories should be negotiable
                  > > When does this negotiation take place? Only at the sprint planning or
                  > > anytime along the sprint? What can change about a user story - its
                  > > acceptance criteria maybe?
                  > > - Goal should be flexible
                  > > Should the goal be intentionally ambigous and remain unchanged? Or should
                  > > it be written in terms of a minimum subset of the sprint backlog items that
                  > > the team expects to deliver? I guess the sencond choice wouldn't be wise
                  > > because a) the goal should be business-driven; and b) it takes away the
                  > > team's freedom to self-organise and meet important business goals.
                  > >
                  > > Can you share your thoughs about that?
                  > >
                  > > Thanks!
                  > >
                  > >
                  > >
                  > >
                  > >
                  > >
                  > > On Fri, Mar 15, 2013 at 8:24 PM, Bob Boyd <bobbatemansbay@...>wrote:
                  > >
                  > >> **
                  > >>
                  > >>
                  > >>
                  > >>
                  > >> Hi Gercel,
                  > >>
                  > >> To answer your questions from one point of view:
                  > >>
                  > >>
                  > >> 1) How often stories are added/removed from the sprint in the teams you
                  > >> work with?
                  > >>
                  > >> In my experience this rarely happened after the team matured. In the
                  > >> beginning, the team tended to over-commit and stories would be removed.
                  > >> However, after a while they were better judging what they could do during
                  > >> the sprint and stories were rarely removed. Stories would generally only be
                  > >> added to a sprint if it was business critical. In this case a story would
                  > >> probably be removed or modified to make room.
                  > >>
                  > >>
                  > >> 2) Should every story be linked to the sprint goal?
                  > >>
                  > >> This is not necessary and if done can make being flexible during the
                  > >> sprint hard. In our case, if a business critical story would be introduced
                  > >> and all stories were necessary to meet the goal, then the goal would likely
                  > >> be unachievable. However, if the goal is not too specific i.e., goal is
                  > >> negotiable, then this shouldn't present a problem.
                  > >>
                  > >>
                  > >> 3) How would you relate the sprint goal with the delivery of stories
                  > >> according to the definition of done?
                  > >>
                  > >> I wouldn't think the sprint goal has any relationship with the definition
                  > >> of done; the definition of done being separate from the goals of the
                  > >> sprint. I think the goal is geared toward adding value for the customer
                  > >> rather than a technical definition.
                  > >>
                  > >> Bob Boyd
                  > >>
                  > >>
                  > >> --- In scrumdevelopment@yahoogroups.com, Gercel Silva <gercel@> wrote:
                  > >> >
                  > >> > Hi!
                  > >> >
                  > >> > Maybe you could help me understand something about how to use the sprint
                  > >> > goal when the backlog is described with user stories. The Scrum Guide
                  > >> says:
                  > >> >
                  > >> > "The Sprint Goal gives the Development Team some flexibility regarding
                  > >> the
                  > >> > functionality implemented within the Sprint."
                  > >> >
                  > >> > I understand that the goal is crafted after the dev team has selected
                  > >> the
                  > >> > functionality they forecast to deliver by the end of the sprint. I also
                  > >> > understand that the team may negotiate with the PO the scope of the
                  > >> sprint
                  > >> > backlog as they learn more about the product.
                  > >> >
                  > >> > Having said that, I have 3 questions:
                  > >> >
                  > >> > 1) How often stories are added/removed from the sprint in the teams you
                  > >> > work with?
                  > >> >
                  > >> > 2) Should every story be linked to the sprint goal?
                  > >> >
                  > >> > 3) How would you relate the sprint goal with the delivery of stories
                  > >> > according to the definition of done?
                  > >> >
                  > >> > Regards
                  > >> >
                  > >>
                  > >>
                  > >
                  > >
                  >
                  >
                  >
                  > --
                  > Wouter Lagerweij | wouter@...
                  > http://www.lagerweij.com | @wouterla <http://twitter.com/#!/wouterla>
                  >
                • Wouter Lagerweij
                  Hi Jim, Thanks for the kind words! Interesting question: I actually have not been very successful using sprint goals in teams with lower maturity. It s been
                  Message 8 of 8 , Apr 1, 2013
                  • 0 Attachment
                    Hi Jim,

                    Thanks for the kind words!

                    Interesting question: I actually have not been very successful using sprint goals in teams with lower maturity. It's been much easier for me later in a team's development to be effective with that. I hadn't considered this before, but maybe that is logical: the ability for a team to make business value based decisions can be one of the main advantages of agile, as Ron Jeffries just reminded me of in another thread ( https://groups.google.com/d/msg/scrumalliance/f63R9t3H9YI/JT8yaH8RyiEJ ). 

                    Or maybe it's my lack of persuasiveness:-)

                    Wouter



                    On Tue, Mar 26, 2013 at 11:40 PM, Jim <jb.rice@...> wrote:
                     

                    @Wouter - Well said. I appreciate and echo the value of the sprint goal(s) for the very reasons you stated.

                    One very challenging team I led, together with their functional/resource manager, [both] told me they thought the stories making up the sprint commitment(plan) were [alone] good enough to serve as the sprint "goal(s)", and having a contextual business goal was redundant. I nearly bit my tongue completely off on this team!

                    I appreciate how you present the decision-guiding value of the sprint goal at eliminating wasteful wait time navigating the small negotiables, as well as sprint scoping and perhaps even story swapping, during the sprint in the PO's absence. Kudos. Thank you!!

                    Having said all this, do you feel the measure of the sprint goal value is respective to the team's agile-maturity? i.e., the lower the maturity, the higher its value? Or is its inherent value irrespective of how disciplined the team is with agile/scrum?

                    Thanks,
                    JimBo


                    --- In scrumdevelopment@yahoogroups.com, Wouter Lagerweij <wouter@...> wrote:
                    >
                    > Hi Gercel,
                    >
                    > Stories should be negotiable, in that the way to get to a specific
                    > functionality can vary. If the team can deliver the business value in a
                    > simpler way, they should be able to discuss that with the product owner.
                    > Even if this is not exactly what he had in mind, he could prefer it because
                    > it would be cheaper to implement. Or the inverse: if could be nicer way to
                    > get the functionality for not much more effort. If it's simpler, the more
                    > extensive/expensive version could be split off into a new story, that can
                    > then be separately prioritised.
                    >
                    > In general, this kind of negotiation will happen before the stories is
                    > taken into the sprint. Once in development, the story and acceptance
                    > criteria should not change. Especially the acceptance criteria, which are
                    > the best way to determine if a story is done.
                    > Of course, there can still be open questions during development, which can
                    > turn into negotiations. But those would be smaller items, that do not
                    > influence the defined acceptance criteria. Like 'does that button really
                    > have to be a different color from the rest?'.
                    >
                    > The sprint goal should give the team context so that they can make informed
                    > decisions about the work they're doing that sprint. Stories that don't
                    > directly contribute to the sprint goal are the first to consider dropping
                    > from scope should such a thing be necessary. Within stories that do
                    > contribute, the goal / why of the story is clear because it is in support
                    > of the sprint goal, and parts of the story that don't exhibit that support
                    > can be negotiated away. And if the PO is not available, the team can make
                    > decisions about these things on their own because the goal is clearly
                    > defined.
                    >
                    > Wouter
                    >
                    >
                    > On Thu, Mar 21, 2013 at 12:38 PM, Gercel Silva <gercel@...> wrote:
                    >
                    > > **

                    > >
                    > >
                    > > Jesse and Bob: thanks for taking the time to reply. I can see that the DoD
                    > > should be a clear definition about what is expected of each story in terms
                    > > of quality and is not related to the sprint goal. It should not change
                    > > during a sprint but evolves as a team matures. The sprint goal and user
                    > > stories however aren't supposed to be as rigid. Let's focus on those two:
                    > >
                    > > - Stories should be negotiable
                    > > When does this negotiation take place? Only at the sprint planning or
                    > > anytime along the sprint? What can change about a user story - its
                    > > acceptance criteria maybe?
                    > > - Goal should be flexible
                    > > Should the goal be intentionally ambigous and remain unchanged? Or should
                    > > it be written in terms of a minimum subset of the sprint backlog items that
                    > > the team expects to deliver? I guess the sencond choice wouldn't be wise
                    > > because a) the goal should be business-driven; and b) it takes away the
                    > > team's freedom to self-organise and meet important business goals.
                    > >
                    > > Can you share your thoughs about that?
                    > >
                    > > Thanks!
                    > >
                    > >
                    > >
                    > >
                    > >
                    > >
                    > > On Fri, Mar 15, 2013 at 8:24 PM, Bob Boyd <bobbatemansbay@...>wrote:
                    > >
                    > >> **

                    > >>
                    > >>
                    > >>
                    > >>
                    > >> Hi Gercel,
                    > >>
                    > >> To answer your questions from one point of view:
                    > >>
                    > >>
                    > >> 1) How often stories are added/removed from the sprint in the teams you
                    > >> work with?
                    > >>
                    > >> In my experience this rarely happened after the team matured. In the
                    > >> beginning, the team tended to over-commit and stories would be removed.
                    > >> However, after a while they were better judging what they could do during
                    > >> the sprint and stories were rarely removed. Stories would generally only be
                    > >> added to a sprint if it was business critical. In this case a story would
                    > >> probably be removed or modified to make room.
                    > >>
                    > >>
                    > >> 2) Should every story be linked to the sprint goal?
                    > >>
                    > >> This is not necessary and if done can make being flexible during the
                    > >> sprint hard. In our case, if a business critical story would be introduced
                    > >> and all stories were necessary to meet the goal, then the goal would likely
                    > >> be unachievable. However, if the goal is not too specific i.e., goal is
                    > >> negotiable, then this shouldn't present a problem.
                    > >>
                    > >>
                    > >> 3) How would you relate the sprint goal with the delivery of stories
                    > >> according to the definition of done?
                    > >>
                    > >> I wouldn't think the sprint goal has any relationship with the definition
                    > >> of done; the definition of done being separate from the goals of the
                    > >> sprint. I think the goal is geared toward adding value for the customer
                    > >> rather than a technical definition.
                    > >>
                    > >> Bob Boyd
                    > >>
                    > >>
                    > >> --- In scrumdevelopment@yahoogroups.com, Gercel Silva <gercel@> wrote:
                    > >> >
                    > >> > Hi!
                    > >> >
                    > >> > Maybe you could help me understand something about how to use the sprint
                    > >> > goal when the backlog is described with user stories. The Scrum Guide
                    > >> says:
                    > >> >
                    > >> > "The Sprint Goal gives the Development Team some flexibility regarding
                    > >> the
                    > >> > functionality implemented within the Sprint."
                    > >> >
                    > >> > I understand that the goal is crafted after the dev team has selected
                    > >> the
                    > >> > functionality they forecast to deliver by the end of the sprint. I also
                    > >> > understand that the team may negotiate with the PO the scope of the
                    > >> sprint
                    > >> > backlog as they learn more about the product.
                    > >> >
                    > >> > Having said that, I have 3 questions:
                    > >> >
                    > >> > 1) How often stories are added/removed from the sprint in the teams you
                    > >> > work with?
                    > >> >
                    > >> > 2) Should every story be linked to the sprint goal?
                    > >> >
                    > >> > 3) How would you relate the sprint goal with the delivery of stories
                    > >> > according to the definition of done?
                    > >> >
                    > >> > Regards
                    > >> >
                    > >>
                    > >>
                    > >
                    > >
                    >
                    >
                    >
                    > --
                    > Wouter Lagerweij | wouter@...
                    > http://www.lagerweij.com | @wouterla <http://twitter.com/#!/wouterla>
                    >




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