In software development and product management, a user story is an informal, natural language description of one or more features of a software system. A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective. A user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement.
User stories are often recorded on index cards, on Post-it notes, or in project management software. Depending on the project, user stories may be written by various stakeholders such as clients, users, managers or development team members.
"User stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality" - Mike Cohn, a main contributor to the invention of Scrum software development methodology
Need an agile software solution for product backlog management? Visual Paradigm supports a powerful agile toolset that covers user story mapping, affinity estimation, sprint management, etc. It's powerful but yet easy-to-use, intuitive and, most important, AGILE.
Free DownloadRequirements always change as teams and customers learn more about the system as the project progresses. It's not exactly realistic to expect project teams to work off a static requirements list and then deliver functional software months later.
With user story approach, we replace big upfront design with a "just enough" approach. User stories reduce the time spent on writing exhaustive documentation by emphasizing customer-centric conversations. Consequently, user stories allow teams to deliver quality software more quickly, which is what customers prefer. There are quite a few benefits for adopting user story approach in agile development such as:
A user story is a lightweight method for quickly capturing the "who", "what" and "why" of a product requirement. In simple terms, user stories are stated ideas of requirements that express what users need. User stories are brief, with each element often containing fewer than 10 or 15 words each. User stories are "to-do" lists that help you determine the steps along the project's path. They help ensure that your process, as well as the resulting product, will meet your requirements.
A user story is defined incrementally, in three stages:
And these, although, are known as the 3C's - Card, Conversation and Confirmation. We will talk more about this later on in this user story guide.
The acronym INVEST helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a user story. If the story fails to meet one of these criteria, the team may want to reword it, or even consider a rewrite (which often translates into physically tearing up the old story card and writing a new one).
A good user story should be - INVEST:
When getting started with writing user stories, a template can help ensure that you don't inadvertently start writing technical tasks:
User stories only capture the essential elements of a requirement:
Here is a simple format of user story used by 70% of practitioners:
Role - The user should be an actual human who interacts with the system.
Action - The behavior of the system should be written as an action.
Benefits - The benefit should be a real-world result that is non-functional or external to the system.
Notes:
User stories are written in everyday language and describe a specific goal (what) from the perspective of an individual (who) along with the reason (why) he/she wants it.
In software development, the goal is often a new product feature, the individual is some type of end-user and the reason is the benefit that the user sees in the targeted product feature.
In the examples above:
It is not a rule but a guideline that helps you think about a user story by considering the followings:
Ron Jeffries, another of the creators of XP, described what has become our favorite way to think about user stories. A User Story has three primary components, each of which begin with the letter 'C': Card, Conversation, and Confirmation to describe the three elements of a user story. Where:
Card represents 2-3 sentences used to describe the intent of the story that can be considered as an invitation to conversation. The card serves as a memorable token, which summarizes intent and represents a more detailed requirement, whose details remain to be determined.
You don't have to have all of the Product Backlog Items written out perfectly "up front", before you bring them to the team. It acknowledges that the customer and the team will be discovering the underlying business/system needed as they are working on it. This discovery occurs through conversation and collaboration around user stories. The Card is usually follows the format similar to the one below:
As a (role) of the product, I can (do action) so that I can obtain (some benefits / value)
Note:
Conversation represents a discussion between the target users, team, product owner, and other stakeholders, which is necessary to determine the more detailed behavior required to implement the intent. In other words, the card also represents a "promise for a conversation" about the intent.
Confirmation represents the Acceptance Test, which is how the customer or product owner will confirm that the story has been implemented to their satisfaction. In other words, Confirmation represents the conditions of satisfaction that will be applied to determine whether or not the story fulfills the intent as well as the more detailed requirements.
User stories should be identified together with the stakeholders, preferably through a face-to-face meeting. User story is a requirement discovery process instead of an upfront requirement analysis process.
In the traditional requirements capturing approaches, system analyst tries to understand customers' needs and then prepare a requirement specification for the system in detail. This is not how the user story approach works. Instead of a documentation process, the identification of user story is more like a note taking process. We list the major steps for identifying user stories as following:
In a broad sense, there are six main states for each user story throughout a software project:
Through the communication between user and project team, user stories are found. At this state, the user stories have nothing more than a short description of user's need. There is no detailed discussion of requirements, no system logic and no screen design yet. In fact, the only purpose of user story, for now, is just for reminding all parties for a future discussion of user's request written in this user story (card). It is possible that the user story will be discarded in the future.
Through a discussion between different stakeholders, the user stories to be addressed in the next few weeks are decided, and are put into a time-box called a sprint. Such user stories are said to be in the to-do state. No detailed discussion has yet been carried out in this state.
When a user story is in the Discussing state, the end user will communicate to the development team in confirming the requirements as well as to define the acceptance criteria. Development team will write down the requirements or any decisions as conversation notes. UX specialist may create wireframes or storyboards to let user preview the proposed features in visual mock-ups, and to feel it. This process is known as user experience design (UX design).
After the requirements are clarified, the development team will design and implement the features to fulfill user's requests.
Upon the development team has implemented a user story, the user story will be confirmed by the end user. He/she will be given access to the testing environment or a semi-complete software product (sometimes known as an alpha version) for confirming the feature. Confirmation will be performed based on the confirmation items written when detailing the user story. Until the confirmation is done, the user story is said to be in the Confirming state.
Finally, the feature is confirmed to be done, the user story is considered in the Finished state. Typically, this is the end of the user story. If user has a new requirement, either it is about a new feature, or it is an enhancement of the finished user story, the team would create a new user story for the next iteration.
User stories is a useful way to build a better product backlog, one that is user-centric and describes software requirements in a practical, actionable way. But user stories on their own do not reveal the whole picture that can clue you in on the larger journey the user goes through from the moment that load an app until they reach their final goal.
A user story map can help us to arrange user stories into a manageable model for plan, understand and organize the functionality of the system systematically. By manipulating the structure of the map, we can identify holes and omissions in your backlog and interrelating the user stories in a meaning structure; helping plan holistic releases effectively that deliver value to users and business with each release. User story map allows you to add a second dimension to your backlog. Here are a few reasons you should consider using this technique:
Story mapping is a top-down approach of requirement gathering and is represented as a tree. Story mapping starts from user activities. A user activity should achieved a particular goals. And to complete an activity, users needs to perform the associated tasks. And these tasks can be transformed into epics and user stories for software development. Typically, user story map consists of 3 levels: User Activities / User Tasks / User Stories. For enterprise scale projects, perhaps a 4 levels structure may be more appropriate by introduce Epics in the third level.
User Activities - They are laid out in the second column. This are major objectives that the system must support, with tangible business outcome. The entire row forms the backbone.
User Tasks - Each of the user activities is broke down into a set of related user tasks called narrative flow. The entire row forms the walking skeleton)
Epics / user stories - Each of the user tasks is broken down into Epics / User Stories underneath directly the user task that the feature realizes. Depending on the complexity of your projects, your team may choose the 3 or 4 level of story map which is more appropriate to you as mentioned above.
Visual Paradigm Story Map supports both 3 and 4 levels of complexity for you to cope wide variety type of projects.
Use a separator to identify slices of tasks that users might use your software for to reach their goals. The smallest number of tasks that allow your specific target users to reach their goal compose a viable product release as shown in the Figure below:
If you want to develop a story map like this one, please check Visual Paradigm's story mapping tool.
Just like many other software development methodologies, if you apply user story properly in your software project you will be able to produce a quality software system plus to win the trust and satisfaction from customers. Here are some points that you need to keep in mind when using user story:
Want an agile tool that can manage your scrum projects well? Visual Paradigm features a user story mapping tool, Affinity Estimation tool, sprint management tool, and task management.
Try it Free
