In Agile projects we often break the work into stories. These fall into two categories:
- User story – describing a tangible addition to the system from the user’s point of view
- Technical story – describing a usable capability of the system under the hood
It’s important that these stories follow the INVEST pattern. In particular, though, stories should be sized appropriately, with clear cut test boundaries.
Here are some examples of things that AREN’T stories, or make execution of stories much harder:
- The LEVIATHAN – possibly a feature or epic, or possibly just an accidental let’s make the world this is too big to define clearly and can blow up to become a super massive BLACK HOLE
- The shard – this might be a technical task one does in pursuance of the story, or may even be the name of one of the sub-components you build while doing one of the tasks, it’s too small and impossible to explain to a stakeholder
- The abstract concept – this is something we need to be, or need to care about, but it’s not possible to treat it as an actionable
- The cross-cutting concern – this is a capability or task that seems to apply all over the place, it’s unlikely that we can do all places in one go – perhaps it’s really part of the definition of done, or something that needs to be turned into stories for each touchpoint
- The chain-gang – this is a sequence of increments, each of which depends on its predecessor. They can only be constructed by a single developer/pair, and each has the assumptions of the whole on it. They’re not necessarily wrong, but they sure make things harder when they’re in the majority.
You may know some other story anti-patterns, please share them in the comments.