Reading Time [est_time]
Traditional product development creates functional barriers that separate the product developers from the users of the product. The reason user stories were used in the Extreme Programming was to connect the product developers with the real-world stories of the customers and users. Stories help the developers understand the pain areas of the users and the opportunities of delighting the users and making them feel awesome.
Today, for most of the teams, User Stories have just become a form in an electronic tool which someone should fill in so that it can enter the Sprint planning, get developed and shipped. Instead of learning the art of storytelling, Product Owners and Teams are often found searching for the perfect ways to fill the User Story templates . In this process, the real intent of the user stories is somewhat lost.
To benefit from the User Stories, teams must go back to the original intent of connecting with the users and learning the user’s latent pain and gain areas, understand their emotions and how a product can help make users’ life easy.
Medtronic, a Minnesota-based medical technology company has institutionalized the art of this storytelling. Every year at the annual employee gathering Medtronic brings in users to share their life transforming stories with all the employees. Leaders at Medtronic use every opportunity to share User’s Stories in their messages. They use both positive and negative stories to reinforce to employees its guiding principle of “Customers First”.
User Stories help product developers understand the impact they have on the people they serve. Understanding the story of the users also empower the developers to find the best way of solving a challenge.
User Stories act as a bridge between users and product developers.
User Stories are most popularly used today in the Agile software development field particularly with the Scrum Framework.
Often index cards are used to write User stories that focus on the benefit to the user. It consists of one or more sentences in the everyday language or the language of the end user (user perspective) that captures description of the story and benefit to the user. It also captures criteria for its acceptance. It helps in shifting the focus from writing about requirements to discussing about the benefits to user(s).
User story card captures the ‘why’, ‘who’ and ‘what’ of a potential feature or hypothesis in simple and concise way. Often limited to detail which can be hand-written on an Index card.
When used with Scrum Framework, a user story should essentially will be small enough so it can be delivered within one sprint and valuable enough so that a user can use it and provide her feedback.
Bill Wake came up with INVEST acronym to emphasize what makes up a good User Story:
I – Independent
N – Negotiable
V – Valuable
E – Estimable
S – Small
T – Testable
User stories are easiest to work with if they are independent i.e. it shouldn’t overlap in the concept. The team may creatively break the technical dependencies as often as possible to create independent stories.
A good user-story should be negotiable. It should capture the essence of the requirement and not the detail hence allowing the team and the Product Owner to negotiate the scope and approach of developing it.
A good user-story needs to be valuable to the customer. It should clearly answer the “why” so the resulting product increment becomes valuable for the user an essential condition for a user to be able to use the product and share feedback. This criterion also draws attention to avoid creating stories that does not deliver customer value such as – story that only focuses on single function such as database work, or platform enhancement or only UI tasks.
A team should understand the story well enough to be able to estimate how much time, effort will be required to deliver a testable and acceptable feature. The estimates allow the Product Owner to forecast the budget and delivery timeline.
A good story typically represents at most a couple of person-days’ worth of work. If the work exceeds a week, the team may have difficulty in delivering a user story hence running into the risk of not delivering it within a sprint. Delay in delivering the user story delays the feedback again increasing the associated risk of failure.
A good user story is testable, i.e. everyone should well understand how the completion of the story will be verified by a user or a proxy of the user that is a Product Owner. It should be understood well enough so that tests can be written and performed. Acceptance Criteria helps establish this user acceptance testing. In case if a story can’t be tested, its scope should be reframed in a way so it can be tested.
Creation of user-story
Once I was coaching a team that was transitioning from traditional product development to implement Scrum. It was their first day after I facilitated a 3 day Agile Team Boot camp for their entire team. Their Product Owner – Jane was excited to get started with user stories and creating their first product backlog. They did have the knowledge that it’s going to be different from their usual approach of writing long multi-page requirements documents. The knowledge had to be put in to practice. Jane and the team members had to cautiously put in efforts to get away from their way of thinking and behaviour of writing long requirements documents and dumping those to their shared document repository and hope that everyone on the team will read, understand and deliver product as intended. That was never the case.
At the beginning of the working session, we did a 2-minute activity to recall points they learned about the User Stories during the boot camp. During this activity, Sri one of the team members stood up and recalled:
A User Story card is a promise for a conversation
Not a mini requirements document, not a requirement itself, a user story card is a promise by the Product Owner for a conversation with the team members when the team picks up a story for implementation. Alistair Cockburn, shares how it was done by the Chrysler C3 team in 1998 when it was first used:
A programmer would pick up a story card, walk over the Customer, and say, “Tell me about this”, then go over and program it up, and come back again and ask, “Like this?”, and back and forth until it was done. The ‘requirements’ were never written down, they communicated in discussion and feedback.
Not writing down requirements felt uncomfortable for Jane in the beginning. Jane and the team members collectively formulated and wrote (new) user-stories. Stakeholders were invited to contribute to writing user stories based on their needs. During the workshop, the intent was to write down high level 1-2 line description of each user need, feature, and hypothesis. There were lot of queries and as we navigated through the workshop, each query was discussed, explored and addressed.
Below I list some of the common User Story queries that I’ve heard.
One of the common way teams write user stories is in the form of:
As a <user type>, I want to <some goal>, so that <benefit>
A crisp user story should answer the following three questions:
- As a <type of user>: Who are we building it for, who the user is?
- I want to <action>: What action the user should be able to perform, what is the intention?
- so that <benefit>: Why are we building it or what value it brings to the user?
Three common user story errors to avoid
- Missing User: If a story doesn’t specify the user, it is most likely going to miss the user’s story. If there is no user and no story the result is far from being a User Story. As simple and silly as it sounds, this is one of the most common error teams make. You may see it in the stories that say something like – As a DBA, I want to….., As a System Admin, I want to….., etc. It takes cautious effort on part of the Product Owner to pro-actively connect with users, listen to their stories and bring them to the team. Each user story may specifically address one user or a group of users with similar needs. Get this one right and you are on the track.
- Too much detail: This one is again resulting from the old mindset of writing down detailed requirements. The Product Owner tries to write every detail in the user-story forgetting the fact that a user story is a promise for a conversation not the requirement itself. Too much detail often dilutes the purpose of the User-story and hinders the team members from having the conversation with the product owner. Writing down too much detail in the user story can conveniently hide the fact that users’ input, users’ story has not been considered before formulating the user story. Necessity to write down too much detail may also be an indication of lack of sufficient trust in the environment – often prevailing in the cases where the Product Owner and the team members work from different geographies.
- Answers ‘how’ and misses ‘what’: A user-story should define what the product should do and what benefit should it yield not the specific approach of how it is achieved. The approach to achieve a user story’s intended outcome should be left for the development team to identify. After the high-level task of writing user stories was completed, the next task was refinement. To refine user stories, split larger stories, add description, write acceptance criteria etc. The team invited the Scrum Master to setup a follow up session to refine the user stories.