This article has been deprecated. Please see the updated version.

Summary

In this article, I describe a 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 Charles Bradley 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.

The Model

Points

Best Practice

15*
3 Components and 2 Must Haves
10
No Stories more than 5 days in size**
15
PO 100% Allocated
5
PO Co-located (Talking Distance)
10
Weekly Story Grooming
10
Multiple Story Testing Styles(4+)
5
Immediate Story Signoff
10
All Stories Sized to 2-3 days
20
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.

Notes

  • No Partial Credit
  • Common Sense Rule: Since no team is perfect, if you feel like your team is exhibiting the 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.
  • 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 could have bad consequences.

Maturity

Score

Team User Story Maturity

25-39
Beginning Team
40-79
Intermediate Team
80-89
Advanced Team
90-100
Expert Team

Notes

  • 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 10 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 25 total points. Anything less is a really poor attempt at User Stories, which is not giving the practice a fair shake.

The Best Practices

Best Practice

Description

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.
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.
PO 100% Allocated
The person playing the Product Owner type role spends 100% of their time playing that role for that one team.
PO Co-located (Talking Distance)
The person playing the Product Owner type role sits within talking distance of the development team.
Weekly Story Grooming
A minimum of 1-2 hours each week is set aside for grooming User Stories. 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.
Multiple Story Testing Styles(4+)
The team knows and uses at least four story testing styles to represent their story tests. The trick is for the team to be able to efficiently represent story tests, and it takes a combination of styles to do this well.
Immediate Story Signoff
Stories are "accepted" or signed off on by the Product Owner as soon as the dev team thinks they are complete. Say, within 1 day at the minimum, and preferably within one hour.
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. 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 count to measure and forecast velocity.
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.

Related Articles