The INVEST methodology in agile software development was created by Bill Wake as a reminder of the characteristics of a good user story.
There is a lot of guidance on the mechanical structure of how to write effective user stories to guide your software development process. Three typical components that make up a good user story is the Title, the Description, and the Acceptance Criteria. We all know a good title structure must make clear WHO (role) performs an ACTION (objective) to satisfy a NEED (motivation). It’s simple, concise, and easy to understand. A huge leap forward from the waterfall days that produced bloated specifications that took a standards group 26 pages to articulate how to write a software requirement.
While interesting, that’s not what we are covering in this writing. Let’s assume you know the art of gathering requirements, and you understand the ‘structure’ of how to write it. This guide steps into a more subjective area on how to determine if a user story is a good one.
The INVEST methodology in agile software development was created by Bill Wake as a reminder of the characteristics of a good user story. This approach can be used in both an agile and Kanban backlog.
User stories are best to work with if they are independent. That means that the user story can be worked on its own and not overlap with another. In a perfect world (which never always happens) you want to be able to schedule and implement user stories in any order.
A good story is negotiable. The user story should not be a dictation or a contract for features; rather, the details will be co-created by all team members during the backlog refinement and development phases. A great story captures the essence of what is needed, not the exact details of how. Over time, the user story may acquire notes, test ideas, etc., but you don't need these to prioritize, point or schedule the user story.
The user story needs to be valuable. It does not matter the value to just anyone, it needs to be valuable to the customer. This becomes very important when splitting stories. Think of a whole story as a multi-layer cake, e.g., a network layer, a persistence layer, a logic layer, and a presentation layer. When we split a story, we’re serving up only part of that cake. We want to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers. Developers often have an inclination to work on only one layer at a time (and get it “right”); but a full database layer (for example) has little value to the customer if there’s no presentation layer.
Making each slice valuable to the customer ensures that you are keeping to this mantra. You need to continuously evaluate what you are prioritizing will bring value to your customer/stakeholder.
A user story cannot be prioritized if it can be estimated. When placing stories in your backlog, the Product Owner must ensure that there is enough information in the user story so that a team can pick it up and estimate the ticket. If there is not enough support documentation/information, the ticket is not estimable, the team cannot work on it, and it won’t bring value to your client/stakeholder.
The definition of what is estimable will vary from team to team and should be negotiated. A more mature team that is aware of how the software was built and the capabilities within it AND understands the vision the Product Owner is aiming for, can estimate a user story with much less information than a more junior team that is new to the codebase or company. Also, a larger story is harder to estimate, ensure to break them down into smaller consumable chunks.
Good stories tend to be small and consumable. Stories typically represent at most a few person-weeks worth of work. Above this size, and it seems to be too hard to know what’s in the story’s scope. Saying, “it would take me more than a month” often implicitly adds, “as I don’t understand what-all it would entail.” Smaller stories tend to get more accurate estimates.
Story descriptions can be small too (and putting them on an index card helps make that happen). Alistair Cockburn described the cards as tokens promising a future conversation. Remember, the details can be elaborated through conversations with the team.
A good story also has to be testable. That means that the team must have a good understanding of the ask. Writing a story card carries an implicit promise: “I understand what I want well enough that I could write a test for it.” Testability has always been a characteristic of good requirements; actually writing the tests early helps us know whether this goal is met.
If the team does not have enough information to write a test for the user story, then there was not enough information for the team to develop a solution. A team can treat non-functional requirements (such as performance and usability) as things that need to be tested. Figure out how to operationalize these tests will help the team learn the true needs. Make these types of tests as part of sprint checkout to ensure that you maintain top performance and usability for each iteration.
I.N.V.E.S.T. is something to keep in mind as you are adding user stories to your backlog. As you look to implement these practices, everything does not fit neatly into each category. These are guidelines for you to follow and to be broken to ensure your team is set up for success.
Possibly, the ultimate sign of a good user story is one that generates a conversation between team members. Through dialogue, clarity is achieved. Team members gain an understanding of the why and then collectively begin to construct the how.
