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
➡️ bit.ly/DFTraining
📧 Get a FREE guide "How to Organise Software Teams" by Dave Farley when you join our CD MAIL LIST 📧
The best way to keep in touch with the latest discussions, events and new training courses, get FREE guides and exclusive offers. ➡️ www.subscribepage.com/organis...
_____________________________________________________
📚 BOOKS:
📖 "Continuous Delivery Pipelines" by Dave Farley
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 Dave’s NEW BOOK "Modern Software Engineering" is available here
➡️ amzn.to/3DwdwT3
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
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:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
Octopus are the makers of Octopus Deploy the single place for your team to manage releases, automate deployments, and automate the runbooks that keep your software operating. ➡️ oc.to/Dave-Farley
SpecFlow Behavior Driven Development for .NET SpecFlow helps teams bind automation to feature files and share the resulting examples as Living Documentation across the team and stakeholders. ➡️ go.specflow.org/dave_farley
TransFICC provides low-latency connectivity, automated trading workflows and e-trading systems for Fixed Income and Derivatives. TransFICC resolves the issue of market fragmentation by providing banks and asset managers with a unified low-latency, robust and scalable API, which provides connectivity to multiple trading venues while supporting numerous complex workflows across asset classes such as Rates and Credit Bonds, Repos, Mortgage-Backed Securities and Interest Rate Swaps ➡️ transficc.com

[@ContinuousDelivery]

If you would like a FREE guide to help you Write Better User Stories, sign up here ➡

[@polariss0i]

Every time I see a story with "as a User" I know it's going to be garbage. What user, internal, external, customer, admin? So I had a laugh at your little example there.

[@jimhumelsine9187]

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.

[@walkerb9]

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.

[@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)

[@martinherrmann5319]

I think this is quite an interesting topic!

[@antoniorocha9438]

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

[@brownhorsesoftware3605]

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).

[@krccmsitp2884]

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

[@johntendresse9055]

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”.

[@genghiskhanschubbycheeks2170]

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.

[@johnwade1325]

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.

[@rasmusl8370]

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).

[@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!

[@disgruntledtoons]

Thirty years ago (and longer) W. Edwards Deming was telling everybody who would listen that not only do you need to understand your users' requirements, you need to understand why they require them.

[@rorycawley]

Thanks Dave. Nice and clear. What's your take in use cases?

[@knuckleheadmcspazatron4939]

Excellent summary of a crucial topic. If you want to save yourself and your team a lot of time and emotional anxiety, follow this advice.

[@tomcowell9653]

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.