01 User stories are used in many agile software development frameworks, such as Extreme Programming, Scrum, and Kanban. Mind that different approaches often use specific templates for how to phrase user stories. See, for example, Schwaber, K., & Beedle, M. (2002). Agile Software Development with Scrum (Vol. 1). Prentice Hall.
02 A hotfix is a fast solution for an urgent problem in a software product. Usually, a hotfix is deployed to fix a critical software bug.
User stories are used in software development to define requirements from a user or customer perspective, in contrast to often rather product-based requirement documents. [01] User stories can be used in various stages of a design process:
- During research to request non-complex features that could be implemented in a short time without prior prototyping (“quick wins” or “low-hanging fruit”), or to report critical bugs that hinder users from utilizing or signing up for the software.
- During ideation and idea selection to speak the same language as the IT team during co-creative workshops and to break down ideas into actionable features.
- During prototyping to quickly agree on which stories need to be part of the first prototype or the MVP, to be able to test selected stories, and to agree in which sequence the following stories should be implemented.
- During implementation to allow seamless integration with an agile development process that is based on user stories, and to be able to quickly adapt and iterate when technical difficulties occur during implementation.
The software requirements can be broken down into a set of user stories.
As an easy example, a user story related to location-based services on your smartphone could be formulated like this: “As a regular customer, I want to get notifications from restaurants I prefer that are nearby, so that I don’t have to search.”
User stories should be formulated without IT-specific language. Write these as seen from the user’s perspective, using simple, concise words, so that everyone can understand them. In service design, user stories are used to connect design research with actionable input for IT development. Often, when a research team identifies potential “quick wins” for existing software, formulating these insights as user stories is all that is needed for an IT team to develop a “hotfix.” [02]At a later stage, these user stories can also be used during prototyping and particularly during implementation to turn low-fidelity prototypes into working software.
Just as journey maps have different zoom levels, software requirements also have different scales. A set of user stories can be combined into what is called an “epic” – a longer, rather sketchy story without a lot of details. Epics describe the big picture of what a piece of software can do. Epics are then typically broken down into several user stories over time based on prototyping, user feedback, and research data.
Reformulating the same example regarding a requirement for a location-based service on your smartphone as a job story could look something like this: “When I stroll through a new city around lunch time, I want to be notified when I’m near a restaurant that matches my preferences so I can go there directly instead of searching for it.”
This example illustrates the main difference between a user story and a job story. The job story focuses more on the context of a specific use case and does not include a role or persona like a user story. It makes sense to clarify with your IT team if they use a specific framework for user stories, job stories, epics, and so on.
