6 ms·
> Relying exclusively on user stories as the source of requirements [...] is not sufficient for the design of solid systems. This narrow focus is one of the mai
by tqi 3y ago
> Relying exclusively on user stories as the source of requirements [...] is not sufficient for the design of solid systems. This narrow focus is one of the main limitations of agile methods.
This feels like a strawman - does anyone actually build software this way? I've worked at a place where the a user story isn't considered in the context of the broader product. No one has ever been like "this user story says they want to be able to share their location with a friend" and just slaps a share button on it an calls it a day. In my experience, teams generally think in terms of how that could best fit in with other functionality. Some are certainly less successful than others, but I think that was probably because the teams were bad, not that the stories were bad requirements.
- michaelt 3y ago> This feels like a strawman - does anyone actually build software this way? I've seen teams perform this cursed sequence: 1. "As a user, I want my pipes to stop leaking" 2. Replacing the leaking joints and pipes would be very time-consuming, we should produce an MVP using duct tapes and drip-catching buckets an intern empties every day, to confirm that users really want this. If they do, we can redo it properly later. 3. New feature released - pipes stop leaking. Great job everyone. 4. Redo it properly? Our users aren't asking for that, their pipes aren't leaking any more. Interns aren't users.
- imbnwa 3y ago>This feels like a strawman - does anyone actually build software this way? Oh yeah, fam.