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

56698Re: [scrumdevelopment] Re: Sprint Goal and user stories

Expand Messages
  • Wouter Lagerweij
    Mar 26, 2013
      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.


      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?




      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@...
    • Show all 8 messages in this topic