Requirement Specification vs User Stories • Dave Farley • GOTO 2023

[@xorfive]

I feel this talk is missing sufficient discussion on how the user stories are translated into design. A story isn't enough to hand over to a team for implementing. Agile often glosses over or skips the essential step of software design. Design can't just be quickly hashed out at the beginning of a sprint. There are often large architectural requirements that must be met (the whole system must follow certain patterns). Agile doesn't really address these. IMHO until agile acknowleges the missing design step, it's not a complete and functional methodology.

[@markwalker3484]

This observation about the misunderstanding of agile as mandating no design is addressed in: kzbin.info/www/bejne/i6upoXmHnMp4r8U

[@philippeparisot6061]

A team can create design/implementation specs AFTER the US is handed off to them, trust the team, they're trained engineers EDIT: Agile isn't all scrum, you're definition of Agile = sprints is incorrect. The team can totally look at implementation only one US at a time when the team (or part of the team) is ready to implement said US.

[@M0rd7ust]

A user story isn't even a handover artifact to "a team for implementing". It's a promise for conversation(s) around the sense as described in the story. Design is an ongoing process, anyway. It's also typically rather specific to the tools used, so "agile" cannot and will not tell you exactly how to design. You'll find about TDD (smaller scale typically) and DDD (for scaling up) if you're interested, though.

[@philippeparisot6061]

@@M0rd7ust okay so you're not aware of BDD? Teams can create their technical tasks in their own time from a user story written in BDD format. I'm surprised you didn't mention this even though you clearly stated TDD and DDD. Look up BDD "three amigos".

[@PaulSebastianM]

I think lots of PMs might be triggered or feel outright insulted if they heard this. 😂

[@diomepa2100]

I would very much disagree that it's a software developer job to extract what the client/end user wants or needs. If PO come with request and design of hot dog birthday cake, that's what we are making, lol. If it turns out the order was hot dogs and cake, it's in the PO job title to OWN that bs product they asked for. You can't have one person make the decisions of what product should be and should do, and then pass the responsibility(blame) to the dev team which built exactly what they were told to build, but it missed the mark. And yes I know PM/PO is not agile concept, but as long as they are running the show, it's their job to figure the requirements.

[@jangohemmes352]

I in turn, completely disagree with your take. Proper software development involves the developers in deciding on what the software needs. Their input is invaluable. Surely you can agree the company you used as an example would be a lot less dysfunctional if you wouldn't have a team blindly implement a hot dog birthday cake? I think it's a developer's job to own their work. They know too many valuable things to not participate in the decision making process.