A User Story is a brief description of a customer’s need. It has a basic structure:
As a <…> I want <…> so that <…>
We would like to believe that writing user stories in this format is an easy task. However, I am sure that you agree with me that when you are new to Agile it is not straight forward to “downsize” requirements to the “Story” Level.
Getting your Story straight is essential for agile teams to be effective. It requires practice and following a set of basic rules to avoid stories from turning into “Drama” or even “Horror” stories. 🙂 Based on experience, I suggest starting with the “so that…” section. I consider this my first step because this is the “Why”, meaning that it describes the business value of the story. If you are NOT able to vocalize the “WHY”, then this could become a “Mystery” story that you may want to re-consider writing at all.
Once you know the reason WHY you want the story, then you should write the “WHAT”. If you are a Product owner, keep in mind that you should avoid the “how”. Give your team a bit of an “Adventure Story” but keep in mind that you have to have a solid business purpose (why) that will frame them to the story goal.
Then, state the “Who”. It is easier to derive the “who” if you have a solid understanding of the WHY and the WHAT. This should be a specific user, persona or role that is properly aligned with the intent of the story. Using “Product Owner” or “Team Member” or any other non-real product related role will transform your story into some kind of “science fiction” story. If your story contains a strong business value proposition, then chances are that “Product Owner” or “Developer” will not jive ell with it.
Finally, describe the acceptance criteria. It should be one or more concrete statements that glue all the previous elements together, the “what”, the “who” and the “why”. If you miss this part, then you have no way to verify that the work was done, and you are probably writing a “Fantasy” story that will end up with lots of “sagas” and “repeats”.
As stated before, good stories improve with practice. Keep practicing and ask these questions with each of your Stories:
– What is the Business Value? Would a Stake Holder understand and recognize the business value when reading the “so that” section of your story?
– Is the WHAT at the right level? Is it clear and aligned with the WHY?, Do I have too many details and am I getting into the “How?”
– Is the “User/persona/role” identified? Avoid the use of “Product Owner” or “Developer” or “Team Member”
– Do you have Acceptance Criteria? Is it concrete and complete so that I will be able to personally see evidence that the work was done?
I hope this post makes sense and helps somebody creating their new Action stories.
Versatilista 