User Stories Applied: For Agile Software Development

Introduction:

"User Stories Applied: For Agile Software Development" is written by two of the heavy hitters from the agile movement, starting with Kent Beck one of the original signatories of the Agile Manifesto in 2001 who has since driven the development and popularisation of Extreme Programming XP. The primary author is Mike Cohn who we have already reviewed in this series with "Succeeding with Agile: Software Development Using Scrum".

In a world where projects can't afford to wait, user stories are a paradigm shift—where communication triumphs over cumbersome upfront requirements.

Key in Agile projects are communication and feedback cycles which are the foundation for user stories. It's ok for developers and customers to talk rather than write requirement specs, negotiate with stakeholders, and then write some more. A requirements document should only be written when it achieves the real goal of delivering the project, not an invaluable waterfall sequence that yields no value to the customer. User stories provide us with a method for having just enough information written down that we don't forget and we can estimate and plan while encouraging communication.

The primary purpose of this book is to set the scene for the role user stories can play in software development and agile projects, why, when and, how to use them, and when other tools in our toolkit might be useful. At 286 pages it's a quick read with sections towards the end reserved for examples. It's a very practical reference point for a tool that many of us use without a second thought in our day-to-day Jira backlog management. User stories at best should serve as a means for communication and collaboration between stakeholders, including customers, developers, and testers throughout the software development process.

This blog will be structured as follows:

• What are user stories and how are they used ??????
• Writing User Stories ????
• Gathering Stories ????
• Guide for Good Stories ???
• Estimating and Planning ????
• What stories are not ????
• Why user stories? ???
• A catalogue of story smells ????
• My conclusion ????♂?

Let's get into it.

What are user stories and how are they used ??????

Software requirements are a communication problem. Those who want the new software must communicate with those building it. If either side dominates the communication the project loses. For example:

• Stakeholder Dominated = mandating functionality and dates with little concern for developer feasibility
• Developer Dominated = technical jargon replaces the business language and we lose what is needed by listening.

We cannot perfectly predict a software development project, rather as users see early versions they come up with new ideas or change their opinions. So instead of attempting to make an all-encompassing set of decisions at the outset of a project, we spread the decision-making across the duration.

User Stories are the 3 Cs. Card, Conversation and Confirmation.

What is a user story? They describe the functionality of something valuable to a user or system. Comprised of:

1. A written description of the story used for planning & and a reminder on scope (Card)
2. Conversations about the story that flesh out the details (Conversation)
3. Tests that convey and document details that can be used to determine when a story is done/ complete. (Confirmation)

Note: When a story is too large it is sometimes referred to as an epic. Epics can be split into two or more stories of a smaller size.

Cohn introduces the concept of the customer team, which includes those who ensure the software meets the needs of intended users e.g. product managers, real users, testers and designers. The customer team write the user stories so they are written in the language of the business rather than developer jargon which means enables the customer team to prioritise their inclusion in iterations and releases.

The story-writing process is best started by considering the type of users of the intended system, more on that next.

Writing User Stories ????

When writing user stories there are some important themes to yield the maximum benefit for the least effort. They must be:

• Independent: dependencies between stories lead to prioritising and planning problems.
• Negotiable: they are not written contracts or requirements that the software must implement. They are short descriptions of functionality to be negotiated between the customer and the development team. Extra detail can often be associated with extra precision which is misleading. This can lead to the mistaken belief that story cards reflect all the details and no further discussions are needed. Details that have already been confirmed on the story become tests.
• Valuable to users or customers: keep in mind the distinction between purchasers of the software and the users. The best way to ensure this is to have the customer write the user stories.
• Customers become comfortable when they learn user stories are a reason to talk, not something they will be held accountable for "well the requirements document said that..."
• Stories are estimable: the only reason they could not be estimable is either the story is too big, or the developers lack technical knowledge. If it truly is unestimable stories turn into spikes which are given a defined timebox to gather information, then the actual implementation story. Ideally, spikes should exist in a different iteration to the implementation story. Otherwise, there will be a higher-than-normal level of uncertainty in the sprint with the inestimable story
• Testable: stories must be written to be testable. Successfully passing its test proves that a story has been successfully developed.

Now, let's take and put it into the practical world when gathering user stories.

Gathering Stories ????

Cohn challenges the idea of elicitation and capture which implies requirements are out there in the wild waiting to be explained and locked in a cage. My favourite takeaway from this book is the excellent metaphor of requirements captured as trawling.

In fishing, trawling involves dragging a large net behind a boat to catch a variety of fish. Similarly, in the context of requirements capture, "trawling" refers to casting a wide net to gather a diverse set of ideas, needs and requirements from stakeholders. This works on multiple levels:

1. Different-sized nets can be used to capture different-sized requirements, a first pass can be a large net to gather the big ones and gut feel. Applicable across business value, essentialness and so on.
2. Like fish, requirements mature and die. The net may miss a requirement today because the requirement is not important to the system.
3. Systems grow in unpredictable directions based on feedback from each iteration, requirements may grow or decrease in importance.
4. You won't capture all of the fish in an area trawling, and you won't capture all requirements.
5. Not forgetting skill plays an important factor in finding the requirements.

However even though we acknowledge the impossibility of writing all the stories upfront, we should at least make an initial upfront attempt. The stories can decrease in detail as the time horizon. This is useful in getting a feel for the size of the application.

Cohn covers 4 techniques for capturing requirements:

1. User Interviews: Watch out for open-ended questions and context-free questions. For example, would you like the app to open in browser vs. would you like the app to open in a browser vs native Windows if it means reduced performance and less user interactivity?
2. Questionnaires: useful when needing information from a wide number of users. Not as a primary means this does not replace interviews and conversations.
3. Observation: a chance for rapid and direct feedback, a great way to pick insights.
4. Story Writing Workshop: all product, customer and dev teams write as many stories as they can. Focus on quantity rather than quality.

Guide for Good Stories ???

Good stories are comprised of a few key elements one of which is acceptance tests (ATs). The purpose of ATs is to express the details from conversations between devs and the customer team. ATs provide basic criteria that can be used to determine if a story is fully implemented. The customer team should as a minimum specify the tests to know if the story has been correctly developed. They are however not responsible for identifying every possible test, the customer focuses on the tests that clarify the intent of the story. It is vital that testing is viewed as part of the development process, not something that happens after 'coding is done'.

Here is a simplified checklist for writing good stories:

1. Start with goal stories: consider each role and the users' goal for interacting with our software.
2. Slice the Cake: stories that represent a full slice of the cake are preferred as exercising each layer of an application arch reduces the risk of finding last-minute problems in one layer.
3. Write Closed Stories: a story that finishes with the achievement of a meaningful goal. This needs to be balanced with stories being estimable and small enough to fit into an iteration.
4. Put constraints on cards for features that must be obeyed rather than directly implemented.
5. Size the story: write at different levels based on the implementation horizon.
6. Keep the UI out as long as possible: One of the problems that has plagued every approach to requirements has been mixing requirements with solution specifications.
7. Include user roles in the stories e.g. as a job seeker, and write for one user.

Estimating and Planning ????

I've kept this section light touch as it's been covered in detail in this blog: https://www.dhirubhai.net/feed/update/urn:li:activity:7150562164158726144/ however relevant to user stories. The best approach to estimation allows us to:

• change our minds when we have new information
• works for both epics and smaller stories
• doesn't take a lot of time
• provides useful information about our progress and work remaining
• tolerant to the imprecision of estimates

Stories within iteration planning are relevant meaning we can discuss a story and disaggregate the story into its constituent tasks with One dev taking responsibility for each task. After all are allocated devs estimate to make sure they are not over capacity.

What stories are not ????

• User stories are not use cases.
• IEEE guidelines on how to write software requirements, which is extremely tedious and error-prone and boring.
• User stories aren't scenarios with settings, actors, goals, objectives, actions and events.

While we advocate for user stories there are instances when they might not be solely applicable e.g. on a large project with many stories it can be difficult to understand the relationship between stories. You may need to augment stories with additional documentation if requirements traceability is mandated in the dev process.

Why user stories? ???

So why user stories? They emphasise verbal communication: it seems so easy to think that if everything is written down there can be no disagreements, developers will know exactly what to build and test and more importantly, customers will get exactly what they want. However, the reality is the customer will get the developer's interpretation of what was written down which may not be what they wanted. A far more valuable goal than perfect requirements is to augment adequate stories with frequent conversation.

Stories are also:

• Comprehensible by everyone: both users and developers
• The right size for planning
• Work for iterative development: I can write some stories, code, test them then write some more as often as necessary.
• Encourages deferring detail: place-holding goal-level stories can be written and replaced with more details once it becomes important to have details.
• Support opportunistic design: Users and customers don't often know what they want and even if they did many of the details devs need to develop the software become clear only as they develop the system. Remember, humans are incapable of comprehending that many details upfront. Even if we could understand all the details product and project changes occur. People make mistakes.

How can we understand if we are using user stories correctly? Checkout the list of smells below.

A catalogue of story smells ????

Something might be amiss in your features, projects and programmes.

1. Stories are too small = there is a frequent need to revise estimates
2. Interdependent stories = difficulty planning iterations because of dependencies
3. Gold plating = devs adding additional features that were not planned
4. Too many details = too much time spent gathering details well in advance of a story being implemented
5. Including user interface details too soon and early in a project
6. Thinking too far ahead:
7. Splitting too many stories
8. Customer has trouble prioritising
9. Customer won't write and prioritise stories

My Conclusion ????

Remember, user stories are not rigid contracts but rather dynamic instruments for ongoing conversations between customers and developers.

Why for users' stories over requirements documents or use cases?

• Emphasis on verbal communication rather than written
• User stories are comprehensible by all audiences
• User stories are the right size for planning
• User stories work for iterative development.

On a practical level in Boohoo and PLT, we've been reviewing the what, why, who, where, when and how across our issue types in Jira looking to create user story standards across our agile squads and tribes. The workshop structure facilitated by Becca Jaye Sharples is included in the Miroverse template:

https://miro.com/miroverse/user-stories-applied-template/

Next up will be a dive into Extreme Programming looking at the latest version of Kent Becks Extreme Programming Explained: Embrace Change.