4 ms·
> User stories are time-consuming to write and read and can silo engineers into a mechanical role where they code to the issue requirements instead of thinking
by jkingsbery 6y ago
> User stories are time-consuming to write and read and can silo engineers into a mechanical role where they code to the issue requirements instead of thinking about the user experience holistically at the product level.
A few problems with this:
1. User Stories, as described by Mike Cohn or in some other textbook description, are supposed to be light weight. They are time consuming to write only in so far it takes time to understand what is the 1-2 sentence summary of the thing to be done.
2. User stories are intentionally ambiguous to avoid "siloing engineers into a mechanical role where they code to the issue requirements." A User story says, "When you're done writing code, here's the thing that needs to happen. Tasks are useful when there isn't much ambiguity, but I've certainly worked with developers who take the approach "I wrote the database table task, I did the Java code task, I did the JavaScript front end task, I'm done" without sanity checking if everything works together.
3. A User Story literally says what the User Experience should be like. Even if that were the wrong approach, I fail to understand how telling developers "Here's what the User Experience should be like and why they want to do that thing" prevents them from thinking about the user.
Overall, even if there's some truth here, this is a silly article. Stating "User stories evolved over twenty years ago" isn't helpful, because tasks evolved even longer ago. User stories are supposed to be "short and simple" and "describe the task in plain language." I'm really left wondering if the things they call "tasks" and "user stories" are the same thing that I use for those terms.
- hk1337 6y agoThis is how I always thought of User Stories and tasks are just a list of items that need to be done to complete that user story.
- taberiand 6y agoWe organise our tasks into a hierarchy where the outer Feature is user-oriented, the next level down (Product backlog item) are the developer-oriented detail of the user feature and the next level are tasks that break down the work needed to compete the PBIs, in 1-8 hour chunks. Features can parent features, so what we end up with is whatever amount of detail is necessary to capture the user stories and other requirements, under which are the work items the developers care about. I think this separation provides a decent balance between producing the features the users need while still allowing developers to focus on the actual technical work required.
- montroser 6y agoYes, this makes good sense. We do it this way too. Stakeholders and executives can easily grok the top level items, described in terms of their UX and business value, and then those are broken down into tasks that product/tech/design folks can execute on. Subtask[1] is one tool that makes this really easy and fluid, because you can break down everything into parts and the parts into parts, etc etc. [1]: https://subtask.co https://subtask.co
- gpmcadam 6y ago100% agree. They lost me with the opening premise by displaying a fundamentally bad understanding of user stories and describing them as "obsolete".
- gumby 6y agoI agree with you, but feel compelled to point out the (slightly) insightful part is "Customers are tech-savvy enough to articulate basic product requirements." There are consulting projects where the customer knows what they need and can spec it. They are similar to "we need a brick wall built here; use a core of breeze blocks and clad it with brick up to four foot high". You can write the needed tasks easily and get to work. As you point out, user stories (which far precede 20 years ago and come from the advertising world) are a step above (or before) that, to cover "Oh, people need to be able to look in through this fence; if it's solid then it can't be higher than five feet, maybe less". This essay would have been better as a short, "don't cargo cult things like user stories when you're already past the point"...but instead they cargo-cult it by inverting the sense and advocating throwing them away.
- twic 6y ago> user stories (which far precede 20 years ago and come from the advertising world) Really?
- akiselev 6y agohttps://smallbusiness.chron.com/use-archetypes-advertising-38626.html https://smallbusiness.chron.com/use-archetypes-advertising-3... User stories are just customer archetypes, themselves based on Jungian archetypes, adapted to software development.
- gumby 6y ago> themselves based on Jungian archetypes Which has always amused me, given that Edward L. Bernays was Freud’s nephew.
- akiselev 6y agoFreud and Jung actually became close friends over a decade before Jung coined his archetypes so that might be how Bernard got exposed to the ideas, even though (IIRC) Freud and Jung had a falling out later. Bernard would have been in his 20s or so
- actf 6y agoIn my experience the problem is that when written as you describe them - user stories represent features and are rarely, if ever, granular enough that they represent a "thin vertical slice" of functionality - as scrum likes to call it. I've always felt this was something scrum did a poor job of addressing. I have found that using user story format for epics or for features, and then further breaking those down into tasks seems to work quite well. Although as far as I'm aware there is no concept of a "task" in scrum. Task seems to be a Jira concept.