Scoping and Writing User Stories

Scoping and writing user stories is a critical part of the Agile development process. User stories are simple, clear, brief descriptions of functionality told from the perspective of a user. They are designed to create a simplified description of a requirement. The format of a user story is typically: "As a [type of user], I want [an action] so that [a benefit/a value]". User stories help to focus on the user's needs and to streamline the development process by breaking down complex tasks into manageable units of work.

While User Stories are the most popular, they’re not the only method. There are closely related alternatives to User Stories called Job Stories, that refocus on what’s the job of situation, motivation, and expected outcome to focus on context and the underlying motivation. There’s also completely different approaches that lean into the criteria for acceptance and the functionality required around it, with a short context description. There is no right and wrong but instead what works best for a given team.

Example

Let's continue with the professional networking example. After the PRD and designs for the "Enhanced Job Filtering" feature have been finalized, the Product Manager now needs to guide the development of this feature. The team uses the Agile methodology, which includes the use of user stories to define the tasks that need to be completed.

The Product Manager, in collaboration with the Product Designer and input from the Engineering Manager, begins to write user stories for the "Enhanced Job Filtering" feature. For instance, one of the user stories could be: "As a job seeker, I want to filter job postings by location so that I can find jobs near me". Another user story might be: "As a job seeker, I want to filter job postings at companies with mutual connections so that I can find opportunities with people I already know".

These user stories help to define the scope of the feature and provide a clear understanding of what needs to be developed from the user's perspective. They also help to prioritize the development tasks and to ensure that the feature meets the user's needs and expectations.

It’s at this point, there’s a hand-off from the Product Manager, who manages the product and feature direction, and the Engineering Manager (EM), who manages the engineers and their engineering tasks. The EM would go on to write out the engineering tasks related to each story, which are commonly sub-tasks of the Story, clarifying any confusion with the Product Manager and Product Designer.

Pain Points

Writing user stories can be challenging as it requires a clear understanding of the user's needs and the functionality of the feature. It's also important to ensure that the user stories are concise, specific, and focused on the user's perspective. Furthermore, managing and prioritizing user stories can be a challenge, especially in a large project with multiple features and functionalities.

Practical Exercise

Think of a feature or product you want to develop. Try writing user stories for it, outlining the user's needs and the functionality of the feature. Share it with a colleague or friend and ask for their feedback. How well do your user stories communicate the user's needs and the functionality of the feature?

Related Research Topics

• Agile development process [ Google | Perplexity ]

• Epic in Agile [ Google | Perplexity ]

• Writing User Stories [ Google | Perplexity ]

• Job Stories vs User Stories [ Google | Perplexity ]

• Alternatives to User Stories [ Google | Perplexity ]

• Engineering Tasks [ Google | Perplexity ]