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:
- So that...
- I need...
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.
- "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"
- 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.