In the last post of this series, we covered the basics of what a User Story is and how to write one. In this post, we will learn how to write better user stories using the Invest mnemonic.
Although the basic structure of a User Story is easy enough to grok, you may find yourself unsure of how or where to start when it comes time to put them into practice. Breaking down a complex project into bite-sized prose is no easy task.
For example, if you were tasked with filling a backlog with user stories to build a car…
Would you scope them large? Like this:
As a pedestrian who is tired of walking, I want a car, so that I can quickly get from one place to another.
Or would you list a lot of details in a single story? Like this;
As a driver, I want a dashboard that contains a transmission temperature gauge, a tachometer, a speedometer, a transmission gear selector, an oil pressure gauge, a fuel gauge, a voltmeter, and an engine coolant temperature gauge, so that I can easily monitor many different functions and measurements of the vehicle. And they should all light up with cool colors too. Actually, it all a hologram.
It’s safe to say that neither of those examples would be considered good User Stories in the eyes a development team. So where does one start?
Fortunately, there is a nifty mnemonic device that can be used to guide your stories; the INVEST mnemonic. The INVEST mnemonic is a tool for remembering six characteristics that good User Stories have.
Understanding the INVEST mnemonic
The INVEST mnemonic breaks out as follows:
User Stories should not be dependencies of one another. A good litmus test for this principle is to ask yourself, “If I were to drastically alter a given User Story, would any of the others be invalidated?”
User Stories should capture the spirit of one’s intentions, but they should leave enough room for iteration through team discussion. Through the team’s collaboration, valuable details may come to light, which would otherwise remain unknown.
The completion of a User Story should always result in added value for the user. The definition of “user” can be broad in this sense, and it may not always be a consumer end-user. The user in question might be a team member or even yourself, the Product Owner.
If the team is unable to estimate the level of effort involved in completing a given story, then work should not begin on that story. Moreover, without determining the LOE, it is impossible to prioritize it against other User Stories, and thus it can not be a priority.
Sized (or Small):
As Agile prefers to use effort as a function of time, as oppose to time itself, we say that the level of effort for a given User Story should be “small”. How exactly does “small” convert to real-world timing? This is intentionally left open-ended, and there is no an official target duration.
Personally, I like the notion: “No less than two hours, no more than two days”.
If a User Story is not testable one can not verify if the original goal was achieved, thus, it can never be known if the User Story is “done.” But, when User Stories can be evaluated on a pass/fail basis, completion is finite, and there is little room for unexpected outcomes.
Note that test details may be in the form of “Acceptance Criteria” that accompany the actual User Story, and not contained by the User Story itself.
Reality Rules in Pragmatic Agile
As with all things Agile, these are aspirational qualities for you to keep in mind when writing your User Stories – they are not strict requirements.
In reality, it is unlikely that every User Story you write for a given project will satisfy the all of the characteristics described above. You may even find yourself on a project where you are required to write all of your stories in such a way that falls short of the complete INVEST mnemonic.
This can be due to many reasons:
- Special project circumstances and/or constraints
- Organizations that don’t fully embrace Agile
- Collaboration with non-Agile teams / 3rd parties
- Life is really hard sometimes
Or, maybe, your team has found some alternative approach that “just works better” for them. If that is the reality of the situation, then “reality rules”.
Regardless of how closely you adhere to the INVEST mnemonic, just by understanding and respecting each of its parts, the quality of your User Stories will naturally improve. At first, it may seem hard to remember what each of the letters in the INVEST mnemonic stand for, but you’ll be surprised at how natural it will become once you start putting them into practice.
At Gorilla Logic, the INVEST mnemonic is just of many tricks which we’ve trained our Gorillas with to ensure that they remain Agile and Unstoppable.