For Training, Coaching, and Consulting engagements, please contact me for details on how I can help your organization.

Please Note: User Stories are not a part of Scrum. User Stories are just one technique among many (Use Cases, Prose requirements, Test Scenarios, etc)to implement Product Backlog Items within Scrum.

Executive Summary

In this article, I describe a User Story pattern that is useful for teams that are advanced in their User Story practices. In short, the pattern is to ensure that all User Stories can be completed in 2-3 days by one or more developers. This pattern requires fairly advanced story slicing skills, as well as other key User Story skills and circumstances. However, when properly executed, the pattern has the follow valuable advantages for stories this small:
  • More opportunities to eliminate waste by deferring or dropping unneeded stories.
  • Less total effort required to understand stories.
  • Higher quality implementation: fewer bugs.
  • Less effort expended in creating and estimating tasks
  • Increased team morale by allowing more frequent story closure
In the article, I cover the team context that is required to achieve the pattern, the advantages of the pattern, and a strategy for progressing towards the pattern. I also discuss how this pattern can impact the Scrum implementation.

The Pattern

Slice stories to where they are all approximately the same size of roughly 2-3 days for one developer (or a pair if your team does pair programming). Instead of burning down tasks, burn down the story "count."

Note that I'm not the creator of this pattern -- I'm just documenting what I've heard from those I trust on the subject of User Stories. As you can probably tell from the context below, I'm not convinced that all teams can pull of this pattern successfully. I'm told by people I trust in the industry that most teams can eventually achieve this pattern, though I remain minorly skeptical.


I go back and forth on whether this is a Best Practice or a Process Pattern. I consider a Best Practice to be something that is good in almost all cases and contexts. A pattern, on the the other hand, is usually a best practice only within a specific context. I think I lean towards pattern here due to the context explained below.

Terminology Note: When I say "days" below, I'm not suggesting that you estimate your stories in days(or any other unit, per se). I'm just suggesting that the stories have a size of roughly 3 days as judged by the development team.


In order to execute this practice well, the following usually have to be true:
  • Someone on the team(usually the PO, but not always) has to be a good story slicer, which is a fairly advanced User Story skill. If there is no such person, then this pattern may not be appropriate.
  • Since splitting of stories should be done as part of a conversation with the development team and PO, the PO must be highly available and the team and PO will have to be communicating almost constantly. Constant PO Interaction and high PO availability are already User Story Best Practices, but if a team cannot execute those best practices well, this pattern may not be appropriate.
  • Slicing stories this small generally increases the total story count per sprint/release in an exponential fashion. As such, it requires a product owner with good visioning skills, to keep the big picture on track and delighting stakeholders. Extensive use of story themes will probably aid in this effort, but again, managing this many small stories well is an advanced skill. If good visioning and big picture skills are not present, then this pattern may not be appropriate.
    • Example for number of stories. If each story is an average of 3 days for one developer,and you have 9 developers on the team in a 2 week sprint, that can mean roughly 25-30 stories in one sprint!
  • The PO has to be highly available within the sprint to accept/sign off on completed stories. If your PO is not highly available, this pattern may not be appropriate.
  • Generally speaking, special care must be given by the PO when communicating about such small stories to stakeholders. If the number of stories is high, the stakeholders may not want to be involved at that level of detail. As such, extensive use of themes and epics can be used to abstract business stakeholders from story detail and the high number of stories.
  • In Scrum, special care has to be given as to which stories are included in the potentially shippable product increment at the end of the Sprint. Said another way, if you deliver a small story (maybe part of a larger feature or theme) that would appear to an external stakeholder or user to be annoying or "half backed," then you're probably not delivering something that would be "potentially shippable" in the eyes of the Product Owner. A shipped feature that is perceived by users as half baked is not always a bad thing. Sometimes it is a bad thing, sometimes it is a good thing, and sometimes it's a totally embarrassing thing -- it depends largely on product context. If special attention to small story ship-ability cannot be given, then this pattern may not be appropriate.
    • This risk is always present when splitting stories, but it's a bigger risk with this pattern due to the greatly increased story count.
    • Ways to mitigate this risk
      • Give careful attention to slicing stories such that they are potentially shippable even in their smallest form.
      • Give careful attention to prioritizing stories such that the group being worked on in the current sprint are shippable as an increment. Use of themes can help here.
      • Last ditch solution that should be done only very rarely: Put the unshippable stories on a version control branch or make their functionality invisible to the user. Only do this if you know the stories will definitely be shippable in the next Sprint, and you may not consider these stories as "done" because they are not shippable.


  • Major advantages
    • Stories this small allow for more opportunities to defer or discard stories. This eliminates a lot of downstream waste, and thus, is a major advantage.
    • Stories this small are much more easily digested by the development team, and thus are less prone to code and test defects.
  • Other advantages
    • Stories this small allow individual members and teams to get story closure much more frequently, which keeps morale up and productivity high.
    • Stories this small will require fewer (Sprint Backlog)tasks, which means less effort will be expended in creating and estimating the tasks.
      • Some teams forgo (Sprint Backlog item)task creation and/or estimation altogether in this situation. Technically this is a violation of the Scrum Guide, but a fairly suitable substitute practice can be achieved by doing a story count burndown to reflect estimated work remaining in the Sprint (Sprint Burndown) and support team optimizations. I recommend that only *very* advanced teams ever forgo task creation and/or estimation, but if a team can execute this User Story pattern well, they are probably advanced enough to forgo the tasks. Another way to see if your team is advanced enough to forgo task creation/estimation is to use the Bradley User Story Maturity Model to assess your team and see their maturity level is high enough (Advanced or Expert).
      • Another advanced strategy: Some teams forgo explicit estimating of User Stories at this level, since the vast majority of their stories are about the same size. Instead, they simply count the number of user stories, and use this count to track velocity and to forecast velocity. I argue that trying to make all stories the same size is still estimating, it's just not explicit estimating. The dev team still needs to decide that a story can be completed in about 2-3 days, and if not, they need to work with the PO to split the story into one or more stories that are 2-3 days. Again, estimation is still occurring, even if implicitly so.

Strategy for adoption

One strategy to progress towards this vision is to create a maximum story size, and decrease the maximum story size.
  • Example
    • Team's current story characteristics:
      • Max size: 4 weeks (20 work days for one developer)
      • Average size: 2 weeks
    • Goal 1: Max size: 2 weeks
      • Do this for 1-3 sprints, then move to Goal 2
    • Goal 2: Max size: 7 days
      • Do this for 1-3 sprints, then move to Goal 3
    • Goal 3: Max size: 5 days
    • And so on until you get a max size of 3 days

Other User Story Links