Although various companies and their agile teams might use their own “agile” format of story writing, a very popular and common way of agile story card writing is to follow three lines that mentions who is the user, what the user wants to do and what is the business value of doing that action or achieving that goal.
This is in sharp contrast to most of the waterfall model requirements writing where most of the time the requirements are written with System of Application in view rather the users in the view. It’s not uncommon to see those waterfall model requirements to be documented as “System shall…”.
One of the reasons behind the success of the agile model of programming is the care for the user role and the business value more than the waterfall one (despite the pros and cons of each type).
The diagram above shows a typical format of a agile story card.
When you are writing the agile stories, what features do you consider to make them good? There is this INVEST principal, which guides you to analyze if your stories are good enough. The acronym INVEST can be expanded to very important features that an agile story needs to have. Although achieving this might not always be possible, it’s the best way that works on most of the cases.
Here is what INVEST means.
I – Independent (your stories should stand alone so that it can prioritized as a next work)
N – Negotiable (Stories should be negotiable – should be brief and allow the finer details later)
V – Valuable (Story should have value to the customer. Too much technical stuff without business outcome is not a good story)
E – Estimable (Story which are good are the ones whose boundaries are clearly defined and can be estimated. Vagueness should be removed.
S – Small (Should be small enough to fit into one iteration)
T – Testable (There is clear expectation, acceptance criteria so that testers can test it when the work is done).
These are the guiding principals, not the standards.