Key Takeaways
1. User stories are short, simple descriptions of features from the user's perspective
Stories are comprehensible by both customers and developers.
Concise and clear. User stories typically follow a simple format: "As a [user role], I want [goal] so that [benefit]." This structure ensures that the story focuses on user value rather than technical implementation. Stories are usually written on index cards or sticky notes, emphasizing their temporary nature as conversation starters rather than comprehensive specifications.
Encourage collaboration. The brevity of user stories promotes discussions between developers and customers, fostering a shared understanding of requirements. This collaborative approach helps uncover hidden assumptions and reduces the risk of misinterpretation that often plagues detailed written specifications.
Flexible and adaptable. User stories allow for easy reprioritization and modification as project needs evolve. Their simplicity makes it easier to estimate effort and plan iterations, supporting agile development practices.
2. User roles and personas help identify diverse user needs and guide story creation
User role modeling: understanding what users have in common, and where they differ.
Identify user types. User roles represent different categories of users who will interact with the system, such as "novice user," "administrator," or "power user." Personas are fictional characters that embody key characteristics of these roles, making them more relatable and concrete.
Guide story creation. By considering diverse user roles and personas, teams can ensure they're addressing the needs of all potential users. This approach helps prevent overlooking important functionality or usability considerations for specific user groups.
Prioritize features. Understanding the relative importance of different user roles helps in prioritizing features and making trade-offs during development. For example, a feature crucial for power users might be less important for novice users.
3. Effective story gathering techniques include interviews, workshops, and observation
The best way to build software that meets users' needs is to begin with "user stories": simple, clear, brief descriptions of functionality that will be valuable to real users.
User interviews. Conduct one-on-one interviews with potential users to understand their goals, pain points, and workflows. Use open-ended questions to encourage detailed responses and uncover unexpected insights.
Story-writing workshops. Bring together developers, customers, and users to collaboratively generate and refine user stories. This technique promotes shared understanding and helps identify gaps in requirements.
Observation. Watch users interact with existing systems or perform their tasks in their natural environment. This can reveal needs and opportunities that users themselves might not articulate in interviews or workshops.
4. Estimating stories in points allows for flexible planning and prioritization
Story points are not equivalent to my team's story points. A story your team estimates as worth three story points may be worth five to my team.
Relative sizing. Story points represent the relative effort or complexity of implementing a story, rather than absolute time estimates. This approach allows teams to estimate more quickly and accurately by comparing stories to each other.
Team-specific scale. Each team defines its own scale for story points, which might be based on complexity, effort, or risk. This allows teams to estimate in a way that makes sense for their specific context and expertise.
Velocity tracking. By measuring how many story points a team completes in each iteration, teams can predict their future capacity more accurately. This "velocity" metric helps in planning releases and managing stakeholder expectations.
5. Release and iteration planning balance customer priorities with team capacity
Planned and actual velocity after the first three iterations.
Release planning. Customers prioritize stories for upcoming releases, while the development team provides estimates. This collaboration ensures that the most valuable features are delivered first, within the constraints of the team's capacity.
Iteration planning. At the start of each iteration (typically 1-4 weeks), the team selects stories to work on based on priority and their estimated velocity. This allows for regular adjustment and reprioritization as new information emerges.
Continuous adaptation. By comparing planned and actual velocity, teams can refine their estimates and adjust plans accordingly. This promotes transparency and helps manage expectations throughout the project.
6. Acceptance tests define story completion and promote clear communication
Acceptance tests validate that a story has been developed with the functionality the customer team had in mind when they wrote the story.
Clarify expectations. Acceptance tests specify the conditions under which a story is considered complete. This helps prevent misunderstandings between customers and developers about what "done" means for each feature.
Guide development. Writing acceptance tests before implementation helps developers understand the desired behavior and can inform their technical design decisions.
Automate verification. Where possible, automating acceptance tests allows for rapid feedback on whether new changes have broken existing functionality. This supports continuous integration and delivery practices.
7. User stories encourage collaboration, adaptability, and customer-focused development
Stories are not contractual obligations. As we'll see, agreements are documented by tests that demonstrate that a story has been developed correctly.
Promote conversation. User stories serve as reminders to have conversations about requirements, rather than attempting to document every detail upfront. This ongoing dialogue helps uncover and address complexities as they arise.
Embrace change. The lightweight nature of user stories makes it easier to adapt to changing requirements or priorities. Unlike detailed specifications, stories can be easily modified, added, or removed as the project evolves.
Focus on value. By continually tying development work back to user needs and business value, user stories help teams avoid building unnecessary features or over-engineering solutions. This ensures that effort is spent on what matters most to customers and users.
Last updated:
FAQ
What's User Stories Applied about?
- Focus on User Stories: User Stories Applied by Mike Cohn emphasizes the role of user stories in agile software development, providing a framework for writing effective stories that capture user needs.
- Requirements Process: The book outlines a process that saves time and reduces rework, teaching how to gather, prioritize, and utilize user stories throughout the development lifecycle.
- Practical Guidance: It offers practical advice on writing, organizing, and using user stories for planning, management, and testing, making it a comprehensive guide for agile methodologies.
Why should I read User Stories Applied?
- Enhance Agile Practices: The book enhances understanding of agile practices, particularly in writing and utilizing user stories effectively, making it valuable for developers, testers, analysts, and managers.
- Improve Communication: It helps improve communication between technical teams and stakeholders, leading to software that better meets user needs.
- Practical Tools and Techniques: Cohn provides tools and techniques that can be immediately applied to projects, useful for both beginners and experienced practitioners in agile development.
What are the key takeaways of User Stories Applied?
- User-Centric Development: Emphasizes writing user stories from the user's perspective to ensure software meets actual user needs.
- INVEST Criteria: Introduces the INVEST criteria for good user stories: Independent, Negotiable, Valuable, Estimatable, Small, and Testable.
- Continuous Collaboration: Highlights the importance of ongoing collaboration between developers and users to refine requirements and adapt to changing needs.
What is a user story according to User Stories Applied?
- Definition: A user story is a simple, clear, and brief description of functionality valuable to real users, capturing what the user wants to achieve.
- Three Aspects: Consists of a written description, conversations to flesh out details, and tests to confirm completion, ensuring clarity and accountability.
- Example: An example might be, "As a job seeker, I want to search for jobs by location so that I can find opportunities near me."
How do I write effective user stories as per User Stories Applied?
- Follow the INVEST Criteria: Ensure stories are Independent, Negotiable, Valuable, Estimatable, Small, and Testable for manageability and user value focus.
- Use User Roles: Include specific user roles to clarify who the story is for, enhancing effectiveness.
- Keep It Simple: Avoid unnecessary details or technical jargon, focusing on user needs for further discussion and refinement.
What techniques does User Stories Applied suggest for gathering user stories?
- User Interviews: Conduct interviews to gather insights about user needs and expectations, uncovering valuable information.
- Story-Writing Workshops: Organize workshops for stakeholders to collaboratively write user stories, encouraging participation and idea generation.
- Observation: Observe users interacting with existing systems to identify pain points and areas for improvement, providing real-world context.
What is the role of acceptance testing in User Stories Applied?
- Validation of User Stories: Used to validate that software meets requirements outlined in user stories, ensuring alignment with user expectations.
- Customer Involvement: Customers specify acceptance tests, clarifying user story details and ensuring development team understanding.
- Part of the Development Process: Integrated into the development process, catching issues early and ensuring software alignment with user needs.
How does User Stories Applied define the concept of velocity?
- Definition of Velocity: Velocity is the amount of work (measured in story points) a team can complete in a single iteration, serving as a key planning metric.
- Importance for Planning: Helps teams estimate completion time for remaining work and plan future iterations effectively.
- Adjusting Expectations: Velocity can change over time; regular measurement allows teams to adjust plans and expectations based on performance.
What are the best practices for planning a release according to User Stories Applied?
- Prioritize Stories: Collaboratively prioritize user stories based on organizational value and user needs, using techniques like the MoSCoW method.
- Estimate Workload: Estimate total story points for the release and use team velocity to predict needed iterations, setting realistic timelines.
- Flexibility in Planning: Be prepared to adjust the release plan as new information emerges or priorities change, maintaining flexibility for success.
What are "story smells" in User Stories Applied?
- Indicators of Problems: Story smells are signs of issues with user stories, such as being too small or too large.
- Guidance for Improvement: Provides a catalog of common story smells and suggests ways to address them, refining user story practices.
- Promotes Better Practices: Recognizing and addressing story smells leads to more effective user stories, improving the development process.
How does User Stories Applied integrate with Scrum?
- User Stories in Scrum: Explains how user stories can be used within Scrum, particularly in managing the product backlog.
- Sprint Planning: Discusses how user stories help prioritize work during sprint planning, ensuring valuable features are developed first.
- Daily Scrums: Provides context for daily scrum meetings, helping teams stay focused on delivering user value throughout the sprint.
What are some common pitfalls to avoid when using user stories according to User Stories Applied?
- Avoid Over-Detailing: Writing too many details can lead to confusion and detract from facilitating conversation.
- Don't Ignore User Input: Failing to involve users in the story-writing process can result in stories that don't reflect user needs.
- Neglecting to Prioritize: Not prioritizing user stories can lead to wasted effort on non-valuable features, impacting project success.
Review Summary
User Stories Applied receives mixed reviews, averaging 3.89/5 stars. Readers appreciate its clear introduction to user stories in agile development, praising the practical examples and case study. Many find it well-written and easy to follow. However, some criticize its dated content (published 2004) and lack of depth on certain topics. The book is recommended for those new to agile methodologies but may be less valuable for experienced practitioners. Some readers note its excessive breadth and high price as drawbacks.
Similar Books








Download PDF
Download EPUB
.epub
digital book format is ideal for reading ebooks on phones, tablets, and e-readers.