When started writing what became “Little Book of Requirements & User Stories” I thought I was writing a few thousand words about the relatively straight forward subject of User Stories in agile development. A “few thousand” became a dozen online articles for Agile Journal and a few tens of thousands of words in the book.
Now those same lessons form the basis for my online workshop “User Stories Masterclass”. Still I find new perspectives and insights on User Stories. I was wrong, there is more to the simple “as a… I want… so that…” than I ever thought possible.
But for once I think we need to draw some boundaries, we need to be clear on what User Stories are NOT.
User Stories are not promises or commitments. Stories are ideas. Stories are tokens for work that might be done. Little more.
Simply writing a User Story, even adding it to a backlog in no way commits anyone to doing anything. Indeed I regularly recommend deleting stories from a backlog. I hear from start-ups who tell me that 30% to 50% of stories are never done.
User Stories are not functional specifications, although if you add enough acceptance criteria they may start to look like that.
User Stories are not functional specifications because User Stories are not complete. They are intended as a “placeholder for a conversation” or “a token for work to be done”. If they were complete there would be no need for that conversation and they would be much more than a token. They are deliberately incomplete to allow the conversation to happen. If the story was complete what can a conversation add? There is more value in the conversation than the story.
User Stories are not unambiguous, or rather: User Stories may contain ambiguities. In the same way User Stories are not complete they can be ambiguous. Again, if stories were clean cut and unambiguous there would be little to talk about in the famous conversation.
And by the way, the User Story conversation is not necessarily a one-off event: if you have the conversation then later, say, during development or testing, then talk some more.
User Stories are not user documentation, a collection of stories does not make a User Guide. If you need to create a user guide then the stories might serve as a reminder of what the software does but using them as user documentation would make for a very poor user guide.
If the system you are building needs a User Guide then the act of writing the User Guide is probably a story itself, a token for work to be done:
As a new customer using the system for the first time
I want a guide to get started
So that I can quickly get the benefits of the new system
All the usual rules of user stories apply here: be specific about who is using the system and what they need, include a so that clause to explain why they want to do this, leave some space for discussion (do the really want a user guide or a quick start guide?) and ensure the story has value in itself.
Similarly, User Stories are not any sort of system documentation, e.g. architecture document, maintenance guide. Again these are work to be done and may be the subject of a User Story.
In general User Stories are not part of the contractual commitment a team enters into. User Stories are poorly suited to be contractual documentation. Because User Stories are not complete and because they are ambiguous they perform poorly when used contractually.
Similarly, User Stories are not good as a record of what has been done. They can be forced into this role if they are updated after they have been developed – and preferably delivered. But that requires more work.
As with any documentation – user guide, system guide, a record of what was done, etc. – you should always ask: what value does this documentation have? and who will complain if this document does not exist?
Documentation is not free. Indeed documentation is very expensive – both to write and to read. And documentation is itself work to be done. Which means: if someone is writing a document then they are not doing something else, e.g. if a developer is documenting the system they are not adding new functionality.
Even when there is a technical author on staff to write documentation other work is displaced. The money used to pay a technical author could be spent elsewhere, another programmer or a tester maybe.
Documentation is expensive. Documentation is another deliverable.
User Stories are not intended to form part of the deliverable. They are transient, they come into existence to represent work that needs doing. They change as understanding improves and can, even should, be thrown away when the work is done.
User Stories Masterclass is running online again at the end of June.
Rather one session a week this time the class will be one afternoon, or possibly one and a half afternoons. Tickets will be on-sale soon, in the meantime you can join the waitlist and be the first to know when tickets go on sale.
Subscribe to my blog newsletter and download Project Myopia for Free
