User Stories
What is a user story and how I try and make gathering them less awful.
This is an entry in my series of post about techniques that are useful to Business Analysts. I am using the IIBA’s BABOK V3 (2015) as my source for what a user story it. It is worth keeping in mind that I come at this a as a IT Business Analyst from a consultancy that works on ERP systems.
A user story is one or two sentences that captures what is needed out of a solution. They take a the view of what a user would be trying accomplish when they use the functionality.Users stories are used to define what features should be included in a solution. They are not intended to be complete requirements which makes them more useful when trying to scope a project rather then an explicit list of what needs to be built.
User stories are suppose to be short and focused on a single activity. Having them focused is very useful as it allows them to be used as a checklist to confirm that the solution meets the needs of the users. I have found this useful as if they are too broad then there are times where they can be half met which makes it difficult to communicate progress to stakeholders.
User stories are not something that works for every project. When the project is strictly integrating data between two systems there are no real “users” of what is being developed making user stories not useful. They are useful any time a business process or product is user facing.
Creating a User Story
One common way that user stories are defined is "As a <who>, I need to <what>, so that <why>." (BABOK, 20215). This is a great way to ensure that all of the parts of a user story are capture that is short, but sticking rigidly to this structure leads to any discussion about a new feature being a little stilted and can cause people to disengage.
One of the best ways that I have found to run a meeting where you are trying to get user stories is to have it be more of a discussion rather than having them speak directly in user stories. I accomplish this by preparing questions for what information I want, but not just reading the questions and having the business users answer them. Instead try to start the conversation with a lot more of an open ended question. I find this leads to better discussions which can unearth desires that were not known before the meeting. Having this mind set also let me adjust to how the discussion has been going and I find that less people disengage from the activity compared to just reading the questions.
This method does not result in being told the user stories. The user stories are created from the notes from the discussion at a later time or the notes can be structured as user stories.
Use stories are a useful way to get people to focus on functionality that provides value to specific users but the common way of getting them is not the best for most users.