Wouldn’t be nice if our user stories started with some great lines and got our attention rather than just the dull monotone of “As a user, I want…”?
“A long time ago in a galaxy far, far away …”
“Who is John Galt?”
I wish I could borrow the famous opening lines and make more interesting user stories like – “In a Bank far, far away, a user Manageritus wants an ability to approve a housing loan sanctioned by one of his direct reports. “
Wishful thinking. Yes, it is.
But, if written correctly, the practical format of a user story is pretty engaging too –
“As a <user role>, I want <this objective accomplished> so that <I could get this benefit> with <the acceptance criteria> given <detailed context“>”
It primarily solves few key aspects –
1. Who are the actor(s) for this story?
2. What is the intent of this story?
3. What value/benefit the actor would get once the objective has been accomplished?
4. How would this story be gauged “done” i.e. acceptance criteria? The acceptance criteria should also cover the non-functional aspects.
There are few principles one need to keep in mind while writing user stories.
Independent – One should strive to write stories that are not dependent on other stories. This aides in better estimation and planning.
Negotiable – The user stories should only capture the gist of desired functionality. It should acts as a catalyst to facilitate a “Conversation” between the Scrum team and Customer about the specifics of the user story.
Valuable – The user story should provide some real value to the actual user of the product.
Estimable – The Scrum team should be able to provide a fair estimate for it. It doesn’t have to be exact but a good-enough estimate so that the team could prioritize and plan the implementation. Please note that if a story is too big to be estimated then it needs to be broken down so that one could comprehend the size of the functionality better.
Small or Sized appropriately – One should split user stories(while retaining their user value) so that they could be completed within an iteration of 2 weeks. Different teams have different perspectives about it but we tend to keep our stories to be NOT more than 5 days of development effort.
Testable – This is absolutely critical for the story to be in “done” state. This also aides the developers to write good unit test cases so that they know if they have completed the objective of the user story.
Thus, in short INVEST in your user stories. It would go a long way in making a good product and streamlining product development lifecycle.