In Agile, we think of requirements coming in the form of user stories. Usually the structure of a user story is best described as below:
Title (one line describing the story) Narrative: As a [role] I want [feature] So that [benefit] Acceptance Criteria: (presented as Scenarios) Scenario 1: Title Given [context] And [some more context]... When [event] Then [outcome] And [another outcome]...
This structure is not mandatory, but it has been proven to work on many projects of all shapes and sizes.
We don’t expect customers or users to view the system the same way that programmers do; stories act as a medium where both sides can agree enough to work together effectively.
But what are characteristics of a good story? The acronym “INVEST” can remind you that good stories are:
- I – Independent
- N – Negotiable
- V – Valuable
- E – Estimable
- S – Small
- T – Testable
Independent
Stories are easiest to work with if they are independent. That is, we’d like them to not overlap in concept, and we’d like to be able to schedule and implement them in any order.
We can’t always achieve this; once in a while we may say things like “3 points for the first report, then 1 point for each of the others.”
Negotiable… and Negotiated
A good story is negotiable. It is not an explicit contract for features; rather, details will be co-created by the customer and programmer during development. A good story captures the essence, not the details. Over time, the card may acquire notes, test ideas, and so on, but we don’t need these to prioritize or schedule stories.
Valuable
A story needs to be valuable. We don’t care about value to just anybody; it needs to be valuable to the customer. Developers may have (legitimate) concerns, but these framed in a way that makes the customer perceive them as important.
This is especially an issue 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 supports pay-as-you-go attitude toward infrastructure.
Estimable
A good story can be estimated. We don’t need an exact estimate, but just enough to help the customer rank and schedule the story’s implementation. Being estimable is partly a function of being negotiated, as it’s hard to estimate a story we don’t understand. It is also a function of size: bigger stories are harder to estimate. Finally, it’s a function of the team: what’s easy to estimate will vary depending on the team’s experience. (Sometimes a team may have to split a story into a (time-boxed) “spike” that will give the team enough information to make a decent estimate, and the rest of the story that will actually implement the desired feature.)
Small
Good stories tend to be small. Stories typically represent at most a few man-weeks worth of work. (Some teams restrict them to a few person-days of work.) Above this size – 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). Remember, the details can be elaborated through conversations with the customer.
Testable
A good story is testable. Writing a story card carries an implicit promise: “I understand what I want well enough that I could write a test for it.” Several teams have reported that by requiring acceptance tests before implementing a story, the team is more productive. “Testability” has always been a characteristic of good requirements; actually writing the tests early helps us know whether this goal is met.
If a customer doesn’t know how to test something, this may indicate that the story isn’t clear enough, or that it doesn’t reflect something valuable to them, or that the customer just needs help in testing.
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.
For all these attributes, the feedback cycle of proposing, estimating, and implementing stories will help teach the team what it needs to know.
Conclusion
As you discuss stories, write cards, and split stories, the INVEST acronym can help remind you of characteristics of good stories.
The INVEST acronym is created by Bill Wake as per his website.
Leave a Reply