Why user stories belong in the garbage
browserlondon.com
browserlondon.com
Could you explain some of your reasons?
1. The context of the software. Where does the software “live” in the world? A context diagram is very useful.
2. The major interfaces. What are the channels, formats, data structures, etc. Interface control documents are very helpful tools, as are any number of diagrams depending upon the application.
3. The concept of operation and “user story.” This is a top-level description of what happens when, why, and how to whom? This involves timing, aesthetic, user inputs, safety/security, other usability factors, outputs/results, etc. When you try to describe how people use the software, salient requirements can be discovered. It also helps to create a wireframe that can be shared with the customer to uncover more details or steer the requirements in a different direction.
4. Develop a draft set of requirements. I won’t go into detail, but this is the culmination of the preceding steps.
Good luck.
1. https://www.browserlondon.com/blog/2022/05/11/user-story-map...
1. As a customer I'd like to confirm my opinions about how stories are a waste of time.
2. As a customer I'd like to confirm my opinions about how stories are essential to the requirements discovery and design process.
You can throw them away, or you can stop destroying the useful part, and get useful stories to work with. You'll just have to accept that they are not standardized.
Really, there two basic ways to specify some software. The algebraic way where you enumerate (ideally independent) capabilities, and the narrative way with stories. Those lead to very different kinds of software, that fit better different problems/users. Throwing one of them away is a great loss.
Not exactly. The story is there to document something you want the software to do, phrased in terms of the value to the user. Once you generate a list of tasks from it, you still need to actually execute the tasks and see if by completing them, you deliver the desired value as expressed in the story. So no, you wouldn't destroy the story once you listed tasks. Once the tasks are done, you still need to circle back and either verify that the goal of the story has been achieved, or that the story is no longer a valid statement about the software.
My understanding of User Stories is that there's a story per task, so, to some extent, both itches are scratched with a well thought out set of User Stories.