Requirement Specification vs User Stories

What are software requirements and how do they relate to user stories? Is it requirement vs user story, or user story as requirement? An important part of agile software development is its user or customer focus. Our aim as software developers is to deliver outcomes that our users want or need. To do that it is vital to focus our work on the outcomes that matter to our users. Actually, this is true of any software development, agile or not. Requirements are often used to define the steps to deliver a solution, this is a big mistake. Deciding what our system needs to do is a difficult problem. Designing software well is a difficult problem too. We should avoid trying to solve these two difficult problems together in a single step, by conflating requirements with design.

In this episode, Dave Farley, author of “Continuous Delivery” and “Modern Software Engineering” explores what makes good requirements and how user stories help to improve the quality of requirements whatever the nature of our software development.

-------------------------------------------------------------------------------------

Also from Dave:

🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses

📧 Get a FREE guide "How to Organise Software Teams" by Dave Farley when you join our CD MAIL LIST 📧

_____________________________________________________

📚 BOOKS:

📖 "Continuous Delivery Pipelines" by Dave Farley

📖 Dave’s NEW BOOK "Modern Software Engineering" is available here

NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.

-------------------------------------------------------------------------------------

CHANNEL SPONSORS:

[jimhumelsine]

As a software developer, I want user stories with testable acceptance criteria, so that I can confidently create acceptance tests that confirm the user story behavior.

I think of acceptance criteria as the requirements and the user story as the narrative that provides context for those criteria.

[walkerb]

Not only should user stories express the “what” of the requirement, a good user story should also express the “why” of the requirement “so that” developers can understand the problem that gets solved by the story. I worked for an organization in which the marketing guy basically designed how the product worked by providing a list of features. That’s what passed for product owner there. But, I wanted to hear about the problems that customers were trying to solve. I you just ask a customer what they want, they may tell you that they want it to be faster, cheaper or some other increment to of what they already have. To them, the product is just a tool to do their work. However, the development team might see a different solution because they understand what the product could do if they understand what the customer actually needs.

Dear Dave, I have no idea how you manage to so concisely sum up in 17 minutes the mental model that I have built up for myself over the years and fail to convey to the teams I work with on a daily basis. But I know that in the future I will simply refer to your video for these questions. And I will add the phrase "Requirmenets that define how the system works aren't requirements" to my vocabulary. Thanks for these videos and please keep up the good job.

[daviddelgadovendrell]

Pure gold. Thanks. I would suggest you to expand this video with a Part 2, including Requirements vs Features (although I guess there are less misunderstandings than the current one)

[johntendresse]

As a senior business analyst, I have thrown out user stories as a tool. I have retooled my BA toolkit to include RML. RML is requirements modeling language. Visual requirements modeling is the best way to define “requirements”.

[brownhorsesoftware]

A user story is a description of the problem in the context of the user. A specification is a description of a proposed solution in the context of the dev. It is the developer story. They are dependent but separate different things. The better the dev's understanding of the user context the better (== faster) the result. In my way-of-working the developer story is a general outline of the solution app or feature expressed as narrative (no implementation details).
The most important skill I have developed as a dev is the user interview. Another important skill is the ability to look things up. Both skills are simply the ability to ask the right question. You ask the right question by understanding the context.

[martinherrmann]

I think this is quite an interesting topic!
As a product manager i put a lot of effort into creating proper tickets, which tech agnostic user stories but clear, testable acceptance criteria.

However i feel i'm a difficult position to include design thinking to it.
Acceptance criteria often expresses some sort of solution already, when earlier in the video we wanted to be open about understanding the user and their problems, and come up with a multitude of possible solutions. I guess it would be interesting to see what the lifecycle looks like. Maybe a ticket should start with the user story and the description of the problem. Then. design and engineering can work on the "best guesses" to solve the problem and define the acceptance criteria based on the understanding and then the development lifecycle would begin?

I would love some opinions about it. Jim in the comments mentioned he wants testable criteria. I was wondering how you would define them when you're at the early stage of describing the problem, without proposing a solution immediately. I'm usually trying to give designers the freedom to come up with whatever they see fit and to work with engineering to make sure it is also feasible. I think this all touches base on good discovery processes that should have happened before the creating of a story itself.

[genghiskhanschubbycheeks]

I have only been in software for 7 years but I am already my teams senior lead. I'm not saying this bc I think I'm some special flower but bc so much of what has made me a good developer is encapsulated in this video. I never thought I would enjoy translating customers vague wishing into computer capabilities. It's extremely rewarding to give others a product they enjoy using and capabilities they didnt know were possible.

[krccmsitp]

My personal summary: distinct between problem space and solution space. Your tips and explanations give good practices to achieve that.

[tomcowell]

Very nice. I've been saying for years that exactly zero people know how to write requirements. This is a much more lucid and nuanced assessment.

[jonblackburn]

That is the BEST description of what should - and should not - be in a User Story that I have ever heard. Thank you.

[antoniorocha]

That is what I love your channel, a few minutes clip expresses the essence of the topic enhanced of your professional experiences.

[seiofecco]

I always had a hard time teaching our new PO's to request functionality rather than specific solutions. In the future this video will be one of my go-to's when topics like that one turns up. Thanks, Dave - great job! I already shared the vid several times!

[michaelc]

As someone who's been with "user story" side of the house and not involved with "requirements, " I have never really put that much thought I to this until all that changed recently. Now being heavily involved with product ownership, I am seeing how vitally important the need for a clear understanding of both of these and how that impacts traceability in the end.

[johnwade]

Thank you for another very clear exposition. My concern is this: there seems to be a lot of ambiguity in so many IT discussions now over the use of the term "user". For many years I was involved in both development and support of systems - usually individually "simple" but intimately interlinked with others to create a complete and coherent system in the most demanding OLTP environments. The term "user" normally denoted the head of the relevant area of the business: as you suggest, these people often didn't really understand what the day-on-day users of the system needed - no user stories there, but we managed given the relatively straightforward interfaces between full-time well trained users on simple screens and the centralised system with a common look and feel.

However, the whole question of "who is a user?" has got infinitely more complex now, where systems are generally directly exposed to the public through the Internet. Is the user still the person in the business who is commissioning this work, and presumably paying for it, as is implied especially in some talks I see on DevOps? Or me, as a potential customer of the organisation, who is expected to understand what I see when I log in? Fifteen years after retirement I consider myself as a seasoned "user" of online systems, and I am still constantly confused by what is put before me. (The most common fault is assuming that I know my way round the website, and where I'm going next. As I am not psychic, I often get lost, and once this happens it is too often impossible to get back to a point of stability.)

Once your users are the general public, the paradox arises that the people who best understand the "desired business interaction" are probably the least qualified to understand what the idiots like me out there are really going to need, to blunder round and achieve it. And from my own experience, the more you pour information and guidance onto the screen, the more confused the recipient becomes. In my book Good Code is Not Enough, I seriously recommend the use of a stroppy teenager to look at this area. (I had always referred to this activity as external design, but the term User Stories is much better and I wish I had known about it before.)

[rasmusl]

This was a fantastic explanation of how focusing on the user's problems rather than the solution is a crucial beginning to any product development.

[neilfromcork]

My requirement was for a succinct explanation of best practice that could would my mind (when it should be changed).

Requirement delivered. Thanks as always Dave!

[davidhsharpe]

We’ve moved towards User Stories and Acceptance Criteria, all with emphasis on the “what” and not the “how”. What I like about this approach is that it is lightweight, flexible and objective rather than subjective. It’s measurable, which our senior team likes, and sets us up well for UAT. And of course we no longer produce long documents that nobody reads.

[shadyworld]

We have a User Persona, to use thier empathy map context as we write the User Sories, and we write them to build on the User Journey map to have a true accurate results and it consists of:
- What is the job they do and our system should do in process details
- Why is that the right sequence of the process?
- What's the constraints they fear to face? And what are the results (Risks/Losses) they'll face?
- How to measure those loses properly to detect, diagnose and notify the user in case they occurred?
- How much (Resources: Time or Money) each step usually takes before?
- And how much reduction of that loss we should consider to make it useful and profitable for them? (That's the lean)
- Lastly ask them if this user Story wouldn't exist or released would it make the solution function or not? (Initial prioritization)


We then put a clear User story definition of one liner above that with the standard format on the top of that then each point is added.

And after the whole user Journey with the defined Story points are gathered as clarified we reprioritize all (User Stories) from 0:5 whight and the critical ones would be between 4 and 5 then 3 for not critical but important then 2 for a nice to have if existed and 1 for a Wasteful code effort but useful for client lastly 0 is NEVER gonna have and those classified from Risks, Fears questions and all bad assumptions you could give and rejected by the User themselves in a brainstorming session at the end if that meeting.

Yeah, that's how I do it, probably Not perfect and need more simplification for much excperinced fellows here how ever it works and I'm open for advice too.

[karsh]

I use both user stories and classical requirements for my projects. Basically I define user stories for what the users want or need and requirements for what must be there. A simple example (please mind this i a youtube comment and not a formal document):
Story
As an employee I want to log on the application without the use of a password.

Requirement
The system must support FIDO for as a sign-in mechanism.

The point os that the end-user doesn't care about security, but the organisation might, so you need both.