Last week I attended a Nashville Girl Geek Dinner workshop for the first time. My initial goal for attending was as a reconnaissance mission because I wanted to know more about the forum and the audience size of the workshop. You see, every month a different company sponsors the GGD and Ingram is sponsoring the July event and have asked me to be on the speaker panel. This is HUGE for me because I have a fear of public speaking. However, talking in front of groups is becoming a prevalent part of my job and I don’t want to turn down good networking opportunities because of a fear that I could probably become comfortable with if I put some effort into it. Part of that effort is to say, “yes” to things like being on a panel without giving myself time to get nervous about it. When I realized that the workshop was on “How to Write Effective User Stories”, I knew that it was for me because user stories come up often when talking to developers about new functionality for the system.
What’s a user story, you ask? Thanks to the workshop, I can break it down for you.
A story is essentially a person with a problem but a user story takes the person and the problem and adds the benefit that the user wants to achieve. User stories come up a lot when talking about agile methodologies on developer teams because a well written user story tells a developer, in everyday language, how the system should function to proceed with coding. User stories can be written using a basic formula to tell explain the “who”, “what”, and “why” of the change being requested.
“As a user, I want to do something, so that I gain this benefit.”
The user story we had for the workshop went like this, “As a business owner, I want a workshop so that I can express my ideas to developers.”
Good user stories meet the criteria of the INVEST mnemonic.
- Independent – the story is a single entity of work and is not dependent on another user story
- Negotiable – can be changed or rewritten as needed
- Valuable – provides value to the user
- Estimable – the time to complete the story can be estimated
- Small – the work to achieve the story can be completed in a sprint
- Testable – there are ways to verify the success of the story by way of acceptance criteria
Once we had an idea of what a user story was and how to write them, we were presented with a real world scenario to create user stories for. David Blutenthal, the CEO and co-founder of an app called Moodsnap – “a music storytelling network that combines music and images to spur discovery and deeper connections” provided samples of user personas that would use the app. Based on these personas, the attendees created user stories to solve problems that a real user might have or want to do with the app. It was motivating to hear people around the room come up with different user scenarios and issues and detail those in the form of a user story that could be taken back to a developer team.
At the end of the night, I not only got a feel for how the dinners are formatted, but I also left with a skill that I can take back to work to help create shared understanding between our business owners and the developers about changes to the platform. I’d call that a productive evening!