For the next few days, it’s going to be head down writing user stories for a new feature. In order to get into the right mindset, i’ve been spending some time reading and re-reading some articles related to how to write a successful user story. there is a lot of information out there, but most of it boils down to the simple sentence of:
As a [user role], I want to [goal], so that I can [reason].
As such, the principle is very clear, however the output isn’t always as clear, unless of course you were the person writing the story. One thing that most articles and how-to’s stress is how important it is to discuss each user story with the entire scrum team. This conversation is the key to ensure understanding for all parties. The product owner can be sure that the stories are understood and also benefit from the feedback of the testers, developers and scrum master, to improve the story writing in future. The team of testers and developers can use the discussion time to ask any questions, clarify and start jotting down ideas on technical details and testing approach for the feature.
In my projects so far, unfortunately we haven’t spent that much time on discussing user stories, particularly for our last effort, as we actually handed over the user stories and all of our other output to another scrum team. Not having that discussion definitely caused some confusion and a certain amount of re-work for the scrum team taking over. As they were not involved in writing the stories and we didn’t have the dedicated time during sprint planning to discuss each of them, there is a level of uncertainty as to what each story actually means. Reading over the stories again myself, I was fairly sure that they were pretty clear, but then again, I wrote the majority of them, so obviously I would understand.
I think my take away after that exercise is that I need to be a lot clearer in my user stories; make a bigger point of specifying the who for each user story, whether there are multiple users or not, and most importantly really stress what the benefit or the why will be. It seems that as soon as people know the why of a story, they are much more likely to understand the what. And considering that we are working agile – whether their interpretation of the what matches my own doesn’t really matter, so long as it serves the purpose of the why for that particular who.
Having worked in waterfall for such a long time it still feels a little strange to not specify details upfront and even with all my good intentions to focus on the why, the output of my user stories was still firmly centered around the what.
I suppose, at least I notice my own mistake, so this next time, I can do better and truly focus on the who, the what and especially the why of the story.