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

Sprint Goals Do you use them? Do you make them work?

Expand Messages
  • Mark Levison
    One bit of Scrum that has never really sat well in my gut is the Sprint Goal: The Scrum Guide says: “*The reason for having a Sprint Goal is to give the Team
    Message 1 of 5 , Sep 26, 2010
    • 0 Attachment
      One bit of Scrum that has never really sat well in my gut is the Sprint Goal:

      The Scrum Guide says: “The reason for having a Sprint Goal is to give the Team some wiggle room regarding the functionality. For example, the goal for the above Sprint could also be: “Automate the client account modification functionality through a secure, recoverable transaction middleware capability.” As the Team works, it keeps this goal in mind. In order to satisfy the goal, it implements the functionality and technology. If the work turns out to be harder than the Team had expected, then the Team collaborates with the Product Owner and only partially implement the functionality.”

      My issues are two fold: If the PO’s needs for a given sprint are a series of disparate user stories, I don’t see how we can create a real sprint goal. The reason states “to give the Team some wiggle room”. If the team needs wiggle room they should talk to the PO and decide together what can be dropped.

      In discussions with someone else since it been suggested that Sprint Goals have other benefits:
      • Goals are what teams really commit to, if you miss couple of stories but hit the goal then things have gone well. However if you miss the goal but hit all the stories then the you've failed.
      • Goals provide a focus and something more than just a bucket of stories to energize the team.
      • Goals provide the team with another subtle pressure to self organize
      While I agree that Goals are very useful in terms of motivating people I've always found the overall product vision to be enough at the high level and the stories themselves sprint by sprint.

      So I'm interested do you use Sprint Goals successfully? Do you derive the benefit? If so how do you create a good sprint goal when the highest priority stories aren't really related to each other?

      Cheers
      Mark Levison

      Blog | Twitter | Office: (613) 862-2538

    • George Dinwiddie
      Hi, Mark, ... Yes, I ve seen Sprint Goals used to good effect, as it reminds people of the /intent/ of the work rather than just the details of the
      Message 2 of 5 , Sep 26, 2010
      • 0 Attachment
        Hi, Mark,

        On 9/26/10 9:34 AM, Mark Levison wrote:
        >
        >
        > One bit of Scrum that has never really sat well in my gut is the Sprint
        > Goal:
        >
        > The Scrum Guide says: “/The reason for having a Sprint Goal is to give
        > the Team some wiggle room regarding the functionality. For example, the
        > goal for the above Sprint could also be: “Automate the client account
        > modification functionality through a secure, recoverable transaction
        > middleware capability.” As the Team works, it keeps this goal in mind.
        > In order to satisfy the goal, it implements the functionality and
        > technology. If the work turns out to be harder than the Team had
        > expected, then the Team collaborates with the Product Owner and only
        > partially implement the functionality/.”

        Yes, I've seen Sprint Goals used to good effect, as it reminds people of
        the /intent/ of the work rather than just the details of the
        functionality specified by the story.

        > My issues are two fold: If the PO’s needs for a given sprint are a
        > series of disparate user stories, I don’t see how we can create a real
        > sprint goal.

        That's true, and that's often an impediment to having a sprint goal. If
        the PO has no unified intent for the sprint, then the only goal is "do
        some more work." Often there's nothing that can immediately be done
        about that.

        But when I have clients in that situation, I suggest that they take a
        step back and look at the bigger picture. Often in these cases, the PO
        isn't really the PO and doesn't have the authority to direct the work.
        They're just relaying instructions. The fact that they can't see
        unifying goals in the work is an indicator of that. When this is true,
        I think it's beneficial if the PO-proxy works a little harder at
        understanding the intent of the PO (sometimes still a proxy) above them.

        > The reason states “to give the Team some wiggle room”. If
        > the team needs wiggle room they should talk to the PO and decide
        > together what can be dropped.

        Yes, the PO is part of the team, in my opinion. Sometimes the use of
        "team" is confusing in Scrum literature, and sometimes orgs don't really
        support teaming, particularly across caste lines. But if you treat the
        PO as part of the team, then they do have wiggle room. "How can we
        accomplish our goal even though we can't accomplish all of the stories
        we thought would be appropriate to accomplish the goal?" To use the
        example you quote from the Scrum Guide, perhaps we drop the "middleware"
        part and just implement some simple transactional support. Maybe we'll
        do some research in the future to look for different middleware products
        to find one we can use for our needs.

        > In discussions with someone else since it been suggested that Sprint
        > Goals have other benefits:
        >
        > * Goals are what teams really commit to, if you miss couple of
        > stories but hit the goal then things have gone well. However if
        > you miss the goal but hit all the stories then the you've failed.
        > * Goals provide a focus and something more than just a bucket of
        > stories to energize the team.
        > * Goals provide the team with another subtle pressure to self organize
        >
        > While I agree that Goals are very useful in terms of motivating people
        > I've always found the overall product vision to be enough at the high
        > level and the stories themselves sprint by sprint.

        If the overall product vision is small enough, that may be true.
        Sometimes it's helpful to break it down into smaller visions.

        > So I'm interested do you use Sprint Goals successfully? Do you derive
        > the benefit? If so how do you create a good sprint goal when the highest
        > priority stories aren't really related to each other?

        Perhaps you can describe a situation where the highest priority stories
        aren't really related to each other. It strikes me that, if they're
        really the highest priority, then each story must be a complete goal.
        This could indicate small goals or big stories.

        Another possibility, and one I've seen often, that that they're not
        really the highest priority stories. Instead, they're the highest
        priority story for each of several features, and the team is working on
        multiple features in parallel. Sometimes this is because the team
        doesn't know how to work collaboratively enough to all work on the same
        feature simultaneously. Sometimes it's because the PO has made promises
        to several stakeholders and wants to "show progress" on all of them,
        even though this delays the delivery of the first one.

        Perhaps it's the best this team (including the nominated PO) can do
        given their current knowledge and skill and organizational environment,
        but I don't think it's the best they can possibly do. Sprint goals are
        a tool to help them transcend such a situation.

        - George

        --
        ----------------------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------------------
      • Peter Stevens (calendar)
        Hi Mark, I think P-O s should should be setting a sprint goal every sprint. The more I dig into it, the more I am convinced that Scrum is introducing a form of
        Message 3 of 5 , Sep 26, 2010
        • 0 Attachment
          Hi Mark,

          I think P-O's should should be setting a sprint goal every sprint.

          The more I dig into it, the more I am convinced that Scrum is introducing a form of military leadership into civilian companies. Military authors distinguish between two forms of command and control: Directive command and control and Mission command and control.

          The former is what is it commonly referred to as 'Command and Control' in agile circles. Essentially 'do what I tell you to do and do it the way I told you to do it'. The latter is about defining goals, communicating the purpose and letting the unit figure out a) how to best achieve the goal and b) if the original goal cannot be achieve, go out and achieve the next best thing. This is called commander's intent.

          The military has been aware that Mission works better than Directive since at least the 1930s. Jeff Sutherland was an Air Force pilot and my understanding is that Ken Schwaber was a US Marine, so both of them understand these leadership principles quite well.

          Why set a goal? So the team has context and an understanding of the goal so they can do Plan A well and work out a plan B to achieve the P-O's intent if Plan A doesn't work out as intended.

          Here in Switzerland, where many/most senior managers also have military background, explaining Scrum based on analogies to military leadership has proved an excellent way to get their attention.

          Cheers,

          Peter



          On 26.09.10 15:34, Mark Levison wrote:  

          One bit of Scrum that has never really sat well in my gut is the Sprint Goal:

          The Scrum Guide says: “The reason for having a Sprint Goal is to give the Team some wiggle room regarding the functionality. For example, the goal for the above Sprint could also be: “Automate the client account modification functionality through a secure, recoverable transaction middleware capability.” As the Team works, it keeps this goal in mind. In order to satisfy the goal, it implements the functionality and technology. If the work turns out to be harder than the Team had expected, then the Team collaborates with the Product Owner and only partially implement the functionality.”

          My issues are two fold: If the PO’s needs for a given sprint are a series of disparate user stories, I don’t see how we can create a real sprint goal. The reason states “to give the Team some wiggle room”. If the team needs wiggle room they should talk to the PO and decide together what can be dropped.

          In discussions with someone else since it been suggested that Sprint Goals have other benefits:

          • Goals are what teams really commit to, if you miss couple of stories but hit the goal then things have gone well. However if you miss the goal but hit all the stories then the you've failed.
          • Goals provide a focus and something more than just a bucket of stories to energize the team.
          • Goals provide the team with another subtle pressure to self organize
          While I agree that Goals are very useful in terms of motivating people I've always found the overall product vision to be enough at the high level and the stories themselves sprint by sprint.

          So I'm interested do you use Sprint Goals successfully? Do you derive the benefit? If so how do you create a good sprint goal when the highest priority stories aren't really related to each other?

          Cheers
          Mark Levison



          .



          -- 
          Peter Stevens, CSM, CSPO, CSP
          Independent Scrum Trainer and Coach
          Sierra-Charlie Consulting | Zurich | Switzerland
          
          Member of DasScrumTeam.de
          
          blog:  http://scrum-breakfast.com
          tel:   +41 44 586 6450 
          cell:  +41 79 422 6722
          skype: peterstev
        • JackM
          I think part of the problem with setting goals that have meaning is the fact that Sprints are shorter. We still use goals each sprint but often times the goals
          Message 4 of 5 , Sep 26, 2010
          • 0 Attachment
            I think part of the problem with setting goals that have meaning is the fact that Sprints are shorter.

            We still use goals each sprint but often times the goals are a rehash of the stories.

            Good question

            Jack
            www.agilebuddy.com
            blog.agilebuddy.com

            --- In scrumdevelopment@yahoogroups.com, Mark Levison <mark@...> wrote:
            >
            > One bit of Scrum that has never really sat well in my gut is the Sprint
            > Goal:
            >
            > The Scrum Guide says: �*The reason for having a Sprint Goal is to give the
            > Team some wiggle room regarding the functionality. For example, the goal for
            > the above Sprint could also be: �Automate the client account modification
            > functionality through a secure, recoverable transaction middleware
            > capability.� As the Team works, it keeps this goal in mind. In order to
            > satisfy the goal, it implements the functionality and technology. If the
            > work turns out to be harder than the Team had expected, then the Team
            > collaborates with the Product Owner and only partially implement the
            > functionality*.�
            >
            > My issues are two fold: If the PO�s needs for a given sprint are a series of
            > disparate user stories, I don�t see how we can create a real sprint goal.
            > The reason states �to give the Team some wiggle room�. If the team needs
            > wiggle room they should talk to the PO and decide together what can be
            > dropped.
            >
            > In discussions with someone else since it been suggested that Sprint Goals
            > have other benefits:
            >
            > - Goals are what teams really commit to, if you miss couple of stories
            > but hit the goal then things have gone well. However if you miss the goal
            > but hit all the stories then the you've failed.
            > - Goals provide a focus and something more than just a bucket of stories
            > to energize the team.
            > - Goals provide the team with another subtle pressure to self organize
            >
            > While I agree that Goals are very useful in terms of motivating people I've
            > always found the overall product vision to be enough at the high level and
            > the stories themselves sprint by sprint.
            >
            > So I'm interested do you use Sprint Goals successfully? Do you derive the
            > benefit? If so how do you create a good sprint goal when the highest
            > priority stories aren't really related to each other?
            >
            > Cheers
            > Mark Levison
            >
            > *Mark Levison* | Agile Pain Relief Consulting
            > <http://agilepainrelief.com/>| Agile
            > Editor @ InfoQ <http://www.infoq.com/about.jsp>
            > Blog <http://www.notesfromatooluser.com/> |
            > Twitter<http://twitter.com/mlevison>| Office: (613) 862-2538
            > Recent Entries: Self Inflicted Agile
            > Injuries<http://www.notesfromatooluser.com/2009/12/self-inflicted-agile-injuries.html>,
            > Why use an Agile
            > Coach<http://www.notesfromatooluser.com/2009/11/why-use-an-agile-coach.html>
            >
          • Ron Jeffries
            Hello, George. On Sunday, September 26, 2010, at 11:44:53 AM, you ... Yes. If the work is just a list of stories, it s likely not very interesting or creative
            Message 5 of 5 , Sep 26, 2010
            • 0 Attachment
              Hello, George. On Sunday, September 26, 2010, at 11:44:53 AM, you
              wrote:

              >> My issues are two fold: If the PO’s needs for a given sprint are a
              >> series of disparate user stories, I don’t see how we can create a real
              >> sprint goal.

              > That's true, and that's often an impediment to having a sprint goal. If
              > the PO has no unified intent for the sprint, then the only goal is "do
              > some more work." Often there's nothing that can immediately be done
              > about that.

              > But when I have clients in that situation, I suggest that they take a
              > step back and look at the bigger picture. Often in these cases, the PO
              > isn't really the PO and doesn't have the authority to direct the work.
              > They're just relaying instructions. The fact that they can't see
              > unifying goals in the work is an indicator of that. When this is true,
              > I think it's beneficial if the PO-proxy works a little harder at
              > understanding the intent of the PO (sometimes still a proxy) above them.

              Yes. If the work is just a list of stories, it's likely not very
              interesting or creative work. "Work is a list of stories" may well
              be the name of an important impediment.

              Ron Jeffries
              www.XProgramming.com
              www.xprogramming.com/blog
              Adapt, improvise, overcome.
              --Gunnery Sergeant Tom Highway (Heartbreak Ridge)
            Your message has been successfully submitted and would be delivered to recipients shortly.