2024 Public Training Schedule
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- September 8, 2021
- Build in Small Batches
Continuing my series of posts based on Seven Strategies for Writing Better Stories from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, here is the next strategy.
Focus Stories on the What
The most important aspect of a user story is contained in the WHAT clause because that’s where the feature is described. It says WHAT the feature is supposed to do, which defines the primary success criteria for the story.
By simply stating WHAT the story is to accomplish, it gives the developers a clear idea of what the feature they need to build will do and also helps the team define their success criteria so they know when the feature will be done.
Acceptance tests are an important aspect of user stories and acceptance tests are drawn directly from the story’s WHAT clause. The WHAT clause of the story clearly states what the story is to accomplish so it can act as the basis for the acceptance criteria. When the story does WHAT it says it’s supposed to do then the story is done.
This means that each story is unambiguous. Every story should be unique and functionally independent from other stories, as much as possible. If we must have dependencies, then they should be backward dependencies and not forward dependencies. In other words, we should depend on features that we’ve already built rather than having to depend on features that we will build in the future.
Sometimes the WHAT clause of the story doesn’t match the WHY clause and what we say that we are doing doesn’t seem to be in alignment with why we want to do it. When this happens, it raises the opportunity for a different kind of conversation between the development team and the Product Owner or between the Product Owner and the users or customers or stakeholders.
Ideally, the WHAT of a story is in alignment with the WHY of a story and also WHO the story is for. Each story should address the needs of just one specific kind of user of the system. This helps us build systems that are more decoupled with a more complete feature-set for a particular set of needs.
There are various techniques around defining a cohesive set of user stories that address the needs of one type of user. For example, Jeff Patton has a technique called Story Mapping that’s very helpful for creating story themes that address a specific set of user needs. This kind of approach is useful for building a consistent set of features.
I find that the best WHAT clauses are the ones that are stated simply and directly. It’s okay to generalize in a story and miss some edge cases because remember, a story is not a specification, it’s simply a placeholder to have a conversation, and those kinds of details get worked out in the conversation with the team rather than writing them down as part of a document.
Remember, in Agile we say ‘barely sufficient documentation and we say this because documents are expensive to create and maintain plus the fidelity of written documents is far lower than a face-to-face conversation. When describing WHAT to build we should always describe it from the primary user’s perspective in the context of WHY they want it.
Previous Post: « See Stories as Placeholders
Next Post: Personify the Who of Stories »