Everyone writes user stories differently
Kainos has a culture of building communities and a few times a year consultants and managers will get together to share experiences from various projects. Sounds boring right? but the name of the game is “collaboration” and there is no better way of sharing knowledge. The days are fully interactive and I come away with my head buzzing and a renewed energy to take back to my project.
Enough about community days though, let’s get to the good part and I’m not talking about the vast amount of coffee and treats that are consumed throughout the day. I’m talking about creating user stories
Creating user stories was one of the many topics we discussed the last time we met. To help get the discussion started four Product Managers got up to present their teams user stories to the group.
4 teams 4 different formats for stories
Each story had the basic format of, As a…. I want …. So that …. Good start, but when we got to the acceptance criteria and additional information ( such as questions to be asked at the next user insight), everyone seemed to have a different take on this. I began to think this should be consistent but then realised that each of these projects were different, some were online digital services others were legacy integration projects, of course they were going to vary in the additional information that was needed.
Keeping things simple
For the acceptance criteria, some were written in the BDD style, others in the “I can, I can not” style. Again I thought about this and realised that this is what the teams themselves had decided and the main point was that the acceptance criteria was clear and could be understood by all team members.
When I read the acceptance criteria I could understand what the objective(s) were being delivered by the stories being presented and I had little or no understanding of 3 out of the 4 projects so this was a good sign. I should admit at this stage that while I’m not a fan off BDD, mainly because I’ve seen the consequences of it being implemented very badly in user stories, if written properly it works well for the teams who use it.
If you can’t explain it simply, you don’t understand it well enough. — Albert Einstein
Avoid solution specific detail
I also loved the fact that every presenter mentioned that they did not outline the solution within the acceptance criteria of stories and avoided this at all costs. If you write the solution into the acceptance criteria you will have to update the story every time this changes, and from experience, that can mean a lot of updates.
Persona lead stories
One project had persona lead user stories which I’m a big fan off. For me, including the Persona allows the team to understand who this story is benefiting and its keeps them focused on delivering a solution which will meet that users needs.
Writing a story “As a PO ..” may be of use in some scenarios but I’ve always avoided them as it smells of a pet feature or one that is ill thought out.
Where do you write them
Some stories were on physical cards others were in tools (Jira, Mingle). The project where the stories were written on physical cards attracted the most interest. This worked for the team because they are small and co-located. A story was recalled by an attendee where someone opened an external door on a hot summers day and the story cards which were stuck up on a wall started to flutter, panic quickly spread amongst the team but with some quick teamwork disaster was averted. Shortly after this they decided to move their stories into a tool. Again there is no right or wrong way, having physical cards has very obvious advantages like keeping acceptance criteria succinct and encouraging the right conversations but wont always work in the instance where the teams are not co-located. You will also need to address any concerns upfront that senior management might have around the accuracy of reporting, internal/external audits, and risk off loss or damage to cards and the sequence they are in.
Who should write them
Later on in the day one of the open spaces was around who should write user stories. Some people said the entire team, others said PO and others said BA’s.
We came to the conclusion that the BA and PO were there to ensure the problem being addressed was clearly articulated. The stories would be initially written down on the story card by them, this could be as little as a title and a few sentences to outline the problem.
The BA’s and PO’s would then take this into a team refinement session where the team would write the acceptance criteria together and potentially split stories out further. Having one person write a story means silos and we all know silos are bad and need broken down as quickly as possible.
A user story is a promise of a conversation
So what did I learn
My take away from the day was that every team creates stories differently but the key thing is collaboration, and only once you get this working can you finally start moving away from up-front requirements specification and release the full power of user stories.