I have received and given training in what makes a "good" Agile story many times and seen many many more story cards that fill me with a sense of dread.
A good healthy Agile project needs people to not only understand what they need to implement, but also why and who for. I know this has been written on the internet hundreds of times but it is worth writing again:
Now these are business headings (or Interaction Driven ones depending on what you read):
"So that" I can use a credit card online, "as" a web channel customer, "I need" a screen to enter my credit card details with"
Anyone picking up the story card can immediately see what it is all about, and if they turn it over they should get a set of acceptance criteria that define the "how":
"Must be able to input card name, long card number, expiry date, and csv number"
In writing cards from a user perspective it is easy to weigh up their necessity and business value as a part of backlog prioritisation and brokering, also as every card is effectively a placeholder for a conversation it gives detail as to who to go to talk to if things are not clear.
The worst stories that will quickly kill an agile project are technical ones, they should be forbidden:
- "So that I can index the database as a DBA I need..."
- "So that I can edit the codebase more effectively as a developer I need to install XYZ tool"
- "So that my class structure is better formed as a software engineer I need a book on Python"
As there is no way in seeing business value in technical stories then there is no way any product owner can "support" a story or indeed prioritise it over other features. These cards should never be written and anyone who says they can't write a business story relating to a technical task needs asking, why are you doing the technical task then?
- Do - put something precise in each section that demonstrates the business value and pick a proper person or user group as the "As"
- Don't - write technical "So that”s or "I Need"s, or equally bad "a developer" "a user" or "a manager" etc in the "As"
Also, work with the product owners and BA’s to come up with a good “smart” set of acceptance criteria to go on the back of the card as these drive the whole TDD element of the Agile development process.
And finally for everyone who says you've got to put technical stuff somewhere; correct - it goes on the Task cards that underpin the stories, but these are only defined within the sprint Backlog, once the user stories have been selected to play in a sprint.
Happy story writing!