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.

The User Story Maturity Model


In this article, I describe the 2nd version of the " User Story Maturity Model" to help teams assess their usage of the practice and identify areas for improvement. You won't find this anywhere else, because this model is a original. I base this model on the most credible User Story literature as well as on my experiences coaching Scrum Teams. The model's best practices are listed in a particular order that represents a strategic path for teams looking to advance their User Story Maturity. While the model doesn't cover everything, and it is no guarantee of success, it should help teams progress their skills and practices.


  • Modeling is not an exact science. That's why it's called a "model." As such, the purpose of the model is to help teams assess and improve. In particular, any poor faith or poorly executed attempt at implementing a best practice(or role) could have bad consequences.
  • The model is not intended as a predictor of success, by any means. It is simply meant as a way for teams to assess and improve their usage of the practice. More details...
  • Topics specifically not covered yet by the model (generally because they are not easy to self assess)
    • Prioritizing User Stories for value or ROI
    • Estimation of story size (Story Points, Ideal Days, Counting Stories, etc)
    • Velocity

The Model


User Story Best Practices

3 Components and 2 Must Haves
Constant PO interaction
No Stories more than 5 days in size**
Story Tests Defined before Development Begins
PO Well Allocated
PO Co-located (Talking Distance)
Weekly Story Grooming
Immediate Story Signoff
All Stories Sized to 2-3 days
Story Tests 90+% automated
(for all current stories)
* This best practice is required.
** This is more of a "good practice" than a best practice. More details below.



Team User Story Maturity

Beginning Team
Intermediate Team
Advanced Team
Expert Team


  • No Partial Credit -- either you fulfill the entire best practice or you don't.
  • Common Sense Rule: Since no team is perfect, if you feel like your team is fulfilling the entire best practice 90+% of the time, go ahead and give your team the points for that practice.
  • Note the importance of the Product Owner's availability in terms of the model. The availability of the PO to the dev team is crucial in the User Story practice.
  • The best practices are listed in the model above in the rough order in which I believe teams should attempt the practices. If a team is unable to execute or make progress on a practice, then the team should move on to the next practice and focus on attaining the level of the next practice.
    • For instance, if you can't get your PO 100% allocated, then move on to trying to get the PO co-located. If that doesn't work, then work on having Weekly Story Grooming, and so on.
  • Note that, in order to even be a beginning team, you have to be exhibiting the "3 Components and 2 Must Haves" and at least 2 more points worth of Best Practices. This is due to my belief that you are not even doing User Stories if you don't have at least the required practice and 5 total points. Anything less is a really poor attempt at User Stories, which is not giving the practice a fair shake.
  • While I use the Scrum term "Product Owner", this term translates pretty directly to other processes and concepts. Other names for essentially the same role with respect to User Stories: Onsite Customer (XP), User Proxy, Product Manager, etc. I also use other Scrum terms, but they can be translated to fit almost any software development strategy.

The User Story Best Practices

Best Practice


3 Components and
2 Must Haves
This practice is a required practice. All stories have the 3 Components (Card, Conversation, Confirmations) and 2 Must Have Characteristics(Direct Value to External Stakeholder + Story describes change in the System Under Development). Confirmations are also known as Story Tests. See A User Story Checklist
Constant PO interaction
The Product Owner should be constantly interacting with the development team, with the only possible exception of when the PO is working with external customers and stakeholders to gather and prioritize stories. Even then, it would probably benefit all involved if the PO brought someone from the dev team as a (mostly silent) observer of those interactions with external stakeholders. As a rule of thumb, the PO should be interacting with one or more developers at least once an hour or so, and hopefully numerous times every hour. If the PO is truly interacting with developers at the minimum of once an hour, then give your team the points for this practice.
No Stories more than 5 days in size
This isn't really a best practice. It's a good practice that is a stepping stone to getting to the best practice(Stories 2-3 days in size). I include it here to demonstrate that this good practice is a good first goal in terms of keeping stories small. The 5 days here means it would take a person(or pair, if you're pair programming) 5 days to fully implement, fully test, and get the story accepted by the PO. Said another way, 5 ideal person days(or 5 ideal pair days if you're pair programming).
Story Tests Defined before Development Begins(ATDD)
The team defines story tests upfront before code development on the story begins. Note here that we're speaking of "conceptual" tests, or test confirmations. Defining story tests(aka acceptance criteria) upfront is consistent with Acceptance Test Driven Design, because story tests are essentially acceptance tests. Automating the story tests is a whole different practice, so don't confuse defining story tests with automating story tests. Improving how to capture story tests is sometimes aided by the knowledge of various story testing styles. Also, see this presentation on Story Testing Patterns .
PO Well Allocated
The person playing the Product Owner type role spends at least 50% of their time or more playing that role(PO) for that one product.
PO Co-located (Talking Distance)
The person playing the Product Owner type role sits within talking distance of at least 80% of the development team. Not shouting distance, not "in the next room" distance, but within talking distance.
Weekly Story Grooming Meeting
A minimum of 1-2 hours each week is set aside for a meeting to groom User Stories. Your team may need more than that, so adjust for your team, but having at least 1-2 hours set aside is a best practice. This typically means time to have conversations, create Story Tests, estimate the size of stories, and splitting the stories when necessary. The entire team participates in this activity. Note that, while this time is set aside specifically for the entire team to groom stories, all user stories are constantly being groomed by the entire team as necessary. Don't make the mistake of assuming that the weekly story grooming meeting is the only time the team will spend grooming user stories in a given week. Also, not all story grooming has to involve the whole team, but fulfilling the 1-2 hours per week meeting requirement must involve the whole team.
Immediate Story Signoff
Stories are "accepted" or signed off on by the Product Owner as soon as the dev team thinks they are complete. So, within 1 day at the minimum, and preferably within one hour. Try to avoid this Worst Practice - The Sprint Review as a Signoff Meeting.
All Stories Sized to 2-3 days
All stories are sized to 2-3 days. This means all stories more than 3 days are split into 2-3 day stories. This also means that any stories less than 2 days are combined with other stories to keep the size to a fairly constant size of 2-3 days. This practice requires pretty advanced story splitting skills, as well as the ability to keep an eye on the "bigger picture" as you aggregate several small related stories(sometimes called a Theme) into a logical and shippable feature. The 2-3 days here means it would take a person(or pair, if you're pair programming) 2-3 days to fully implement, fully test, and get the story accepted by the PO. Said another way, 2-3 ideal person days(or 2-3 ideal pair days if you're pair programming). As an aside, some teams abandon using Story Points once they get to this point because all stories are very close in size. Instead of estimating stories, they just count the number of stories, and use this "story count" to measure and forecast velocity. See this User Story Pattern - Micro Stories.
Story Tests 90+% automated
(for all current stories)
90+% of all story tests for current stories are automated. This can be difficult for many teams to get to, but it is possible. Note that we don't say how they're automated here, just that they are automated. The best method of automation will depend on a lot of team specific factors. Also, see this presentation on Story Testing Patterns .

Related Articles