I developed the INVEST model years ago to help someone (and then many people) think about the user stories they were creating. Is INVEST all you need to create good stories? Unfortunately, no.
INVEST
Briefly, INVEST (see References) is an acronym for qualities of good user stories:
I – Independent – Stories are (mostly) independent capabilities.
N – Negotiable – Stories are not specifications, but solution ideas we explore together.
V – Valuable – Stories are valuable to those who care about the product.
E – Estimable (yes, it also means “can be estimated”:) – Stories can be estimated in terms of the work required for a particular team to implement them. (I don’t emphasize this one too much; estimates are over-used, and often unnecessary; Small and Testable capture most of what I care about there.)
S – Small – Stories are on the scale of hours to days, not months to years.
T – Testable – Stories are well enough understood that we can describe examples and behaviors.
That’s the original formulation. I tend to have a couple other criteria too. (But no, I won’t change the acronym.)
- End-to-End – Focus on a story as a full capability (from a user’s perspective), not a piece of a capability. (I’ve seen many places where teams have pieces of the puzzle, but nobody owns the end to end flow or capability.)
- Scalable (rather than just Small) – A story’s headline can be fulfilled in many ways – a manual solution, a minimal solution, or a full-featured solution. (Yes, this overlaps with the idea of negotiation through possible solutions).
Story Templates
Some teams like to use templates for their story headlines. The most common one is the “Connextra” format –
As a role, I want to do something, so that some goal is met
Another template, suggested by Industrial Logic, is –
Role Action Context
The advantage of templates is that they prompt you to think about which users you’re addressing and what capabilities they need. They push you to use a vocabulary your customers/users would understand. And they encourage you to rise above the details to think about why you want this.
But, like INVEST, the templates are easy to see, but they aren’t the point.
The Context of Stories
Criteria and story templates are great, and may nudge you in a better direction, but effective use of stories requires that you create a context that can leverage them.
Ron Jeffries described stories as “Card, Conversation, and Confirmation”, where Conversation is the most important part. On XP teams, a story (card) is treated as “a token of a conversation”, in Alistair Cockburn’s words. [I’ve also heard “ticket” or “promise”, but I don’t have a reference.] That is, the card exists because the team had a conversation about a possible future capability, and wrote a few words on a card to remind them of it.
How much work could you manage effectively this way? If it were only three stories, you wouldn’t need to bother. But 5, 10, maybe 50? (I doubt I could keep 20 deep conversations in my head, though 50 “headlines” is manageable.)
I can recall one legacy replacement project that had 100+ story cards and used them well. A handful at a time were active, but the cards helped track progress against the whole replacement.
However, most times I’ve seen a hundred stories, or even hundreds, the teams weren’t collaborating deeply or well. Rather, they seemed to use the set of stories (held in a tool) to avoid conversations and let analysis “get ahead”. (For the record, dumping lots of stories in a tool is not collaboration.)
Instead, agile teams limit work in progress (WIP). They’ve found it better to have the conversation, and move on to implementing and deploying while it’s still fresh in everybody’s minds. You may then be able to get feedback, ideally from real use, and adjust future directions based on what you learn.
Stories replace documentation and handoffs with a dynamic interplay of conversation, experiments, implementation, and feedback.
Stories replace documentation and handoffs with a dynamic interplay of conversation, experiments, implementation, and feedback. Rather than the old mostly-stable context, Agile teams recognize that most work now takes place in a constantly-evolving environment, and they must respond accordingly.
A Product Isn’t a Bunch of Stories – or a Bunch of Code
Stories can help in development, but there’s more to a product than stories or the code that implements them. A software product is not just software – it participates in and creates a whole ecosystem.
Especially early on, a team may have a lot of learning to do: users, customers, capabilities needed, architecture, etc. You may need to do experiments to learn where your ideas are useful or valuable.
Some developers resent the “folderol” and think somebody should somehow just know and tell them what to do – never backtracking, or even changing direction. They may get to work as if that were true, but the best teams instead accept the instability and leverage it to make even better products.
Product management has its own practices; product managers must balance outside and inside forces. To learn more deeply about this role, I look to Jeff Patton, Marty Cagan, Melissa Perri, and others (see References). Writing stories may be a small or even non-existent part of a product manager’s job.
Leveraging Agility
A key aspect of agility is that we don’t just lock in on some idea and head there, but rather we adjust both our direction and our target as we learn.
If your habit is to define a large project, load a bunch of stories in a tool, head there, and measure “conformance to plan”, you’re missing a chance.
Agility is instead built around an evolutionary approach: ship something simple (but end to end), try it, learn, and repeat – a little better each time around. User stories support this as a lightweight way of reminding us what to do.
Making Stories Work
- Take a whole-product perspective.
- Build in learning and feedback – part of everything you do.
- Use an evolutionary approach that supports that.
- Keep WIP low – focus on completing things more than starting them.
- Have conversations about capabilities – and implement them soon after.
- Use a tool if needed (e.g., remote), but don’t let stories become a “pile of leaves” (Jeff Patton’s great metaphor).
- Use CCC, INVEST, story templates, or whatever else will help you sustain a context where the above works well.
I’m happy that INVEST has helped some teams create better stories, but it’s a small tool. Flexible learning and an evolutionary approach are key to making Agile work. Stories are only a means to support that flexibility.
References
Cagan, Marty. Follow @cagan on Twitter. Most recent book: Empowered: Ordinary People, Extraordinary Products (2020).
Jeffries, Ron. “Essential XP: Card, Conversation, Confirmation”. Retrieved 2021-08-02.
Patton, Jeff. Follow @jeffpatton on Twitter. Website: https://www.jpattonassociates.com
Perri, Melissa. Follow @lissijean on Twitter. Website: https://melissaperri.com
Wake, Bill. “INVEST in Good Stories, and Smart Tasks”. Retrieved 2021-08-02. (See its Related Articles section for more details on this.)