An introduction to User Stories<\/h2>\n\n\n\n
Engineers love solving puzzles, implementing new technologies, and finding better, more optimized uses for their tech stack. However, at the end of the day, the software they develop is not a Rubic\u2019s cube. There\u2019s more to it than being a puzzle that needs solving. <\/p>\n\n\n\n
For example, let\u2019s say you have a couple of eggs, a pint of water, and a bit of flour. What can you make from this humble list of ingredients? Obviously a loaf of bread is the first thing that comes to mind. But you can also make noodles, pancakes, or crepes. <\/p>\n\n\n\n
Having a User Story that defines a user <\/strong>(a very hungry me, craving for something Italian), their intent <\/strong>(who wants to make some Puttanesca just like nana used to) , and the desired outcome<\/strong> (to enjoy a delicious, home-made meal) will steer you to the correct recipe – you will be making spaghetti.<\/p>\n\n\n\n Obviously, knowing why you do the things you do is helpful outside the kitchen. <\/p>\n\n\n\n If we were to go by the definition<\/a>, a user story is an \u201cinformal, general explanation of a software feature written from the perspective of the end user.\u201d They are helpful, because they give the team a clear definition of what needs to be done and why.<\/p>\n\n\n\n Most user stories follow a certain format: as a [type of user] <\/strong>I want to do [action] <\/strong>so that [benefit\/value]<\/strong>. <\/em>You can use it as a template or wireframe for writing your stories.<\/p>\n<\/blockquote>\n\n\n\n An example of a user story that follows this format will look something like this: As a user of the XYZ Bank banking app<\/strong> I want to temporarily edit the default credit card transaction limit<\/strong> so that I can make an expensive purchase<\/strong>.<\/p>\n\n\n\n This description of a user story adds a lot of context and clarity. The dev team understands who they are developing the software for, that person\u2019s intent, and desired outcome. Having your user stories follow this format also helps communicate your vision and progress to the business people. <\/p>\n\n\n\n Note: User Stories aren’t restricted to external end users. You can have user stories that are relevant to people within your team or organization who are dependent on something you\u2019ll be delivering. <\/em><\/p>\n\n\n\n It\u2019s also not that uncommon to have users who aren\u2019t even people. We\u2019ve had cases when we needed to write them from the perspective of a database, where the database substituted the user. These types of stories are commonly used in #research tasks. Just remember that the user – regardless of it being a person or an object – still needs to achieve something so the format of the story formula does not change.<\/em><\/p>\n\n\n\n Software development teams rely on User Stories for project management – they serve as building blocks for Epics<\/a> and even Initiatives<\/a> in Jira. Engineers use the finalized stories to create detailed implementation plans that will include all the steps that must be completed in order to deliver said Story. <\/p>\n\n\n\n You\u2019ll need to click on the \u201cCreate\u201d button in Jira to create a Story. <\/p>\n\n\n\n From there you\u2019ll need to create a new work item (issue) and select the story work type.<\/p>\n\n\n\n Once selected – fill the Story with the story description. Jira has many fields for documenting stories<\/a>. You may be actively using different ones based on the processes established in your company. Let\u2019s focus on several of them for now.<\/p>\n\n\n\n Most of the time the first batch of User Stories will be created and added to the backlog ad hoc. They will be pretty generalized and their objective will be to simply give the development a certain vector. This step is usually done by the Product owner.<\/p>\n\n\n\n These stories will be later refined during the backlog refining sessions by the entire team. You\u2019ll add Acceptance Criteria<\/a> to the stories. These criteria are needed to further define the story and add a bit more context. <\/p>\n\n\n\n You\u2019ll also assign stories their story points – an agreed upon rough estimation of the complexity of a story.<\/p>\n\n\n\n The stories that are moved from the backlog into the Sprint backlog must be ready. By that, I mean that they must be immediately actionable. This doesn’t mean that you\u2019ll need to define 100% of the Acceptance Criteria. But you\u2019ll need to ensure that the team understands the story well enough to a point where they are sure it can be delivered. For this purpose, many companies use INVEST<\/a> checklists for their Definition of Ready. <\/p>\n\n\n\n The following stage would be to move the work item from the backlog to the Sprint backlog. This is when the development team will begin their work on the feature and, once the story meets the Definition of Done, the feature will be released.<\/p>\n\n\n\n Here are some valuable tips for writing kick-ass user stories:<\/p>\n\n\n\nHow to write User Stories?<\/h2>\n\n\n\n
\n
What is a User Story in Jira?<\/h2>\n\n\n\n
![\"\"](\"https:\/\/titanapps.io\/blog\/wp-content\/uploads\/2023\/03\/Template-main-11-1024x252.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/titanapps.io\/blog\/wp-content\/uploads\/2023\/03\/Template-main-12-1024x629.png\")
<\/figure>\n\n\n\n\n
The workflow of a User Story<\/h2>\n\n\n\n
![\"\"](\"https:\/\/titanapps.io\/blog\/wp-content\/uploads\/2023\/03\/Template-main-13-1024x680.png\")
<\/figure>\n\n\n\n\n
![\"\"](\"https:\/\/titanapps.io\/blog\/wp-content\/uploads\/2024\/08\/note.png\")
Pro Tip<\/span>\n <\/div>\n
![\"\"](\"https:\/\/titanapps.io\/blog\/wp-content\/uploads\/2023\/03\/Template-main-14-1024x680.png\")
<\/figure>\n\n\n\n