ProductFTW #15: User Stories

As product managers, our primary goal is to deliver high-quality products that meet and exceed user expectations. Essentially, we're aiming for what you might call fanatical joy. You’ve heard of “delight your user,” right? We accomplish this by providing accurate and thorough information to our development teams so they have a clear understanding of what will truly make the user happy. Among the most effective tools at our disposal for conveying these details is the user story.

But what exactly is a user story?

A user story is a short description of a product feature from the perspective of the person who desires the new capability, typically a user or customer of the system. It’s a formula that keeps your product's who, what, and why top of mind for everyone involved in its development:

When I started as a product manager at CreditCards.com, we didn’t have a practice of writing user stories. More often than not, we found ourselves building solutions that were technically sophisticated but didn’t necessarily address the real needs of our users. Instead, we were inadvertently building for ourselves (the technology team), creating features that were more about showcasing our capabilities than solving actual problems. This led to overdeveloped solutions. 

One example that sticks out is how overly complex our website publishing was. Seriously, it took hours to publish a spelling correction. I still look back and shutter. We forgot who the end user was, and although it is normal for development to sit back and run a batch process overnight, our internal users didn’t expect that. A simple user story would have prevented this.

Example of a Good User Story:

This is a good example because it clearly states the user's problem and goal.

Example of a Bad User Story:

This is a bad example because it does not start with the user and focuses on the solution.

Best Practices for Crafting User Stories

• INVEST in Your Stories: Ensure each story is Independent, Negotiable, Valuable, Estimable, Small, and Testable. This helps create stories that are manageable and actionable without being overly prescriptive.
• Be Specific and Realistic: Vague stories lead to ambiguous implementations. Provide enough detail in your stories and acceptance criteria to guide development but leave room for technical creativity.
• Regularly Review and Revise: User stories are not set in stone. They should evolve as new information is discovered and as project needs change. This iterative process helps align the project with user needs and business goals.

Common Pitfalls to Avoid

• Writing Too Many Details: Avoid turning user stories into fixed requirements. Over-detailing can stifle creativity and flexibility in finding the best technical solutions.
• Ignoring User Feedback: User stories should adapt based on feedback from all stakeholders, including users, developers, and business representatives. Regular feedback loops are essential for refining stories.
• Confusing Tasks for Stories: Ensure each story focuses on delivering value to the user rather than just completing tasks. Stories should always be outcome-oriented.

Acceptance Criteria

A user story is nothing without its acceptance criteria. Acceptance criteria specify the ‘conditions that must be met’ for the user story to be considered complete. They serve as a checklist that ensures every functionality introduced meets the user’s needs and the team’s quality standards. While the user story focuses on the 'what' and the 'why,' acceptance criteria define the 'how' to achieve it, making the story actionable for developers and testable for QA teams.

Best Practices for Crafting Acceptance Criteria

• Specific and Clear: Good acceptance criteria provide detailed and unambiguous details that must be met for the user story to be considered complete. They eliminate guesswork by providing exact parameters. Example: "Updates to card listings can be published live within one minute of submission by a content editor, and the system must confirm the successful publication with a timestamped notification to the editor."
• Testable: It needs to be easily measurable. This clarity allows developers to create precise tests for each requirement, ensuring functionality meets the specified standards. Example: "The publishing system should allow content editors to preview changes in a sandbox environment, which accurately reflects the live site, before final publication."
• Achievable: Given the project's scope, technology, and timeline, the criteria should be realistic. They should challenge the team to deliver high-quality work without setting them up for failure.
• Relevant: Directly connects to the functionality described in the user story, focusing on solving the user's problem without including unrelated features. Example: "Content editors must be able to revert to the previous version of the content in case of any errors."

Common Pitfalls to Avoid

• Vague and Ambiguous: Vague criteria lead to subjective interpretations and inconsistent implementations, which can significantly deviate from the intended user requirements. Example: "The publishing tool should be user-friendly." (This is subjective and doesn’t specify what aspects make the tool user-friendly.)
• Non-testable: Criteria that cannot be quantified or confirmed through testing are useless for developers or QA teams. Example: "The site should publish faster than before." (Without a specific target time, "faster" is too ambiguous and unmeasurable.)
• Irrelevant: Criteria that do not support the specific goals of the user story lead to the development of unnecessary features, potentially increasing complexity and resource expenditures. Example: "The system should be compatible with all future content management systems." (While forward compatibility is important, this is too broad and irrelevant to the user's immediate needs.)
• Overly Prescriptive: While clarity is crucial, overly detailed instructions on how tasks should be executed can limit the developers' ability to innovate or optimize the solution. Example: "Use specific CMS X version 2.34 for the publishing tool." (Unless a particular version is essential for compliance or integration, this type of specification may unnecessarily restrict technical solutions.)

Putting it Together

User Story:

"As product operations, I want to be able to quickly publish our card listing pages, so that I can avoid posting misinformation or a compliance violation."

Acceptance Criteria:

1. Timeliness of Publishing:
   1. Changes submitted by the content editor must be live on the site within one minute of submission.
2. Notification of Publication:
   1. Upon successful publication, the system must send a timestamped notification to the content editor confirming that the changes are live.
3. Preview Capability:
   1. The system must provide a sandbox environment where content editors can preview their changes exactly as they would appear on the live site before finalizing the publication.
4. Error Handling and Reversion:
   1. Content editors must be able to revert to the previous version of the content in case of any publishing errors.
5. Compliance Checks:
   1. The system must automatically perform a compliance check on the content before it is published, flagging any potential compliance issues for review by the content editor.

User stories and their corresponding acceptance criteria are the building blocks of successful product development. They ensure that every piece of functionality is directly tied to user needs, avoiding unnecessary features and misdirected efforts. Remember, a well-crafted user story and detailed acceptance criteria together create a clear path forward.

As you continue to refine your approach to writing user stories and acceptance criteria, you'll find that these tools will help you better serve your users. Keep iterating and refining. The more aligned your stories and criteria are with your users' true needs, the more successful your product will be. 

About ProductFTW

ProductFTW is a weekly newsletter about product management focusing on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions worldwide yet. We’re here to bridge the content gap from building your product and team to scaling it.