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

Re: Sprint Goal and user stories

Expand Messages
  • 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 1 of 8 , Mar 26, 2013
    View Source
    • 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 2 of 8 , Apr 1 2:00 PM
      View Source
      • 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.