Jira has been built from the ground up for agile developers, so it’s only natural that the platform has features for creating and working with user stories. Jira makes it fast and easy for agile teams to work with user stories, seamlessly fitting them into workflows and sprints.
User stories aren’t product specifications, though. Instead, the practice of focusing on user needs and experience is about putting the human element first.
Here’s a complete guide to how to make the most of Jira’s User Stories features and how to avoid common pitfalls.
What is covered in this blog post:
- What are user stories, and what are they used for?
- How do Jira user stories fit into agile?
- How to create a new Jira user story
- Best practices and tips for user stories in Jira
- Conclusion
What are user stories, and what are they used for?
User stories are descriptions of product functionality as seen from the perspective of the product’s users. They shouldn’t go into detailed specifics about the feature or use technical terminology, but should briefly outline what is intended and how this will serve the user. Indeed, user stories don’t describe an actual product feature, but they represent a desired end goal. And the key thing about stories is that they put human beings – the ultimate end users – front and center in the development process.
Anyone, including both users and individuals in the organization, should be able to read and understand them. And depending on the use case, a “user” might refer to a member of the team, a general user of the system, or a consumer.
Stories should serve as a compass for the dev team, laying out the who, what, and why of the project as well as its fundamental objective and the value that it will deliver. The team can then use this as a framework to build on, defining features and functionality as they go. All of this should keep the team aligned and moving forward in the right direction.
How do Jira user stories fit into agile?
User stories comprise the smallest working unit within the agile framework – scaling all the way up to the level of Epics and Initiatives. In agile, Epics comprise larger pieces of work and consist of multiple stories, while Initiatives bring multiple Epics together into a single larger project.
In Kanban, teams assign user stories to the backlog and then work through them. In scrum, user stories are burned down over the course of sprints. Stories can hence assist with sprint planning and the refining of workflows. Stories ensure that throughout the process, the user experience is always the foremost consideration.
How to create a new Jira user story
Typically, user stories are created by the product owner or product manager and are a refined version of a request from a real user (whether supplied directly or as a result of research work into product usage and desired functionality).
User stories should broadly adhere to the following pattern: “As a [persona], I [want to], [so that].” → “Who wants to do … What … Why”
The “what” shouldn’t refer to the UI – so it shouldn’t describe buttons or layout features, but should state the user’s fundamental need. The “why”, meanwhile, should explain the underlying objective behind the user’s want. Customers, for example, might want to see shipping dates, so that they can see when items will arrive – achieving a more satisfying purchase experience and encouraging purchases.
To create a user story in Jira:
- In a Scrum or Kanban project, click the “Create” button
- From the “Create issue” screen, select the “Story” issue type on the dropdown
- And then fill out all the information you need – and you’re done!
Just like other issues, you can also create stories from the backlog, board view, and project page, of course.
The story-creation process should consider:
- The original user story – as provided by actual users
- The user definition – laying out precisely who the user actually is or if there are multiple user types
- The completion state – typically achieved when the user is able to complete the desired action
- Defining steps – potentially breaking the concept down into multiple stories, defining each step along the way in a more complicated process; this is particularly the case where more complex stories need to be broken down so that elements that are too large for a single sprint can be addressed and resolved on a sprint-by-sprint basis
- Specifying tasks – establishing the tasks needed to facilitate the user story and who these will be assigned to
- And lastly, the business value that the user story delivers
Once ready, the story can then be added to the backlog and submitted for review in a sprint meeting. The story is visible to the whole team, so it can be assessed and discussed.
At this point the requirements of the story can be defined, laying out the technical details of what is needed, allocating actionable working tasks, and setting out the practical steps required to implement the functionality. The team may also want to loop in stakeholders and users as the story is expanded upon and refined to ensure that what is built matches what is intended.
The team can then schedule stories for the next sprint or the following iteration, potentially using scoring systems such as planning poker to allocate resources or otherwise visually represent the stories so that they can be prioritized. You can also set about assigning the relevant tasks to team members and setting due dates within the sprint or iteration. If needed later, stories can be tracked from the backlog or via Jira’s search functionality.
Best practices and tips for user stories in Jira
User stories form a fundamental building block for agile development projects, so it’s important to make sure that they are created on a logical and consistent basis.
User stories:
- Should be able to be completed in a single sprint; if the story is too complex, it should be broken down into multiple stories, which can be completed over multiple sprints.
- Should be accessible and describe the desired functionality in broad, non-technical terms.
- Should be based on real user experience and should deliver tangible business value.
- Should be specific enough that the need described can be fulfilled – stories that are too vague (“make the interface more accessible”) cannot be demonstrably achieved.
- May need inspiration over time. For example, if multiple customers request the same functionality, then it’s worth taking note of this. Equally, team members might suggest ideas that aren’t suitable for the backlog at present but might be in the future – so it’s worth holding onto ideas and saving them for later.
- Can host relevant supporting material in Jira, using attachments, links, and notes – pointing to any material that may assist the team, without distracting them.
- Shouldn’t describe UI features, but should lay out the underlying requirement, which the team can then assess.
- Shouldn’t always be brought to the team – if the need described in the story isn’t practical, or it doesn’t fit the product, then it can be assessed and discarded.
- Shouldn’t overwhelm the backlog – stories that aren’t relevant to the product or that aren’t likely to be addressed in the near future should be pruned to prevent the backlog from becoming unusable.
Conclusion
Jira User stories put the human element at the center of the agile development process, providing answers to the questions of who wants to do what and why. This ensures that the dev team is serving the specific needs of their users and delivering real value.
When deployed effectively, user stories can provide a North Star for the team, encouraging collaboration, keeping the team aligned, and driving efficiency by focusing the team on business value and specific customer needs. And what’s more, all of this is made fast and easy to deploy with Jira.
Recommended Reads:
