5 Common Mistakes In User Stories

What are User stories and what are the common user story mistakes that people make? How can we write better user stories and avoid these common mistakes?
Requirements vs User Story Requirements, are they the same, are user story requirements a thing? There are really only three steps in building software, having an idea of the problem that we’d like to solve, building some software to solve it and then checking that the software does what we think and solves the problem. A User Story is focused on the first step, but if we get them right they make the next two steps much easier.
In this episode Dave Farley explores 5 common user story mistakes that make software engineering and continuous delivery more difficult, rather than easier. During his exploration of the mistakes, Dave describes some of the properties of better, more useful, user stories and the reasons why they are better.
-------------------------------------------------------------------------------------
📚 BOOKS:
“50 Quick Ideas to Improve your User Stories” by Gojko Adzic & David Evans 50% discount here ➡️ leanpub.com/50quickideas/c/fa...
📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
Kindle ➡️ amzn.to/3DwdwT3
(Paperback version available soon)
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.
📖 "Continuous Delivery Pipelines" by Dave Farley
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble
➡️ amzn.to/2WxRYmx
-------------------------------------------------------------------------------------
🎓 CD TRAINING COURSES 🎓
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses ➡️ bit.ly/DFTraining
📧 JOIN CD MAIL LIST 📧
Keep up to date with the latest discussions, free "How To..." guides, events and online courses.
➡️ bit.ly/MailListCD
-------------------------------------------------------------------------------------
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
Harness helps engineers and developers simplify and scale CI/CD, Feature Flags and Cloud Cost Management with an AI-powered platform for software delivery. ➡️ bit.ly/3Cfx3qI
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. ➡️ octopus.com/
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

[@ruixue6955]

1:15 3 fundamentals of software development 2:42 1st mistake : requirement as remote control programming 3:20 user stories are not requirement in the traditional sense, *a story doesn't tell devs what code to write* 3:32 a user story is: a descriptoon of the problem we try to solve 3:42 good user story says nothing at all about how to solve The problem 4:30 5:49 a Job of software developer is not to wrote code but to solve The problem 5:58 2nd mistake: stories as a contract for change 6:43 a user story is a placeholder for a conversation 8:08 3rd mistake: monster stories 8:24 a user story should Be a small increment in The behavior of The system 8:37 ideally stories are shorter yet, much nicer you are going to complete this in a day or 2 8:57 the whole point of a user story: 9:16 4th mistake: 10:57 recommend book 14:22 5th mistake: dependencies between stories 15:10 good user stories are ATOMIC

[@robertholtz]

Outstanding. Whenever I encounter a dev team that isn’t getting results, the way they handle (or mishandle) user stories is almost always the root culprit. Getting User Stories right is literally make or break in my experience. Thanks for another fantastic video. I always get great value from your work.

[@alanjohnson7374]

That's because it's usually a case of shit in, shit out.

[@christophe7692]

Great! The focus of stories on real needs, leaving room for creative solutions in a conversation, is definitely a key advice here. Writing stories just passively formulating requested solutions is a practice that dangerously nears Henry Ford's paradox: "If I had asked people what they wanted, they would have said faster horses".

[@urbaniv]

It's so great listening to you because all you say is absolutely no BS. Just pure wisdom based on experience. So refreshing Thx for this channel

[@ContinuousDelivery]

Thanks 🙂

[@reinerjung1613]

While this video is on user stories, it also is a good introduction on what requirements are or better what they are not: Requirements are not UI design or technical features. To stick with the example: "I need a way to browse songs quickly" is a requirement. We teach that at university, but it seems not to stick with students.

[@m0un106]

When I went to University, they taught requirements in terms of a specific high-level thing to be implemented, but it was not in terms of a user’s story and the impact that the change will have on them.

[@reinerjung1613]

@@m0un106 This is true. User stories go a little bit further or the term shifts the focus to the user, but that focus should also be used with requirements. However, there are also technical and contextual requirements which do not fit under "user story", still they can be put in a story as the user wants the system to work with something else. Or you could say they are the first derived Info from the user story. Either way requirements should be written from the perspective of the user. Just like use cases should focus on what the user wants not how the UI is actually designed. We are currently migrating from one groupware to another and therefore we develop use cases based in the old system and these have to be mapped in features of the new system as well as the old. So they must be UI independent.

[@msb3559]

But then how do you setup an acceptance criteria for something that vague? And how do you fit it in a single sprint?

[@tylersmith8245]

This was really good. This might be my favorite one you've done so far!

[@ContinuousDelivery]

Thanks 😎

[@fabricejaouen4252]

Thank you very much. Willing to start up with a large project from scratch, for sure this video will help. Absolutely fabulous.

[@ContinuousDelivery]

Glad it was helpful!

[@vlkff]

Awesome video, great perspective with a deep understanding! Thank you!

[@YoavNaaman]

Thank you again for this helpful session.

[@ContinuousDelivery]

My pleasure!

[@marconiiii]

Thank you so much for this! thanks for share your wisdom and experience

[@thought-provoker]

The Login Feature is my favorite *antipattern* of a user story. Here's how the story is typically written, "As a user, I want to register with my e-mail and password, so that I can log in." Well, as I like to say ... " _I want to register_ ... said no one ever. Who _wants_ to register, who _wants_ to give their e-mail - and most of all, _who really wants to remember yet another password_ ?" The actual story is more like, "As a user, I want to have access to secured content." - isn't it fascinating that some platforms have entirely eliminated e-mail/password registration by simply relying on other authentication mechanisms? As long as the Login user story is written as a detailed requirement of the "How", that kind of solution is un-thinkable. But even in the age of fingerprints, facial recognition and Google Accounts, we still see the username/password "story" in almost every new project ...

[@karsh001]

The problem with biometrics is that they are not secure secrets, therefore in many cases they can't be used as security tokens (that they are being used as such does not make them suitable). Besides that, I agree with you: 'want' and 'have to' is two different things.

[@ContinuousDelivery]

Good point, the idea of “password” is an implementation-leak in my example.

[@boldinn]

No offence Michael but you make the other 'big mistake' with writing user stories - what I call the 'Meatloaf problem' i.e. you've only covered 2 out of three of the criteria... which ain't bad, but it's not enough! AS A User I WANT to have access to secured content SO THAT ??? I'd go more like: AS A user I NEED to be able to provide evidence of my identity SO THAT I can access secured content That could be (probably is) an epic on the basis you could build out a number of methods for 'providing evidence of identity'...

[@emaayan]

here's my problem, on one hand you say stories need to be short and provide value to the user , but OTOH you say that the first stories will involve more work "building supporting infrastructure" this tiny phrase, hides a LOT of work right now, i need to build a system, that when a user inputs a token to a machine, it initiate a massive process behind the scenes where the machine registers itself to aws ssm, receives ansible playbooks that install stuff , builds up docker images, creates cloud iot resources, all those things are completely hidden an automatic and hidden from the user. our ALM system (JAZZ based :( ) has the concept of "epic" which contains "features" which contain "user stories" which may contain tasks" the first user stories were created by someone that didn't implement them, and they were monster stories because included so much work, (sometimes by more then one person on different systems), but the reason it was like that is that created tasks, would actually bring even more overhead to managing all this because it would be hard to move tasks/user stories between sprints in the system. so the next time i wanted to break it down, so i was given pre-written features that were based on the steps this massive process does, and i needed break them down to stories, so i did, by having a one user story on a service creates the registration, another user story on sending back an async message to calling system, another user story about actually creating the ansible playbook according to what you're saying those are wrong as they focus on the technical implementation, but i viewed them as isolated units i could commit (btw did i mention that every commit we do , must include in the comment the pattern id : name ,reviewed by: so eventually our code must report back to what ever we put in the ALM system) which seemed far more manageable then monster stories, and less over head then having tasks. but OTOH hand i find that trying to test those is problematic at best , for example if i have a spring boot services that needs to both call an SSM to create a registration ,create an async call to start building cloud resources, and eventually send back an async message to the calling app that started the process (and do all that locally) it becomes an issue. i could start by first just testing the call registration, but what am i really testing, here. if a call was made?

[@jared_grey]

I really enjoy your channels, this one, and Top Gear.

[@ParamountMotion]

This is one of the best Scrum videos I've ever seen. It's a shame that the people who REALLY need to see this could never be bothered to watch a 5 minute video, let alone an 18 minute one.

[@emiliod90]

This was great Dave - are you covering Acceptance Criteria how-to's/mistakes too?

[@MINDoSOFT]

Wow ! Thank you for sharing these videos. Very useful at my job as a software developer! 👌

[@ContinuousDelivery]

Glad you like them!

[@user-uc7yn6rm8b]

Bought the book years ago, brilliant, concise, and well worth getting

[@emonymph6911]

Very good, love the ipod analogy.

[@penangiteInAU]

Just bought the book! Thank you for the great offer and splendid video👍 it’s helpful and bade sense. So straight away checked out your recommended book. Please keep up with your excellent teaching 😊

[@ContinuousDelivery]

Thanks for your support!

[@Pedritox0953]

Excellent insights

[@phronessys]

You always help me so much, thanks!

[@ContinuousDelivery]

Thanks, pleased to be helpful.

[@janisiivola4423]

Good explanation about value vs valuable. Something I’ve struggled to explain as clearly.

[@parumita]

It's a good idea to divide the video when you re using a count or steps. Nice video btw

[@ferdibra]

Good session with lots of food for thought 💭

[@ContinuousDelivery]

Thanks

[@boryswwa]

First of all - I love your content. I have started to understand Agile so much more, since I found your channel! I have two questions, that bother me, though, in regards to User Stories: 1) Synergy (or lack of thereof) 2) How to estimate? Ad 1) I feel that splitting the work into small chunks, as it is advised with Agile, apart from all its' pros, causes synergy to suffer. I have not heard anyone mentioning this, though. Let's imagine that one story is about adding a button to a screen. And then there is another story, about adding another button to the same screen. If those user stories were combined, some common work required on them could be shared, and therefore total amount of effort spent on implementing two buttons to the same screen at once, would be lower, than the amount of work spent on implementing the same buttons but in separate development tasks. Other example would be, that looking at small User Stories developer could get into "silo thinking" only considering the current piece of work, the he's doing, and the code, he'd write, would not account for other features that might have already been requested as part of other User Stories, causing the need to alter or, sometimes, rewrite that piece of code completely, when working on the User Stories further down the line. That double effort would not be needed, if developer would know about the contents of all User Stories and could therefore write the code accounting for all requested features already from the start. That synergy is achieved in waterfall during the blueprint phase. Is it simply that Agile sacrifices some synergy in favor of flexibility and pace in which features are delivered, and this is simply something that needs to be accepted, or am I still missing something? Ad 2) You mentioned (15:22), that amount of effort that it takes to implement a user story, will differ, depending on when the user story lands in the development timeline. How can we properly estimate the User Stories then? We don't when it will be planned for implementation at the time when we estimate the User Story. Thank you very much for a great content!

[@fmkoba]

great video and also thank you for the book promo, Gojko's books are great

[@ContinuousDelivery]

Yes they are!

[@Dinokkio2]

Timed perfectly for me, just writing user stories for software that I kind of partially already wrote, without stories :D - Very good points. I have been doing this stuff so long that it is very hard not to expect requirements (because that is what we used to do).

[@ContinuousDelivery]

I am pleased that this was helpful.

[@PeterManger]

My whole career of 20 years I’ve never had requirements. I’ve had vague notions of what users want that they think are requirements. I quickly learnt most users don’t know what they want and (gently) need help. Prototypes and showing what’s possible totally changes the user experience and gives the business ownership of success and outcomes. Today agile and “fail forward fast” has helped me and team a lot!

[@Dinokkio2]

@@PeterManger Yeah, well. The practice for us has mostly been converting users wishes (and what we think they wish) into kind of requirements. Me or someone on the team has done it. User story format isn't very intuitive because our team has been so small. Usually one coder/one solution.

[@PeterManger]

@@Dinokkio2 it's a tough gig!

[@GDScriptDude]

Wow man, this reminds me of when I moved from a commercial company to a military contracting company (for communications) and their equipment specification (or maybe it was acceptance criteria) was just like what you are calling a story. It was alien to me at the time but now I get it.

[@ContinuousDelivery]

Interesting, I hadn't heard of that before, thanks.

[@OthmanAlikhan]

Thanks for the video =)

[@career248]

Thanks!

[@thomasmarshall97]

Well said

[@wjrasmussen666]

Love it and got the book

[@Munkendrunky]

DAVE! Thanks for publishing these recommendations; excellent content! One question.... Your first suggestion is a point of inner turmoil I've had for quite some time. I've worn the Product Manager hat for several0 dev teams working on web apps. Following your example, if an app needs to include a new set of identifiers I could either write a story to describe the business need or to prescribe a solution. If I choose the latter and follow through with a conversation stating the business need and that I believe a drop-down list is the best approach as it has a low LOE, fits well into the existing UI, and provides the desired functional behavior, they will quickly agree, go to work building to that "requirement", and have something to deliver within a day or two. If I choose the former and leave things open to interpretation and innovation, they will take weigh out multiple possibilities using wireframes/POCs, and either end up with a drop-list or something that involves either significantly re-working the UI and/or would make a UX designer want to jump out of a window. The story will, also, often take the full Sprint or multiple Sprints when handled in this manner. In my (current) opinion UX skills are among several things that don't come easy to many dev team members and if you don't already have that skillset in your Scrum team, it is better to bring them in (which often means swapping someone and their talents out) or to manage around that shortcoming than spend many tiresome hours trying to teach a chicken to fly. What are your thoughts on this subject?

[@ContinuousDelivery]

Sure, you don't always have the expertise that you need in a team. Where you have that expertise elsewhere, in a UX specialist perhaps, then I think their role should be to join the team for the duration of the story, and their job during that time is not really to do all the UX (or whatever) work, but to teach the team enough that they can do a better job next time. Use the experts for unusual difficult cases, and train the team to be good enough to do the normal, day-to-day, stuff. I think that the "programming by remote control" approach to requirements feels good in the short term, but over the long-term is a much worse strategy. If your teams agonise too much over simple UI changes (for example) then that is the problem to fix, improve their skills, rather than remove their responsibility for the code IMO.

[@errrzarrr]

They are not to blame for spending too much time. The company is for not hiring a subject-matter expert, a UI/UX designer. If you were assigned with the task of preparing an exquisite Spanish seafood. How much would you spend on that? How much it would cost you?The final result result won't be a total mess? Probably it would be a total mess, too expensive and spend too much time. Why? Because you aren't a chef, you have never before heard of "Spanish seafood" dishes.

[@DreySF]

Thank you very much for the nice video. As far as I understand from your video I can treat a user story as a kind of test in a test-driven development. But that also mean that a developer team can simply deliver at smallest increment that just works. That also means that I need some kind of refactoring I can apply to the result. A product owner can say in the review that he doesn't like how the front end looks like for example. That also means that in the acceptance criteria I need to factor in that kind of description. simply implementing a user registration or or something else will not result in a high-quality front end for example. So what's the methodology to have a very good user story that also considered us high-quality ux design? Simply describing what a user want will not result in the new generation of an iPod. There need to be some kind of instrument that precisely develops a really good description of the end result. What would you recommend?

[@tyrantsonthefield]

Wonderful video. Small incremental value is critical as you develop even on updating established code bases. Being dead focused on MVP minimal viable product, is also helpful for narrowing your scope to get the bones of the project in place. What's the simplest version of your product you can make. The analogy i like to use is say we are building a house and their is a storm coming in, should we be putting sinks in the bathrooms or should we make sure the roof is on and the walls are up.

[@ContinuousDelivery]

I like the analogy, I may steal that. It's not that you don't need sinks, it is just that they are not vital right now. I like Jeff Patton's "getting ready to leave for work" exercise in the Story Mapping book to illustrate this too.

[@iliumboy]

This is the perfect methodology to give the users want they want, but not what they need. I recently started at a online gaming company (and have since left) that had a requirement to exclude customers with certain postal codes. The systems analyst designed a solution and instructed the developers how to implement the solution, despite my objections. The feature was implemented using Agile/Scrum & CICD. It was implemented in record time, users were happy and they were given exactly what they wanted. And the solution was completely wrong. The systems analyst didn't understand what the users really needed and the developers did what they were told. The users wanted a way to exclude certain postal codes, what they NEEDED was a way to include certain postal codes. I will take competent analysts and developers over any methodology any time/every time.

[@TheMetadude]

I have to agree with this. In my experience "users" always know what they want, they often don't know what they need. This is why having a 'conversation' as Dave says is so important, especially at the start. And that conversation needs to involve real users !

[@tieTYT]

How do you write user stories for a product that isn't user-facing? For example, a micro service that other services call? Do I consider the other services to be users? Should I still write stories from the perspective of the person using the front end? Or is there and even better option I hadn't thought about?

[@gandralf]

5:24 => ok, I get the need to keep the focus at the problem in hand in order to avoid common pitfalls and be open to the best solutions, but it looks like a (research) project description (which will take months) instead of a short story (that will take days).

[@stojadinovicp]

Please add chapters so that we can link to particular mistake when sharing this video with out teams.

[@paulreilly5987]

interesting point about saying that the job as software developers is to design solutions, not to program. This is not always the case. Many people can program but they cannot design solutions. There are people who can paint a wall very well, but they are not interior designers. There are people that can build a wall but they are not architects.

[@tomwolverson2500]

I've noticed the first one as an antipattern in one of my recent lead roles - "stories" that are actually instructions. It's particularly prevalent in teams with novices, who want to have somewhere to turn to for guidance on how to use an unfamiliar technology or platform to solve problems.

[@ContinuousDelivery]

Yes, I sometimes call this anti-pattern for stories "Programming by remote control" 😖

[@krccmsitp2884]

Full ack. Unfortunately, there are still too many software companies that don't get the Agile Manifesto (individual and interactions, customer collaboration), even though they are supposedly committed to a strong customer centricity. BTW, nice T shirt.

[@nickfifield1]

50% off! Bought the book years ago . Pretty good.

[@myobpro8516]

Thank you Dave for these useful tips, However I would like to know how to express pure technical task as user story that bring value to the user ?

[@ContinuousDelivery]

First, try and find out why this matters to a user and capture that. If it doesn't matter to a user, why is it worth doing. This is an over generalisation but mostly you need technical stories when you aren't doing a good enough job of quality on regular stories. Start including the technical updates as part of regular stories. Make it easy to do things like upgrade language, OS and libraries though automation etc. On the whole I think it a sensible approach to try and eliminate 'technical stories'. You may never completely eliminate them, but treat them as a 'smell' in your process.

[@georgehelyar]

The stories must be delivering value to someone, or you wouldn't be doing them. Perhaps you just need to identify your user. It could be that a particular story is actually intended to help your ops team, for example.

[@rpopov71]

If the user story is not a contract between PO and DEV, why does it have acceptance criteria? Why are the user stories used to frame the implementation work, replacing the tasks? Why is the implementation considered "not done" without proving that it satisfies the acceptance criteria? These characteristics of the user stories make them a pure contract between actually three parties - the PO, the DEV, and the team that planned them. To me, there is a clear distinction between: - requirements (as a statement of the business objective to achieve) answer "what?"; - design answer "how?"; - tasks answer "when?". Then, planning the most valuable or critical tasks to deliver the earliest addresses the risks and opportunities. Here the user story is just the topic to discuss, reveal, and prioritize the real needs, while the process above satisfies them. RUP used to call it "use case." Sadly, now the vague term "user story" replaces that whole process.

[@pmc9194]

Always thought that a user story was distinct from acceptance criteria - but maybe I'm thinking about the Agile-based User Story statement ("As a... I want... So that..."), whereby this would be very much distinct from acceptance criteria, which is what is part of "definition of done". As a matter of fact - it depends on which development approach you are using - business requirement says Waterfall-based.

[@rpopov71]

@@pmc9194 I mean that uhe user story in "as a... I want..." contains acceptance criteria - the specific steps needed to demonstrate that the implementation of this specific story satisfies this specific user's need. The definition of done is a general checklist if the/any implementation is sufficient to be demonstrated. In general DoD may state "there are tests", but the acceptance criteria can say what actually to test in this specific implementation.

[@pmc9194]

@@rpopov71 well, I don't think anyone said that the contents of user story and acceptance criteria to be mutually exclusive. But the fact remains that these have distinctly different uses. Because the user story is in reference to the business need, it is usually not so specific as to outline what would normally end up in the acceptance criteria, which is why I feel you are referring to Waterfall more than Agile. To assume user story and acceptance criteria can be synonymous would be presupposing the solution, which then can lead to issues already mentioned in the video (stifles innovation, a "back-seat driving" product owner, and a lock in to a tight scope for solutionising). Speaking generically, and after allowing for some due diligence, the product owner is arguably responsible for ensuring the final agreed acceptance criteria is faithful to delivering the value outlined in the user story.

[@abstractworlds]

Some good points, thank you Dave. I think your "We want people to be able to easily find and select the song they want" identifies at least 2 other common issues with user stories: 1. Not defining the problem domain, e.g. how many songs, what is a song, what information does it contain, how are songs structured? Without this information too, we wont understand what the problem/problem domain/business domain is, so in this case a user story like that in isolation is not enough. 2. This user story is not a small story, how many 2 week sprints did it take at Apple to solve this one? In which case what do you do? Do you break it down into much smaller user stories that can be achieved in a sprint or a few days (another point you raised), at which point are you then indeed going back into user stories as remote control programming (another point you raised) when they are broken down to this level, actually defining the solution not the problem?

[@jamesnotreal321]

You mentioned not to use stories as contracts. In this case what do we track? What we do where I work is we only track technical tasks and move the story along until all technical tasks are done for that story. (of course we still keep stories to be small and no more than 1 sprint)

[@ContinuousDelivery]

I think that the stories are good things to track. Why do you care, once the development is done, about the mechanics of the work, the useful bit is the bit that is useful, the behaviour. In the past I have used the content of user stories and the acceptance criteria (examples that demonstrate that the value exists, from which we create acceptance tests in the form of 'executable specifications') to track what is in each release candidate and do things like auto-generate release notes and audit trails. Works very nicely!

[@robertburnfield8837]

Interesting take. Only problem is convincing Product Owners to let go of things this way. Most companies I've been in do fake agile with waterfall behind the scenes. Companies typically do product idea -> design -> scrum team (qa, dev, po, etc) -> release At which point the scrum team of QA/dev are really just implementing the requirement of make this screen like this rather than being asked to solve the problem for the user. Instead they're only asked to solve a technical problem and not a user problem. Sadly I don't think most developers would have the confidence to demand this kind of change in an organization, especially if the organization is large. In addition, lot of devs are prob burnt at that point and just want to get done for the day. Not to mention the enormous push back you will get from the rest of the company especially those business owners who want to control all changes.

[@Ryushindo]

I m having this problem right now as a BA with a new VEYY big client, I have to convince senior VP and VP level POs to implement best practices, all they say is that I m making things more complicated. Lets not even talk about behind the scenes politics. I really don't know what to do.

[@raulsantandertirado4400]

So, how do Used Stories relate to BDD tests? Also, does the book offer advice on automated testing?

[@raulsantandertirado4400]

​ @Continuous Delivery, I'm sorry Dave, for some reason KZbin is not showing your reply here. However, I'm able to read some of it. I think that you were trying to tell me where you talk more about this.

[@bjoernwuest7483]

Greate video and very helpful to show it to the business to avoid many mistakes. Yet, there are two things that remain open to me and maybe someone can help. 1) How to combine the "atomic" with the "small" principle? E.g. assume the following user story "I as a user want to change the secret that is required to identify myself to the system so ...". Wouldn't such user story actually depend on a story like "I as a ... want users to securely and reliably identify to the system so ..."? In that case, I have a dependency between the two user stories. Or would the idea here that you just come up with the second user story, holding back the first one until the second one has been delivered? 2) If I make user stories very small and just focus on the what, how do I actually avoid ripping of by e.g. external devs? Even in a situation where you provide a well-thought of set of solution focused but "non remote dev" user stories I had the experience that external devs try to rip you off. Most likely by just barely implementing what is very easy to do and then with the next user story asking for a whole redesign of the system. A la "Oh, you want that users can only access their resources and not the resources of anyone else? Well, if you had told us that beforehand we might have considered it but now we have to redesign the whole system and data architecture". And to be clear, I had this experience more than five times in my career as external consultant for Business Analysis and Enterprise Architecture.

[@asdf3568]

So for a log in system with registration you come up with a dozen user stories. But what if you're using a framework and you find some plugin that does all those things? There's a reason you want to do some remote programming beforehand.

[@EatonEmmerich]

Are these videos somewhere without ads?

[@jimiwikmanofficial]

Interesting point of view regarding contractual agreements. I assume you mean the user stories are starting points and once the conversation has led to a solution, that user story is updated and becomes contractual? I am asking because the definition of a requirement is a legally binding contract. This is because I can deny acceptance if the solution does not match what I have requested, and on the opposite side, I can deny an incident if it does not match what I have promised to deliver. So at some point a user story, or rather the requirement itself, will become a contractual object?

[@alirezaRahmanikhalili]

I have missed you a lot!

[@KYsYooToob]

Folks at our company get lost on how to move from a general problem user story into an agreement with the user that the functionality works. for that they need test cases and detailed steps, and they want to know where to put those steps, and on which stories, since the steps span stories from the user perspective. If there were to regression test the system, where do they put the expectation that the list box be populated with "Active people" or whatever the solution ended up being. Where do they keep a final description of functionality and test cases that span stories? I've never had a perfect answer for them. The sometimes put them on an Epic but then they struggle with "sometimes epic, sometimes story", and "stories aren't permanent".

[@lost-prototype]

Another great video. I caution against cutting things up too small because I've found incrementalism to negatively impact technical design. But getting things as small as is reasonable is still useful!

[@peshutanpavri1599]

This is so incredible. So I just wanted to know, If I have been asked to make a product, do I not need any kind of formal documentation to establish what is required? How would this work with User stories?

[@ContinuousDelivery]

The idea is that we technologists do the best work when we are part of the process of agreeing what makes sense, we have part of the puzzle, how difficult or easy a proposed solution may be in the context of how our system actually works. So someone without that understanding can't make sensible decisions. On the other hand, we techies need help to understand the business context and the product better, so this decision-making should be a collaboration, not a series of instructions. If you have a "formal specification" of some-kind, it inevitably lacks either technical context, or even if done by technical people, it is usually done by technical people far from the actual problem. This is a bad way to write good code! I have another video that talks about that: kzbin.info/www/bejne/naS3lH56ipxmjac

[@peshutanpavri1599]

@@ContinuousDelivery Thank you so much for getting back to me. I will look into this. I have just finished my msc in CS, I have done a whole few modules on Software quality management, they taught a lot of theory, but i have no idea how documentation works in the real world. Your videos are so helpful. I am tending to do a lot of TDD after watching your videos

[@mztr0nix]

Thanks for the video, it's super helpful on what's important and how to focus on the right things! However I have a question on the part where User Stories should not depend on each other: Let's say you start a new project/topic. And part of the project involves having persisted data. Other stories working with those persisted information would be clearly dependant on the story including the persistence in the first place, wouldn't they? Is there another way of solving this dependencies on a user story level?

[@ContinuousDelivery]

I think there are a couple of strategies. Either include enough persistence in the first story to make it work, or if it makes sense for the story, implement it in a way that it doesn't need persistence. Mostly I'd do the first one, but sometimes the second one is useful. The idea that you can play stories in any order isn't necessarily the same as saying that you can play them in any order and they will take the same amount of time. The aim is to avoid trying to make things more complex, more tightly-coupled to the implementation, by keeping stories atomic. You can work on them in any order. Then it is a separate act to decide what order makes sense to implement them in. It is fine to, once you have the stories, have discussions like "if we play this one first it will take less time", but that should be a separate decision to defining what you want from the system.

[@DTwo1977]

One problem I'm often faced with, and that rarely are addressed when talking about software development in general, is working with internal requirements. A customer that only wants a small, new feature or a bug fix won't see any value in us spending time on switching the acceptance tests from .NET 4.6 to .NET 5 or going from SpecFlow 2 to SpecFlow 3. Other examples, that only at best indirectly affect the end user, is making tests more robust by re-writing or replacing the flaky ones, creating proper libraries of things that are used (and repeated) in many projects or just profiling the tests to see what can be done to speed them up. Is it even a good idea to try to fit these things into the standard user story pattern, or should I just go with 'As an architect, I want the tests ported to .NET 5, so that we...'?

[@georgehelyar]

This may not work for you but the way we do it where I work is to have a separate backlog of small, technical tasks, which is owned by the development teams rather than the product owner. Reminders to repay tech debt, to remove old feature flags and prune now unused code paths, etc. We fill the sprint to about 3/4 full, and pick up these technical tasks at the end of the sprint, only after the sprint goal has been hit. Unfortunately the reason we have to do it this way is because non-feature stories are given absolutely no priority where I work. Things that save us development time, improve security, improve performance, reduce costs or even fix most bugs are just never done otherwise.

[@user-ks2uu2mh2h]

Interesting video. But it's a great problem when user gives U detail BRD what looks like FRS/SRS

[@gabrielchristiannegre2715]

Thank you for the video! What is your opinion on "developer" stories, like in an API, "As a developer, I want to be able to schedule a crawler to run", things that the user doensn't see directly

[@linucksrox]

I would think that is totally acceptable. Even though you're a developer, you are also a user of the API so that is still a "user story"

[@gabrielchristiannegre2715]

@@linucksrox Yeah, I sometimes find myself really pushing to create stories, but thanks for the comment, It is nice to know other people do it

[@pabloduke2748]

I find it ironic how rigid agile tends be around story sizes. What we need are complexity coefficients for domains. The coefficient can act as a multiplier of how long the minimum time for a deliverable with value can be produced. A coefficient of 1 means 1 day and and a coefficient of 10 would mean 10 days. If you work on a web UI that has a basic login, where the most complex thing the dev needs to worry about is making a text box show up on a screen that has a blue background - assign that a coefficient of 1 and hand that off to an intern. If you work in a domain with extremely complex math and requirements developed by lawyers then maybe in the spirit of being agile you should consider increasing that coefficient to a 30 or 40. Some problems really are harder to solve than others.

[@ssssssstssssssss]

As a software engineer, I can get good advice on software engineering without being bombarded with code and all the tricks that (fill in the blank with the trending language) provides.. (sorry for the monster story)

[@trocomerlo]

Masterpiece

[@barry5433]

Excellent video, thank you so much for your valuable insight on the SDL. Would you consider writing a user story for secondary users (stakeholders who aren't "end users"), where the implementation might include some 3rd party integration e.g. As a Sales Manager I want to see the bounce rate on the register page, so that I can make a decision on registration form input fields. I e. Where do you draw the line between a user story and a "task"?

[@rolemodel99]

Maybe jobs to be done as a backlog item format might be more useful?

[@rolemodel99]

Hope @continuous Delivery can also make an episode about this

[@heymega4779]

Great video! Although I don't agree entirely with "User Login" or "Require Password" being user stories. A story should describe a user carrying out some domain-level task that has a value associated with it. Logging into a system doesn't offer any value, it's what they do after logging in which adds the value. I find it easier to accept that not everything can be a story but ideally, they should be the bulk of your work.

[@gonzalowaszczuk638]

If the content the user wants is already secured behind authentication, then doesn't a "User Login" actually provide value? Before the user story the user wasn't able to access that content, after that user story is released the user is able to access that content; thus it provides value in their eyes.

[@KieranShaw]

Thanks for another great video Dave. One thing I've been struggling with in the world of microservices is how or if to split up stories and the work to allow for independently deployable services to get their changes out the door. In a simple example of someone wanting a new field to display on a page in a UI where the UI is one deployable component and the API that's going to contain that data is the other deployable component. Should we be doing the work across as many services (in this case a UI and an API) as the story requires and release probably the API change first and then the UI change, and only when both are out of the door is that story done? Or...is it 2 stories, one for the API and one for the UI? Obviously the customer doesn't care about our architecture and deployment behaviours, but as a development team we don't want to couple the releases of two seemingly independent services if we don't have to. Any thoughts?

[@ContinuousDelivery]

In general my advice, and the advice from the experts on MicroServices, is that they align with a "Bounded Context" not artificially along technical boundaries like UI and API. I see a lot of teams making this kind of division. As usual I suppose that it really depends on coupling. If the 'API' of a service is generic and the 'UI' then organises it with some other things (DropBox on top of S3 for example) then that is one thing. If every time you want to change the API you have to change the UI, or vice versa, then these aren't really MicroServices, because they are too tightly-coupled to be "independently deployable", another defining characteristic. So at the problem that this may be highlighting is that the division of responsibilities between the teams is wrong. The goal of MS is to reduce coupling between teams. None of this changes the advice in this video to my mind. Still good to structure your work around what the user of the software wants. If your service presents an API though, who is the customer, probably other services that consume that API, so stories at that level are best captured from the perspective of those users. This is difficult to do well, because it is now too easy for API programmers to start thinking from their own perspective rather than their user's perspective, because both are programmers. Still an important, and good, idea though.

[@KieranShaw]

@@ContinuousDelivery Great answer, really useful. Thanks Dave.

[@georgehelyar]

@@KieranShaw ideally you want vertical slices. The problem with that comes when the story requires work on multiple services that are owned by separate teams. Then you pretty much have to split it at service boundaries. You can start with vertical slices and then split it at service boundaries though, as part of your story refinement. There are a few ways to make them independently deployable, you just probably can't release it in a visible way to the end user until all of them are done.

[@scottthornton4220]

This is all fine and dandy for user interface work, but how do I use user stories / agile if I need to develop (research) complicated mathematical algorithms that could take months to develop? It's difficult to put into a story because I'm not even sure where the algorithm is going to go, i.e. I'm not sure if this is even going to work or not.

[@ContinuousDelivery]

Who’s the user of the algorithm? Focus on them, they are your users even if their “user interface” is an API. The real point of user stories, in my opinion, is to separate what it does from how it does it. That is just as valuable for an API as for a UI.

[@gayatrivalwani7839]

Sometimes in the process of splitting stories, you find the small story is non testable or perhaps would be less effort to test it with other stories. Any suggestions or recommendations for this ?

[@ContinuousDelivery]

I try to organise my testing so that it is very easy to add tests, and reuse nearly everything that makes them work, usually by creating a Domain Specific Language for testing. That means that I don't usually end up facing this problem. The only reason that I can think of for a change to be not-testable is if there is some tech in way that stops me testing, in which case I'd design the system to find a way around that problem. If my DSL makes it easy to write scenarios quickly, and my tests are cheap to run, there's not much advantage in trying to optimise the tests, if that comes at the cost of making them more complicated - always a bigger cost in the long-run, in my experience. So I'd nearly always write the separate test, even for a tiny feature.

[@OverPwng]

About the last point "Avoiding user story ordering"... Isn't ordering inevitable? In your example for #4, your stories are ordered so aren't you contradicting yourself? For example, you can't address password security before passwords are implemented... Or am I understanding something wrong?

[@ContinuousDelivery]

No, I don’t think you are misunderstanding, and it’s a fair question, but the difference, at least to my mind, maybe a bit subtle. The difference is where does the ordering come from. There is ordering in my stories, but it is order implied by the value to users, not by optimising the development for technical reasons. If the user wanted strong passwords first (probably a bit crazy in this example, but if they did…) there is no technical reason not to do it.

[@OverPwng]

@@ContinuousDelivery Aaah I get it now. We want to avoid ordering based on technical requirements, while ordering based on story coherence is fine.. Makes a lot of sense!

[@stevehopper8086]

i understand two things 1. not to have a monster story , but split with a view to complete smaller stories in a single sprint 2. from another Continuous Delivery video not to have technical stories. So at moment, our team split a monster story into technical stories that can be completed in different sprints. I agree this is not good, so am after ideas. We are a Business "Intelligence" team where a typical example (a) is waiting for a source system to capture new data --> (b) we amend ETL for BI datawarehouse --> (c) we update a PowerBI dataset data model --> (d) we publish new PowerBI report that provides business value. obviously (d) is the user story, and (a) --(c) are technical tasks that will be spread across sprints.. Open to any ideas about how to split this story into User stories. These two apparently conflicting principles are causing a lot of unresolved debates in team

[@stevehopper8086]

i've read about vertical slicing which sounds great but can't see how to apply it in this example

[@WorthyVII]

When a user story would require both some backend and frontend work, and assuming we want to do this in the "CI way", how should teams manage this if the front and back end repository are separated?

[@ContinuousDelivery]

My first question would be, is it the right decision that front end and back end are in separate repos? If they regularly change together, then it is not a good choice to separate them. It adds complexity in the form of dependency management. For separate repos to make sense, each of these parts should be "independently deployable" that is, you can deploy them without first checking that they work with the other, this is the heart of the Microservices approach. If they are that independent, then each can be built tested and deployed independently of the others.

[@WorthyVII]

@@ContinuousDelivery Thank you so much for the reply. These were my thoughts exactly. They almost always change together when a new feature is introduced, which is why to me this make no sense. The reasoning behind it is that there are a front end and backend team working separately, but I don't agree with this logic. There's no reason two teams can't work on one Pull Request/branch. I suppose in the case where we had a separate company doing the front end work, some companies might argue they don't want to share backend code due to IP, but I suppose an NDA should protect from that situation and it should be ok to share source with other contractors. Would you agree? Thanks

[@dripcaraybbx]

I am curious what is the role of the designer in your view?

[@mathalphabet5645]

About the way you explained your registration in your stories. Did your previous teams work like that. It seems like a pleasurable experience. What i saw is login with full registration, mandatory phone number. Integration with other systems, like google, facebook. Full design made and then changed on the ui side and so on. Password reset. All in one story. Developed fully on a separate branch. Nightmare. Just nightmares.

[@Robert-ht5kd]

Where can I buy your t-shirt?

[@harag9]

Great video, Would really love our Product Owner to learn from this, but it won't change... But thanks anyway. All I can do is send them the link and hope they change their ways - they fail on all your 5 mistakes, and if this was a video about 10, I'm sure they would fail all 10 too.

[@ContinuousDelivery]

Sorry to hear it, I hope this helps a bit.

[@googleaccount5225]

How do you reconcile that a user story is both a conversation and something to deconstruct.

[@elfnecromancer]

How do separate UX/design teams figure into this? Once they've finished their work and it gets attached to a story, the requirements are pretty much written and it's remote control programming by design.

[@ContinuousDelivery]

Yes, my advice is not to do it like that! Design comes after stories, not as part of them. If you have a separate design team, I think that they should focus on patterns and general guidance and assets, not on the specifics of UI design for every feature. Mostly let the dev teams work within guidelines and figure it out for themselves.

[@robertlybarger]

I'll add to this. For background, at my work place (large retailer e-com site), we happen to use atlassian JIRA, and claim to follow a scrum/agile concept. The way things truly work (for loose definitions of 'work') is that a "JIRA story" is crafted (by an analyst, in response to direction from a product owner) which includes the high level AS-A/I-WANT/SO-THAT statement. It also includes links to designer art boards to dictate look-and-feel for front-end concerns. This same JIRA artifact further includes a listing of acceptance criteria (for QA) that relate to behavioral expectations. Once that is all drafted up, then the dev team is asked to 'estimate', at which point we are getting our first look at the feature. As a further aggravation, we (dev team) tend to be grooming/estimating a "story" artifact well into (read: past the starting point of) the working sprint that business expects us to deliver it in ... and then the negotiations start once dev pushes back on feasibility (due to technical baggage we have to contend with) but the sprint clock is still ticking. Also, these stories tend to be bulk shopping lists of bullet points, each of which could, in many cases, be broken out separately, worked separately, and tested separately. If we run short on time and a bulk story is only 6/7th's complete (meaning, QA will NOT pass it as complete) then the conversation wheels around into deal making about pushing pieces of the bulk story out to a separate ticket in the next sprint, and that eats up additional time/energy. And yes, it's as much of a mess as it sounds like it might be. Somehow we're still evolving things and generally hitting targets, but it feels like some of the energy involved is mis-spent. Naturally things will only work as well as people can communicate... and stories (and other artifacts) are a key player in that communication.

[@oldcountryman2795]

Designer "What information would you like on the summary form" User "All of it" User "Feature X is absolutely critical to our business, how much will it cost to implement?" Designer "$3000" User "Yeah, no. We can do without that"

[@kamertonaudiophileplayer847]

What about a user learning story? A user who just started using your app and a user who uses your app for an year or more are different users and have different values. Can your app adopt to the fact?

[@ContinuousDelivery]

I’d say they were multiple stories. If the user experience changes, based on the user’s experience, then they need something different in each case - two (or more) stories!

[@firkinfright5168]

There is more to values then just value. Monetization is the byproduct of a value delivered to the end user.

[@oussamaziani6422]

Since you are a pilot why don't you make video on the disciplines and the lessons you learned from flying planes and how they apply on software engineering.

[@_winston_smith_]

For a long project, say 10 plus years, how do the maintainers understand the requirements? If everything is based on stories and conversations it could be very difficult for a maintainer 10 years later to determine if modifications are ok. Let’s say the automated test suite starts failing after a maintainer adds an enhancement. How can the maintainer determine if the test is still relevant?

[@Farren246]

No project is 10+ years. Even a 1-year project's scope should be broken down into smaller, faster deliverables, with future deliverables changing according to changing needs.

[@SumoCumLoudly]

@@Farren246 nonsense

[@barneylaurance1865]

The maintainer needs to have a conversation with current users and stakeholders if it isn't clear. Even if exact requirements were written they may not be relavent if they are several years old. My starting point is that modifications to a system which is in regular use are never OK unless they are intentional. People may be relying on any aspect of the system behaviour. Often there are good reasons to change it, but it shouldn't normally be changed by accident.

[@AntonMochalin]

User Stories are definitely not a substitute for requirements. A subtask inside the user story can be dedicated to properly documenting the new feature if the documentation is expected to be needed in the future. Maybe even several subtasks for several types of documentation. Just like subtasks for development, writing QA tests, performing QA testing etc. But they all would be supporting that user story i.e. the behavior of the system.

[@ContinuousDelivery]

If you do a decent job, the acceptance tests, written in the ubiquitous langue (see last week’s video), give an accurate description of what the system does, even years later.

[@klodr]

Good talk. Since the beginning of the "user story" concept and its comparison with the old good "use case", I have treated them as very different animals. The user stories are user needs, but not in terms of a hypothetical solution, but as a business activity, a capability the user (a role) wants. It is common that the users of a system express themselves with user stories that point already to a "solution" based on their experience of other software systems. Common tasks and features, with well-known solutions, are proposed as a user story. I believe this is not totally wrong, but we have to distinguish them from the raw, human user story. On the other hand, I have combined use cases as a model of the solution. The use case (as a model) derives from the user stories as a representation of the ideal solution, that realizes the story of the user. Also, my programming style uses the use case as an interface of all the capabilities the hypothetical system should support (each step of the use case points to a method, for example). For me, this workflow and definitions of both have an impact on the requirements empirical validity from the user desire (story) to the real solution or implementation code. What do you think? Thanks again.

[@karsh001]

Most common mostake: to never involve the actual users iin the creation of user stories. Story: "As a user I want to see all products in a list so that I can get a good overview and easily choose what I'd like to order." Break that down into more user stories and requirements. How long can a user wait for the list?

[@CTBell-uy7ri]

Love your videos Dave, I just think your thumbnail images haven't been as flattering lately. Maybe it's something in the edit, but it makes your skin look kind of blue/red, instead of a more natural pink/orange. It's weird I know, but I just want to see you succeed. A little lighting or process rework would go a long way. Hope that's constructive, Cheers and love your content.

[@ContinuousDelivery]

Thanks for the feedback

[@jimiwikmanofficial]

Mega stories sound more like features, or even a full scale need? A feature is a collection of code that provide value. If you make a new feature, then you have many user stories that make up each logical development task to fulfil that feature. If you expand on an existing feature, then you will just add more user stories to an existing feature. User stories also should have a small set of acceptance criteria, or they are too big. It falls upon the developers and testers to break down the need to proper sizes together with the need owner.

[@THEMithrandir09]

How would you suggest structuring e.g. user systems in user stories? Typically one may look at CRUD, but is this one or four stories? And if it's four stories, wouldn't they all implement e.g. your networking REST calls redundantly? Isn't that bad as well? Or do you just accept that and fix it when refactoring?

[@kahnfatman]

Would you give us examples which demonstrate USE STORY cannot be used at all to describe any deliverables? I mean an irreducible complexity. When broken down, the deliverable cannot be used. When kept as a whole, the story is too big.

[@erikvolger5631]

Do we have an acronym (like SOLID or ACID) to describe how user stories should be written? Based on this video I came up with a first draft: Small: a story should be small enough to complete within a sprint Atomic: a story should be without dependencies to other stories Descriptive: a story should describe what the system does, not how Implementation freedom: freedom to choose any implementation Special: "value" means "valuable" Testable: there must be a way to check that the implementation satisfies the story The acronym (after reordering and adding a 6th) I came up with is SADIST. The last two I am not happy with. I'm sure we can think of a better one if we work together. Any thoughts???

[@ContinuousDelivery]

🤣 Not sure that 'SADIST' sends an encouraging message. The usual acronym, which I didn't reference in this video is 'INVEST' Independent, Negotiable, Valuable, Estimable, Testable www.kaizenko.com/6-attributes-of-effective-user-stories-invest/

[@erikvolger5631]

INVEST is indeed better and already existing... Thanks!

[@someguy3176]

We talk to each other about what we want to build and why. The way to write user stories (or whether to even have them at all) should be secondary and is a means to an end.

[@meelanbawjee]

It would be great if you could bring up real world examples and critique them. Some of us prefer practical instead of the theoretical info. A lot of what you saying is good in theory but I'd like to see how you apply it

[@ContinuousDelivery]

You should probably watch some of my “real world example” videos then 😁

[@PeterManger]

I love this, I feel like it validates all the silly things I’ve seen. I lost many jobs because I said “requirements are overrated”. I (accidentally) managed to keep “finding my tribe” with this attitude. The most successful tool I ever built was a buggy dodgy graphing tool that exposed underlying data no one knew could be retrieved and a manager saw it and said “I want that!”. I said it sucked and crashed after rendering the graph. User didn’t care. And a week later everyone was using it - crashes and all. The user NEVER asked for that 6 months ago when project started, and the product they originally wanted never really got used.

[@iliumboy]

Wow, you accidentally built a crappy doghouse all by yourself. Did you use Agile? What happens if the client wants the Freedom Tower? Would "requirements" be overrated then? As a client paying the bills, I would've tossed your butt too.

[@PeterManger]

@@iliumboy yeah, we're so dumb as to not apply judgement and logic and adjust to environmental consideration. So sorry, I forgot to mention I only work with intelligent people too. Context is everything.

[@pilotboba]

I'm curious, do you use user stories to define non-function parts of the system? What about technical parts? Non-functional: As a user I want the list of accounts to display in under 3 seconds. As a user I want the payroll to process at least 1000 employees a minute. Technial As an Operator I want to deploy the system to AWS without using the console. ???? As an Operator I want the system to run in a containerized runtime. ???? As an Operator I want to be able to define the log level for a specific tenant ??? Or are here other ways the technical architecture is described and tested. This kind of stuff can't be organic... someone has to decide and define, here's the runtime environment at the least I would think.

[@ContinuousDelivery]

Yes, your non-functional examples aren’t really stories, because they don’t express an outcome - why “under 3 seconds”? These are poor measures of success, they are guesses. The technical ones aren’t really stories, or requirements, they are design choices. What are the reasons that these design choices make sense? Those are IMO more effective as stories or requirements. Otherwise we end up with requirements as “coding by remote control” which I think these are.

[@pilotboba]

@@ContinuousDelivery I don't understand "more effective as stories"? Is a story different than a user story? Performance is not so much a guess as a performance requirement. Granted many of them are meet with a combination of the code and the environment. Thanks.

[@ContinuousDelivery]

@@pilotboba My point was not really about a difference between "stories" and "user stories" but that what you listed didn't really, to my mind, count as either. A user doesn't wan't the accounts to display in under 3 seconds, they either want the results much sooner than that, all the research says under 400ms or they want an indication that this will take time, then you have more than 3 seconds. A user doesn't care at all that the payroll processes 1000 employees a minute, they want something else - what is it? These are tasks, from the perspective of a development team, so they aren't user stories. The limits that you mention are a guess, what are the reasons behind those guesses, they may lead you to better solutions. Capture that in the requirements, and you may end up with these numbers, but these numbers aren't the real goal - better to measure achievement of the real goal.

[@barneylaurance1865]

I like the principle of user stories being about problems not solutions, but it can't be an absolute rule. As John Cutler points out, any stated problem tends to assume a particular assumed solution to a more general problem. I think you have to choose a solution at some level to be able to write a user story. A user story of "As a human I would like to increase the net sum of happiness in the world" would not help me build software very much.

[@ContinuousDelivery]

Then again, its not really a user story, more of a fond wish. I don’t agree that you need to choose a solution, “pay by credit card” doesn’t chose a software solution.

[@barneylaurance1865]

@@ContinuousDelivery But the credit card itself is a solution. Other solutions to similar sets of problems exist - e.g. the vendor could extend credit themselves, or you could take payment by cash on delivery, or you could remove the need for that person to pay entirely and make money through advertising something to them instead. In some cases I think it will make sense for developers to participate in choosing between those solutions as part of a cross-functional team, in other cases it will make sense for them to be asked to just solve the problem of letting users pay by credit card.

[@barneylaurance1865]

I think this is the John Cutler tweet I was remembering: twitter.com/johncutlefish/status/1354233412081446913

[@Nikifuj908]

@@barneylaurance1865 User stories are written from the user's perspective. Users are not necessarily technical people; they don't necessarily have a solution to their problem in mind. Imagine you're at an unfamiliar museum and need to use the bathroom. Just because you're able to ask where it is (i.e. state your problem), does that mean you already know how to get there (solution)? Of course not. You may be able to state your problem, but it doesn't mean you have a solution.

[@Nikifuj908]

@@barneylaurance1865 You may be right on some level... but I don't see this as a promising line of thinking. You can easily state solutions later down the line.

[@orange-vlcybpd2]

5:49 "The job as the software developer is not to write the code, it's to solve problems". I want to frame it and hang it on the wall in my office. I wonder, where did the software industry took the wrong turn...?

[@michaelrstover]

"As a user, I would like this web app to look nicer". I don't know what I'd do with that. If a story doesn't come with well-defined acceptance criteria, how can I know when I'm done? Whenever we have this kind of story, it bounces back and forth for days between dev and qa folks in disagreement about what "nicer" means.

[@ContinuousDelivery]

Yup, not really a user story, more a vague wish.

[@michaelrstover]

@@ContinuousDelivery Your main example is "make it easier to find a song". And the problem is the same. The only way this works is if we have a real extreme programming setup and the stakeholder can see results multiple times a day to provide feedback. Otherwise, I try something, get feedback a day later, try again, get feedback a day later, try again... All trying to guess what "easier" means. It's no wonder we get to the point of demanding stories come with acceptance criteria so we have a prayer of getting it done.

[@ContinuousDelivery]

@@michaelrstover Yes, you need to iterate too. That is how you create good products - it works better than omniscience 😁😎

[@dehman6836]

Thanos of user stories

[@JaumeSabater]

Voice recognition software, in a login form, in Scotland? It's not going to work... Eleven! 😀

[@SumoCumLoudly]

Tests don't exist in my reality, its very nice.

[@ContinuousDelivery]

How do you know your software works?

[@SumoCumLoudly]

@@ContinuousDelivery i use it

[@SumoCumLoudly]

@@ContinuousDelivery im working solo on a tool that I'm also the target audience for, so its not a common circumstance, but ive not yet been convinced what benefit tests have for me, maybe one day i will see. I should add, i move slowly and i dont move to the next part till im happy with something, so there is some peace of mind in that. Each part is all that im capable of. When you are responsible for the whole system you dont break things accidentally, its not an issue for me.