User Stories for small teams and individuals
My wake up call
I should admit that all my life, I believed that user stories are feature requests with a fancy and rigid ticket structure. My personal experience is limited.
Last week, I had to explain the concept of user stories to a different person, only to learn that I knew nothing about the subject and mostly cargo-culted them. It’s time to fill the gap. Below I’m sharing my understanding of user stories and notes that I extracted from different sources in the context of a small team or a personal project.
Story card format
The classical story card format is known as Connextra template
As a [role]
I want to [capability],
So that [receive benefit].
The INVEST checklist
INVEST is an acronym for a checklist to build a good user story — independent, negotiable, valuable, estimable, small, and testable.
Independent: Should be self-contained. You should be able to change the order in which you pick and release stories.
Negotiable: User story should not be written like a contract and should live space for discussion.
Valuable: User story should deliver value to stakeholders.
Estmable: You should be able to estimate a user story.
Small: User story should be small enough to be done in a few days.
Testable: User story should contain a definition of done.
Card, Conversation, Confirmation (3C) of user stories
The user story card can’t and shouldn’t contain all the user story details. What follows is a conversation, followed by agreement on how the story should be tested, in a confirmation.
User story card describes “why” without “how”
The concept of user stories plays well with the product management framework jobs to be done. To find a technical solution to a problem, we need to answer two questions: “why” and “how” — why do we solve a problem, and how do we do it.
Feature requests focus on “how” and either ignore “why” or address it tangentially and implicitly. User stories start with a different side. They focus on the problem, and only the follow-up discussion defines the “how.”
Why bothering?
If feature requests or free-form tasks serve stakeholders well, why bother introducing user stories? Below are some of the thoughts, primarily speculative but grounded on my experience working with different stakeholders.
Clear vision and strong technical background — successful technical founders.
Usually, they form a feature request after thinking a lot about it. When they draft the ticket, they already have a strong opinion on how the team must implement it. Their technical expertise lets them fill the ticket with detailed technical instructions.
Why pretend to discuss if everything has already been decided? They may feel that following the card-conversation-confirmation format may sound like an unnecessary ceremony.
I’ve seen this approach becoming a challenge when the team grows. The very moment the product person needs a hand because they are overwhelmed, there is nobody to help because the team is not used to making decisions on their own.
- Explicitly formulating the why on the card and discussing the solution can help developers build a sense of ownership.
- Likely, this also results in better technical decisions.
- Finally, being explicit about actors and their desires can help you build the product intuition and make reasonable decisions when they go beyond scratching your itch.
No clear vision but strong technical background — any average developer dreaming of making a startup.
I know how it happens because it has happened to me a lot. I learned something new and wondered how to turn it into a product. A solution waiting for a problem, as people say.
Oh, the curse of enthusiastic developers. Lack of clear understanding of the customer and immersion by the process results in an infinite fractal of making for the sake of making. We’re toying with tools, services, architecture, and everything else we love so much. Then we abandon the project, jump to the next idea, etc.
Hopefully, the user story can serve as an easy-to-use tool to help organize the developer’s work and put the maker’s spirit in the right direction.
Clear vision, but no technical background — domain experts, professional product managers.
Not much to add. User stories probably are the most natural way of sharing their vision with developers.
No clear vision, no technical background — a recipe for disaster.
There is a slight hope that user stories can help them develop a product intuition and move to the previous category.
Story size
There are two dimensions of what can be called a story size, impact (value to the business) and amount of work. We keep both parameters under control by limiting the scope.
- Amount of work. Ideally, it should take 1-3 days to complete. User stories shouldn’t take more than half the sprint and definitely should never be longer than a sprint.
- Impact. It’s OK that the value that the story brings is not high. It can and probably should be small.
When the scope is too large, turn the story into an epic and split the story into smaller chunks.
Tips on writing user stories
- Don’t cargo cult story format. It is less critical than the idea the story card conveys.
- If you need to emphasize changes, extend the template by expressing current behavior with words like
whereas currentlyorinstead of. This is helpful for stories that introduce the change in the existing functionality rather than introducing a new one. - Try to be specific with your roles. Consider generic “As a user” as the smell (as in code smell).
Backlog size
Large backlogs don’t make sense in the context of agile development. Common advice is to keep backlog size worth 2-3 sprints.
Applying math over a two-week-long spring, we’ll get something like 3-6 stories per developer per sprint, but the actual number should be less than that because multiple developers can work on the same story. I learned that it’s called swarming.