SN-Logo NewSN-Logo NewSN-Logo NewSN-Logo New
  • Scrum Courses
  • Agile Keynotes
  • Agile Books & Tools
  • Blog
  • About
  • Contact
0

CHF0.00

✕
In Praise of the Waterfall
08-07-2010
Scrum Breakfast/September Introduction to Lean and Agile
29-08-2010

Eight Strategies for Achieving the Scrum Sprint Commitment

Published by Peter Stevens on 23-07-2010
Categories
  • commitment
  • product owner
  • sprint contract
  • sprint planning
  • sprint review
Tags

I just finished leading an in-house Scrum Product Owner course with a group of 6 actual or future product owners. One of their most pressing issues was what to do when the team does not meet its commitment. “My Team regularly commits to 20 points, then only delivers 10. What can I do?”

We briefly discussed the alternatives of shooting, firing or otherwise punishing team members for not meeting their commitment, but quickly came to the realization that such measures are likely to be counterproductive. If the team fears the consequences of not meeting a commitment, it will be very cautious about making those commitments.

Here are eight strategies for achieving the sprint goal:

1. Yesterday’s Weather

If the team finished three backlog items (“stories”) for a total of 10 points in the last sprint, then that is a good place to start for the next sprint. As a product owner, only accept a commitment to 10 points. As a team, only offer to take on 10 points. If the team runs out of work, it can always go back to the product owner and ask for more.

2. Smaller Stories

The larger the backlog item, the higher the complexity and the higher the risk. By breaking the story down into smaller stories, you decrease the risk of each individual story. If 3 of 6 stories go South, the Team has a problem, if the team does not succeed on 3 of 20, it’s not such a big deal.

Current recommendations suggest that a team should commit to 10 to 20 stories per sprint. For two week sprint with 6 people on the team, that means each story (backlog entry) will need, on the average, about 3 to 6 Person-days to complete.

Reminder: each story must meet the INVEST criteria and have an acceptance test associated with it.

3. Prioritize large stories higher

Even if you are aggressively breaking down stories, some will be bigger than others. It’s dangerous to have big, low priority items. When the team starts the story, the sprint should be nearing its end, so the story may not fit. Get the big ones out of the way first, then do the smaller ones.

4. Defend against Scope Creep

A common problem in the sprint is discovering “new” requirements during the course of the sprint. (Product owner says, “check our requirements document, chapter 4.1.3 for the details.” Chapter 4.1.3 is where the skeletons are hiding. No-one has really studied the implications of 4.1.3 and it will surely have surprises which cause the effort to rise.

I have found the following strategy to be useful: The story has precedence over the requirements doc. It represents the instructions for this sprint, which is should create a small piece of the entire product. If I stumble on a requirement which is not clearly part of the story, I report that to the product owner, who then decides what to do with the “new” requirement (in backlog or not, prioritized high or low), and I continue to implement the story as previously agreed.

How do you identify what is in the story and what not? Two components define the story: 1) its title 2) how do demonstrate it to the Product Owner at the end of the sprint. If the functionality in question is needed to make the title happen and is visible in the ‘how to demo’ workflow, then it is part of the story, otherwise not.

Even if title is not a correctly formatted user story, the story should be a complete sentence. For example:

  • Good: As a job hunter, I want to send my resume with my job application so that….
  • OK: Send resume with job application.
  • Much room for improvement: Attach resume.

The second component is “how to demo.” This is a simple work-flow which the team will use to demonstrate the story and that they have met the requirements on the story, for instance: 1) chose a want-ad, 2) select “Apply,” 3) select “Attach resume,” 4), pick file from dialog 5) upload, 6) Send. At there very latest, Team and product Owner should agree on this work-flow during the Sprint Planning.

So the team is working on this story, reads chapter 4.1.3, and discovers ‘E-Mails should be signed with PGP to assure authenticity.” Sounds like a great, trust building requirement. Is it part of this story? No! There is nothing about digital signing, neither in the title nor in the ‘how to demo’. Report this to the PO who can create and prioritize a new story, if appropriate.

5. Strict Prioritization

The backlog items are prioritized in the Product Backlog. This prioritization is carried over into the sprint backlog. A simple approach is to consider the top story ‘Must have’ and everything else ‘Nice to have’ until the top story is finished. The team members should always focus on getting the top story finished before looking at issues further down the priority list.

6. Early Acceptance

There is no rule which says the Product Owner must wait until the Sprint Review before definitively accepting a story. If the story is done after three days, then ask the product owner to accept it right away. This smooths out his workload and reduces the uncertainty on how many stories have been accepted.

7. Swarming / Pairing

Consider a team with 4 people, 4 stories each estimated at 10 days each, a 2 week sprint (10 working days), and in which each team member takes on 1 story and works on it large by himself. On the 9th day, each story is 90% done.

How many stories will be done at the end of the sprint? Hard to say. Getting stories done usually means coordinating with other people: a code review, an independent test, acceptance by the Product Owner. This can become a tremendous bottleneck and it is possible that no stories get finished, even if the work on each really was 90% done. The situation gets worse if the stories were underestimated. They don’t need 10 days to finish, but 13. At the end of the sprint, nothing is finished and the burn-down chart remains unchanged.

Let us assume that this team applied Strict Prioritization and the entire team worked on one story at a time and that this did not affect the working time needed to complete the story. The first story would finish after 3 days, the second after 6, the third after 9 days. At the end of the sprint, the team has taken 30 points off the backlog. Not the 40 they had hoped, but better than the zero achieved with everybody working on their own story.

Can a team — and in particular your team — really apply swarming? Only one way to find out: Try it on a story or two and see how it works. More widely practiced is pairing, in which two team members work on a story together. This is almost always useful, because it stimulates knowledge sharing and prevents becoming too dependent on a single team member.

8. Throttling

The Product Owner cannot and should not tell the team to pair or swarm. But the P-O can still influence this process. Let us assume the team has 6 members. If the product owner only asks for 3 stories (sized according to the guidelines above), then the team is forced to ask themselves, ‘How can we work together to solve this problem?’

I recommend this approach to teams that are just getting started, in combination with a few weeks of one week sprints. This helps them learn to do Scrum quickly and to work as a team effectively.


These strategies have worked for me. What other strategies do you use to help your team achieve its commitment at the end of each sprint?

Share
0
Peter Stevens
Peter Stevens

Related posts

05-06-2019

The Sprint Contract


Read more
01-02-2019

How to be effective in an online meeting


Read more
09-01-2018

Lowest prices for Scrum Training


Read more

3 Comments

  1. Matt Block says:
    23-07-2010 at 19:33

    Good post and good advice. We've done a few things that line up with these recommendations. My question would be, are they having a retrospective? This should definitely be coming up in the retrospective with an action item or two on what they team plans to do differently the next sprint to avoid this recurring issue.

    A few specific things we do…

    1) In line with your number 3, we generally leave the sprint planning with the first round of tickets assigned and always ensure the largest ticket(s) in the sprint are being addressed first.

    2) We don't really do "swarming", but we do emphasize getting a ticket completely through the process before starting another. When a developer completes one ticket he/she then focuses on peer review and testing of tickets from other developers before starting the next. There are times when the developer picks up another ticket before the first one is completely through due to scheduling issues, but we have a rule of no more than 2 in process per developer without approval from the team in the daily meeting.

    The second item above probably had the biggest impact on our success as it helps make it more visible when team members are waiting on others to review or test before moving on to another issue. Kanban practices focus a lot on this "flow" as well and could be very useful to anyone interested.

  2. abc says:
    22-10-2010 at 17:52

    Hi,
    A good posting overall. Could you provide references for this comment:
    Current recommendations suggest that a team should commit to 10 to 20 stories per sprint. For two week sprint with 6 people on the team, that means each story (backlog entry) will need, on the average, about 3 to 6 Person-days to complete.

  3. Peter says:
    24-10-2010 at 18:55

    Hi abc,

    You might look at this posting on When is a Story too big?" — in particular the discussions on story size. ( And Sorry for the Spam!! Ugh).

    You've caught me on the recommended number of stories – I'm no longer certain where I got the number. I looked for an article discussing the issue and couldn't find one quickly. I will do some research on this and post a better answer to your question.

    Cheers,
    Peter

Learn more about Agile

  • Certified Scrum Product Owner | Face-2-Face | English | 230413-CP2
    in Zürich
    April 13, 2023 -
    April 14, 2023
    Register Now
  •  

  • Certified Scrum Master | Face-2-Face | English | May 22-23, 2023
    in Zürich
    May 22, 2023 -
    May 23, 2023
    Register Now
  •  

  • Certified Scrum Product Owner | Face-2-Face | English | Jun 15-16, 2023
    in Zürich
    June 15, 2023 -
    June 16, 2023
    Register Now
  •  

  • Certified Scrum Master | Face-2-Face | English | Jul 06-07, 2023
    in Zürich
    July 06, 2023 -
    July 07, 2023
    Register Now
  •  

High Performing Teams

  • Get Stuff Done
  • Get Right Stuff Done
  • Create Alignment
  • Leadership

Free Resources

  • Personal Agility Institute
  • Impressum
  • Terms and Conditions
  • Privacy Policy

Upcoming courses

  • Certified Scrum Product Owner | Face-2-Face | English | 230413-CP2 in Zürich
    April 13, 2023 -
    April 14, 2023
    Register Now
  • Certified Scrum Master | Face-2-Face | English | May 22-23, 2023 in Zürich
    May 22, 2023 -
    May 23, 2023
    Register Now
© 2020 Saat Network GmbH. All Rights Reserved.
    0

    CHF0.00

      ✕

      Login

      Lost your password?

      We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept All”, you consent to the use of ALL the cookies. However, you may visit "Cookie Settings" to provide a controlled consent.
      Read more about our Privacy Policy
      Cookie SettingsAccept All
      Manage consent

      Privacy Overview

      This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
      Necessary
      Always Enabled
      Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
      CookieDurationDescription
      cookielawinfo-checkbox-advertisement1 yearSet by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category .
      cookielawinfo-checkbox-analytics11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
      cookielawinfo-checkbox-functional11 monthsThe cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
      cookielawinfo-checkbox-necessary11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
      cookielawinfo-checkbox-others11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
      cookielawinfo-checkbox-performance11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
      viewed_cookie_policy11 monthsThe cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
      Functional
      Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
      CookieDurationDescription
      mailchimp_landing_site1 monthThe cookie is set by MailChimp to record which page the user first visited.
      Performance
      Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
      Analytics
      Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
      CookieDurationDescription
      CONSENT2 yearsYouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
      _ga2 yearsThe _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors.
      _gat_gtag_UA_42152348_11 minuteSet by Google to distinguish users.
      _gcl_au3 monthsProvided by Google Tag Manager to experiment advertisement efficiency of websites using their services.
      _gid1 dayInstalled by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously.
      Advertisement
      Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
      CookieDurationDescription
      NID6 monthsNID cookie, set by Google, is used for advertising purposes; to limit the number of times the user sees an ad, to mute unwanted ads, and to measure the effectiveness of ads.
      test_cookie15 minutesThe test_cookie is set by doubleclick.net and is used to determine if the user's browser supports cookies.
      VISITOR_INFO1_LIVE5 months 27 daysA cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
      YSCsessionYSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
      yt-remote-connected-devicesneverYouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
      yt-remote-device-idneverYouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
      Others
      Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.
      CookieDurationDescription
      COMPASS1 hourNo description
      cookies.jssessionNo description available.
      S1 hourNo description available.
      SAVE & ACCEPT
      Powered by CookieYes Logo