At the End of a Sprint on a Scrum Project: Two Scenarios

a-or-b---exc---v171204-0028for-blog0029-lowerres-squashed

Take a look at the results at the end of a sprint on a Scrum project. There are two scenarios. Both have the same user stories with the same story points for each:

  • User story 1: 13 story points
  • User story 2: 8 story points
  • User story 3: 3 story points
  • User story 4: 5 story points
  • User story 5: 1 story point
  • User story 6: 3 story points
  • User story 7: 1 story point

Scenario A

a-or-b-0028a0029---exc---v171204-lowres-squashed

Here are some details on A:

  • User story 1: 70 hours of work performed, 5 hours of work remaining
  • User story 2: 51 hours of work performed, no work remaining (and it meets the Definition of Done [DoD])
  • User story 3: 45 hours of work performed, 13 hours of work remaining
  • User story 4: 29 hours of work performed, no work remaining (and it meets the DoD)
  • User story 5: 3 hours of work performed, 2 hours of work remaining
  • User story 6: 30 hours of work performed, 17 hours of work remaining
  • User story 7: 4 hours of work performed, 1 hour of work remaining

A is summarized as:

  • 232 hours of work was performed, and 38 hours of work remains
  • 2 user stories were done, and 5 user stories were not completed

Scenario B

a-or-b-0028b0029---exc--v171204-lowres-squashed

Here are some details on B:

  • User story 1: 75 hours of work performed, no work remaining (and it meets the DoD)
  • User story 2: 51 hours of work performed, no work remaining (and it meets the DoD)
  • User story 3: 58 hours of work performed, no work remaining (and it meets the DoD)
  • User story 4: 29 hours of work performed, no work remaining (and it meets the DoD)
  • User story 5: 5 hours of work performed, no work remaining (and it meets the DoD)
  • User story 6: 14 hours of work performed, 33 hours of work remaining
  • User story 5: no work performed, and five hours of work remaining

B is summarized as:

  • 232 hours of work was performed, and 38 hours of work remains
  • 5 user stories were done, and 2 user stories were not completed

What Counts

a-or-b-0028conclusion0029---exc---v171204-lowerres-squashed

Scrum requires teams to build an increment of functionality during every sprint. Only work meeting the Definition of Done (DoD) is counted as complete, demonstrated at the sprint review meeting, and is potentially shippable.

There were two scenarios. Both had the same user stories with the same story points for each, and the same amount of work hours performed. Yet the outcomes were dramatically different. In A, 2 user stories were done--and are to be demonstrated at the sprint review meeting, and are potentially shippable. In B, 5 user stories were done--and are to be demonstrated at the sprint review meeting, and are potentially shippable. B is the better scenario.

A possible explanation for the differences between the two situations is that the Scrum team in B may have done a better job of limiting Work in Progress.

To learn more about agile/Scrum, check out the award-winning book, Agile Scrum: Your Quick Start Guide with Step-by-Step Instructions. You're invited to visit the digital press kit, watch the trailer, and pick up a copy of the publication—it’s available in paperback and ebook—at Amazon.

Let's Connect

Connect with us on LinkedIn, Twitter, and Facebook.

© Copyright 2018 Scott M. Graffius, Exceptional PPM and PMO Solutions™. All rights reserved. This material may not be published, broadcast, rewritten or redistributed without the express written permission of Scott M. Graffius/Exceptional PPM and PMO Solutions™.



exc-inc-badge-19093011-lr-1-squashed



exc-guarantee-badge-19093011-lr-squashed


exc-li-badge-19093011-lr-squashed



custom - back to main page of blog




Techniques for Gathering User Stories

1 - TECHNIQUES FOR GATHERING USER STORIES - exc - v171024B LOWRES

In Scrum, user stories act as requirements. Each story represents a portion of business value that a team can deliver in an iteration. A common format is: “As a (role), I want (goal) so that I can (reason).” Here's an example: “As a customer, I want shopping cart functionality so that I can buy items online.” User stories are captured in the product release backlog. This short article focuses on techniques for gathering user stories.

The following methods can help the Product Owner gather material for user stories:

Interviews: Ask a diverse group of users—or anticipated users if the product/service does not yet exist—open-ended questions containing "how" or "why." For example: "How would you pair this device with your iPhone?”

Observation: Watch people using the product/service.

Prototyping: Use tools such as sticky notes, PowerPoint, and wireframes to illustrate ideas, show preliminary versions of the product, and facilitate discussions.

Surveys: Employ surveys where the Product Owner verbally asks respondents pre-determined questions, or questionnaires where items are presented via forms (online or in hard copy format).

Workshops: This is a type of brainstorming where the group identifies as many user story ideas as possible. To support getting a high quantity of ideas, it is suggested that participants should not agree/disagree with or assess items during the workshop.

The above content includes excerpts from the book,
Agile Scrum: Your Quick Start Guide with Step-by-Step Instructions. It’s available in paperback and ebook formats at Amazon. The press kit is available at agilescrumguide.com.

Let's Connect

Connect with us on LinkedIn, Twitter, and Facebook.

© Copyright 2017 Scott M. Graffius, Exceptional PPM and PMO Solutions™. All rights reserved. This material may not be published, broadcast, rewritten or redistributed without the express written permission of Scott M. Graffius/Exceptional PPM and PMO Solutions™.



exc-inc-badge-19093011-lr-1-squashed



exc-guarantee-badge-19093011-lr-squashed


exc-li-badge-19093011-lr-squashed



custom - back to main page of blog