[HN Gopher] Write tasks not user stories - Linear Method
___________________________________________________________________
Write tasks not user stories - Linear Method
Author : yellowyacht
Score : 61 points
Date : 2021-04-14 16:15 UTC (6 hours ago)
(HTM) web link (linear.app)
(TXT) w3m dump (linear.app)
| macspoofing wrote:
| >User stories evolved over twenty years ago as a way to
| communicate what a customer wanted into product requirements that
| a software team could deliver. ... Customers are tech-savvy
| enough to articulate basic product requirements
|
| HA. Sure. 20 years ago Customers were dum-dums, but today
| Customers are tech-savvy.
|
| >issue should describe a task with a clear, defined outcome.
|
| The point of user-stories is that the implementing developer also
| has a brain and is able to contribute to the solution. So a user
| story is supposed to communicate the problem the customer is
| trying to solve so that the specific solution can be derived
| collaboratively. Nothing is worse than writing a task to turn a
| developer into an automaton.
| NorthOf33rd wrote:
| I often write both, sometimes just a task, sometimes a story,
| sometimes I'll only include a sketch. The claim that User Stories
| are "dead" or an "anti-pattern" is silly. What's an anti-pattern
| is to claim that your communication method works best for all
| projects, teams, contexts and times.
|
| In my experience, for new teams the more detail the better. For
| these teams I often write both. They need the additional
| information and it helps them get in the head of the customer.
| Sometimes for well gelled teams switching to a new context I'll
| do this. Or, sometimes for well gelled teams working on a problem
| space where there's alot of nuance in the solution, or maybe it's
| a departure from the norm and there's a good reason, I'll write
| both. Sometimes I'll be in planning and realize that the team is
| missing the picture and I'll write a user story on the spot and
| things will click.
|
| For teams working on a space they know well sometimes just a
| description of the issue is enough. They know how to fix it and
| why. I dont need to waste my time or theirs writing contrived
| examples. They probably dont need a task to tell them what to do.
| They can figure it out.
|
| Also, this is BS:
|
| 1)Customers are tech-savvy enough to articulate basic product
| requirements. -- Some (few) customers are savvy enough to
| communicate basic requirements but I've rarely met a customer who
| can articulate edge cases and considers their needs in context of
| the system- either technically, economically, or socially. Part
| of the value of a user story is the abstraction.
|
| 2)We've developed standards for common features such as shopping
| carts, todo lists, and notifications so there is no need to
| explain how they should work.
|
| -- No we haven't! Go checkout at 5 different stores and tell me
| how many are using an identical cart. Even stores that use
| identical cart providers have widely varying carts because
| business and user needs are different and everyone is playing
| with their own ways to optimize conversion. I think it might be
| difficult to find a better example of something that's not fully
| standardized than a cart.
|
| 3)The best product and engineering teams understand their users
| deeply and are familiar with how their product should work.
|
| -- "Best" is operative here... the best teams I've worked with
| like user stories because they frame the requirements in the
| context of the user instead of assuming the PM/PdM/Whoever has
| the "correct" solution.
| tommymanstrom wrote:
| A pragmatic approach, which I value as a team member!
|
| Currently my small team is using "user stories" for deliverable
| value and tasks as default for everything else.
|
| Sometimes there are longer descriptions as the why is important
| to add (for future team members and myself) to "user stories".
| mumblemumble wrote:
| I've started writing a one-sentence description of what we'll do
| to demo the feature to stakeholders. I find that this approach
| tends to leave much less room for confusion than the user story
| formula.
|
| Also, "Can I fit it into one reasonable sentence?" is a
| surprisingly good litmus test for whether the task is right-
| sized. Not necessarily in terms of implementation effort, but in
| terms of scope.
|
| User stories might be good for a Scrum product owner who's trying
| to juggle a more nebulous set of ideas in a product backlog. By
| the time the work's ready to hand off to the dev team, though,
| you should be able to come up with a something more concrete and
| concise.
| clavalle wrote:
| I find the opposite.
|
| It is too easy to fit Really Hard Problems into one, seemingly
| innocuous, sentence.
|
| The 'reasonable' requirement is a tough one to get people to
| agree on, especially if they don't have a firm grasp on what is
| possible.
|
| For example, I've seen one sentence requirements like
|
| "Let the user import legacy data".
|
| Depending on the systems, that's either a one liner script or
| an entire industry.
| MattGaiser wrote:
| It is also going to lead to wildly different implementations
| developer to developer unless they have a really solid
| understanding of the project. And given how frequently we
| turn over, that rarely exists.
|
| I usually don't really know anything about how the code I
| write will be used in practice.
| mumblemumble wrote:
| "Let the user import legacy data", though, is not a one-
| sentence description of a _feature demo_. "Import a
| transaction list file in version 1.0 of the format and show
| that it loads all entries," would be more like it.
| dragonwriter wrote:
| > User stories evolved over twenty years ago as a way to
| communicate what a customer wanted into product requirements that
| a software team could deliver. Fast forward to today and a lot of
| things have changed about how we build software. Customers are
| tech-savvy enough to articulate basic product requirements.
|
| I'm jealous of your customers if that's true for you. But, IME,
| not only are customers no better at spontaneously producing
| requirements than they were 20 years ago, IT organizations--
| _especially_ ones that have notionally embraced "Agile" methods--
| are much worse at eliciting requirements, or even understanding
| what they should look like. It's like the entire understanding of
| requirements was the baby thrown out with the bathwater of big
| upfront design.
|
| And this article on tasks instead of stories is a further step
| down that path of losing knowledge. Yes, once you have
| requirements, you need to task out the implementation. But tasks
| don't replace description of requirements, whether in the form of
| stories or any other form.
| zabzonk wrote:
| I've pointed out before that the job description of "Systems
| Analyst" seems to have disappeared i.e. someone who's job it
| was to understand and describe requirements. I agree with you
| about the baby and the bathwater, though to be fair there was
| often quite a bit of bathwater.
| ivan_gammel wrote:
| It will come back with more regulatory pressure, but under a
| different name, because startups tend to reinvent the wheels
| and give funny names to the old ideas. I won't be surprised
| if someone will come up with a new RUP soon, because
| compliance will dictate the need for formal requirements,
| RTMs and QA processes.
| Pokepokalypse wrote:
| >It's like the entire understanding of requirements was the
| baby thrown out with the bathwater of big upfront design.
|
| I shall quietly agree with this.
| clairity wrote:
| there are certainly some subset of customers who can write
| effective product requirements for any product, but certainly
| not all or perhaps even most.
|
| the point of users stories is not to lose sight of the origins
| of a domain traversal problem (from customer/problem domain to
| product/solution domain). jumping straight to writing tasks
| assumes high intimacy with the problem domain _and_ the
| solution domain, which few people possess. the best product
| managers have both of those, _and_ still are humble enough to
| regularly test their assumptions by writing user stories first
| backed up by quantifiable customer experience.
| mateo411 wrote:
| I think requirements and design documents are necessary for any
| project of a certain size. In my organization we try to do this
| for a project that will take a few Sprints. A Sprint is 2
| weeks. The requirements and tech design don't have to be
| perfect, and they can be updated, as time goes on. If updates
| are signficant, then we point that out, and adjust deadlines.
|
| The nice thing about this is you have a document that describes
| what we built, and another document which describes how we
| built it, at the end of the short project. We scope these
| projects so they can fit into a quarter. If it's longer than
| quarter, we try to break it down by certain milestones.
|
| I also don't like User Stories, maybe it's just how they are
| set up in JIRA, but once you have the tech design, it's pretty
| easy to break it down into tasks. This mostly works for my
| company.
| tkiolp4 wrote:
| > A Sprint is 2 weeks. The requirements and tech design don't
| have to be perfect, and they can be updated, as time goes on.
|
| > This mostly works for my company.
|
| What is working for your company (and others) is: delivering
| software FAST. Which is good and all, but I think it's
| important to highlight this because sometimes, some people
| prefer to deliver maintainable software in a paced way (no
| sprints, but marathons... I hate the analogy but hey).
| evrydayhustling wrote:
| A similar quote that gave me a double-take:
|
| > [Project teams will] understand the user experience
| intuitively, so you don't need to clarify it at the task level.
|
| My god, the hours I've spent under both engineer and PM hats
| because of misalignment about what the user experience is
| supposed to be! "The task said 'enable color selection', not
| that the old color should be _un_ -selected."
|
| This philosophy seems to be leaning really hard on the
| assumption that your team is re-implementing well-worn
| patterns, but shouldn't items that are so well-worn as to
| require no explanation or context just get subsumed into
| higher-level stories?
| hamdouni wrote:
| > Customers are tech-savvy enough to articulate basic product
| requirements.
|
| Alas, I've got no customer like that.
| cgrealy wrote:
| Tech savvy? I'd be happy if customers understood their own
| problem domain, let alone be tech-savvy enough to articulate
| product requirements.
| grawprog wrote:
| >At Linear, we don't write user stories and think they're an
| anti-pattern in product development. We write short and simple
| issues that describe the task in plain language instead.
|
| I found it kind of ironic they lead with this, then proceed to
| describe their issue tracker using a long winding story that took
| a while to actually get to the point and before I could even
| figure out what this actually was.
| endiangroup wrote:
| AD: I call BS... There is a fundamental difference between
| functional requirements and the tasks required to implement them.
| Note there are NO examples in that article, and I bet you it's
| because it was hard to think of context free tasks... because
| context is everything and thats what your functional requirements
| provide your tasks.
|
| User stories capture functional requirements:
|
| ```
|
| As a restaurant guest
|
| I want to consume food
|
| Because I am hungry
|
| Scenario: Guest is provided with menu when they are sat at their
| table Given there is a free table When
| I am sat at my table Then I should be given a menu
|
| ```
|
| This is BDD style, I don't really care what you think of BDD it
| covers what I need to make the point... First of all context is
| king, there should be NO scenarios here that do not satisfy the
| guest being hungry, thats scope creep. Equally there is NOTHING
| here about HOW you implement this, it does not mention who gives
| the menu, what the menu contains, how it looks or anything about
| the rest of the restaurant. Why is that the case? Because we are
| at a level of abstraction that is talking about delivering value,
| not about the quality of what we deliver. You can only deliver
| value to users so we can only talk about users and their
| experiences. Now as for tasks, they are derived from these
| functional requirements, they connect what currently IS to what
| needs to be, e.g. if we currently give guests a menu when they
| enter the door, thats what IS, now we need to go about creating a
| task to change that to when the guest sits down, thats the task
| and it is a poignant task because it's derived from our
| functional requirements, there is no room for scope creep here.
|
| Please do not write context free tasks, you'll run yourself into
| the ground in scope creep, because you're detached from what
| matters. That's why user stories are important... but most people
| don't write user stories correctly, they treat them like a task
| template and forget the value delivering aspect and all the
| context that goes with it.
| teachingassist wrote:
| I don't mean to pick on your example... but it's absolutely not
| true that I go to a restaurant because I'm hungry.
|
| There are other ways I can and would sate my hunger if that was
| my genuine motivation. For me to go to a restaurant, it does
| have to provide food, but that is not sufficient, since I can
| get cheaper/more convenient food elsewhere.
|
| A restaurant has to offer _something other than just food_ , or
| I won't go at all.
| endiangroup wrote:
| AD: Sorry you got bogged down in the details. Would you like
| me to put together a more thorough example? That one I wrote
| in 2 minutes.
|
| To clarify I picked /some/ value for the restaurant guest,
| but we could negotiate what the /true/ value is. I go to
| restaurants when I'm hungry and I'm sure others do, but
| you're right there are other reasons why you might go, but
| that doesn't detract from my point being made.
| teachingassist wrote:
| I commented this because I find it does relate to your
| point - in my view, you have identified a false
| motivation/incorrect user story.
|
| By my understanding, this is exactly what the parent
| article is identifying as potentially damaging.
|
| Quote from the article: "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."
| endiangroup wrote:
| So let's negotiate the true value? How else are you going
| to know if you're delivering technology thats useful?
|
| You said there are other reasons, what are those reason?
| I've gone to restaurants to meet friends... and
| ultimately we all eat to satisfy our hunger.
|
| My point is that tasks are derived from functional
| requirements, they aren't context free, and if you make
| them context free then we're just doing what ever we
| want? To analogise, why do you have relationships in
| databases and indexes? An index is a flat map to speed up
| lookups on known queries, you don't get at the meat of
| your query in the index, the meat of what you want is in
| the row and it's relationships. You have an object graph
| for a reason, and yeah it was the hard part, but it's
| what makes a model useful.
|
| ... and to counter the quote... What's the point of your
| users experience if it's not to get them to where they
| are deriving value?
| endiangroup wrote:
| AD: So this has been downvoted without refute... any takers? Or
| is it just bots...
| hinkley wrote:
| > There is a fundamental difference between functional
| requirements and the tasks required to implement them.
|
| Tasks that don't honor the 'why' of the work can make someone
| look productive when they are not (or indeed, when they are
| being destructive).
|
| I see the same thing in 5 Why's analysis. There's always one
| faction that wants to come up with an inactionable 5th Why. It
| is remarkably easy to steer such discussions to whatever agenda
| you are pushing.
| redler wrote:
| As has been said elsewhere, beware that zealot on your team
| who keeps on with the whys until the user gives up and
| screams, in tears, "because I don't want to die alone!"
| endiangroup wrote:
| I think the insight here is that if you're asking your user
| you aren't going to get the answers you want. This is why
| survey writing is so hard, because people can't just
| explain themselves on the spot.
| endiangroup wrote:
| AD: I completely agree, value > ego's.
| [deleted]
| 42droids wrote:
| I find, after creating software for 14 years, that 1) clients
| don't know what they want, 2) they can't communicate what they
| want 3) describing features is difficult it doesn't matter if we
| call it a story or an issue, 4) something will always change
| rmah wrote:
| Exactly right. One thing I often tell younger developers is...
| 80% of developing software is figuring out _exactly_ what you
| want to build. " Usually, the actual act of building it (i.e.
| writing the code) is fairly trivial.
| marcus_holmes wrote:
| After creating software for almost 30 years, this is still
| true.
|
| But...it's not their fault. Asking _anyone_ to precisely
| describe a complex system that is subject to change will have
| the same problem(s).
|
| This is why Agile[0] was such a breath of fresh air. And
| Iterative Prototyping, MVP's, all that. It's massively easier
| and quicker to slap something together, put it in front of a
| customer and ask them what's wrong with it, than it is to ask
| them what they want in the first place.
|
| In my experience a quick "it should do this" is good enough to
| get that going, and then iterate from there.
|
| [0]Actual Agile. As in the Manifesto. Not this Scrum bullshit.
| sumtechguy wrote:
| It is interesting to watch scrumm. I have seen it broken a
| few times now. Every single time it started off just fine.
| Then someone decides the process was more important instead
| of the intent. Then everyone just went along with it. Even
| worse someone knows they 'still dont like it' but keep
| tweaking it but making it worse instead of saying 'yeah that
| did not work _at_ _all_ '. Or my favorite is someone blows in
| and finds out you have been skipping one ritual (because it
| was low value to your team). Your team is then declared
| 'broken'. It is like there is some flaw in scrumm that allows
| for anti patterns.
| kbenson wrote:
| > But...it's not their fault. Asking anyone to precisely
| describe a complex system that is subject to change will have
| the same problem(s).
|
| Yes. In the same breath someone might denigrate users for not
| knowing what they want and also explain about how they can't
| accurately timeline their personal coding project where they
| are the only user and developer.
|
| Designing any complex system is hard. Asking users to take
| part in that design process means asking them to do something
| hard (or at least that's hard if done well, and hard to tell
| you aren't doing well unless you put in that effort you
| didn't know you had to). Complaining about bad user
| requirements as fine, but truthfully it should be done in a
| way that's self deprecating...
| rualca wrote:
| > I find, after creating software for 14 years, that 1) clients
| don't know what they want (..)
|
| I've logged in just to point out this fact, and to call out how
| the author of this anti-user stories rant is completely
| clueless and out of touch with the reality of developing
| software.
|
| The whole point of user stories is to not only specify an
| objective target but also a concrete definition of done, in
| spite of the clients' inherent ambiguity and flexibility, and
| very often also contradicting notions inherent to their asks.
|
| User stories report intent and context along with the goal.
| User stories adds information that helps developers help the
| customer. If you remove the out-of-band information, you are
| creating a process that is a throwback to the bad old days of
| waterfall, where saying that it's the client's fault that the
| devs built the exact opposite of what the clients were
| expecting.
|
| All which was old is eventually new again, and in the case of
| "linear method" the novelty is not having a clue of what you
| need to do to meet customer's demands and expectations.
| kaiju0 wrote:
| So very true. I usually ask what business outcome they are
| looking for and then tell them how I'm going to deliver that
| for them. Saves a lot of hassle.
| ljm wrote:
| Write user stories not tasks
|
| At Linear, we don't write tasks and think they're an anti-pattern
| in product development. We write short and simple user stories
| that describe the issue in plain language instead.
|
| The point of writing a user story is to communicate a feature. It
| needs to be clear enough so that the assignee can implement it
| and also give enough context so that teammates who need to know
| understand what work is being done. So the goal when writing user
| stories should be to do this as effectively and quickly as
| possible.
|
| Why user stories are not obsolete
|
| User stories evolved over twenty years ago as a way to
| communicate what a customer wanted into product requirements that
| a software team could deliver. Fast forward to today and few
| things have changed about how we build software. Customers are
| tech-savvy enough to articulate basic product requirements. We
| haven't developed standards for common features such as shopping
| carts, todo lists, and notifications so there is no need to
| explain how they should work. The best product and engineering
| teams need to understand their users deeply and are familiar with
| how their product should work.
|
| Tasks have become a cargo cult ritual that feels good but wastes
| a lot of resources and time. They're a roundabout way to describe
| features, obscuring the work to be done. User stories are time-
| consuming to write but tasks can silo engineers into a mechanical
| role where they code to the technical requirements instead of
| thinking about the user experience holistically at the product
| level. One reason user stories are complicated and difficult to
| scope is because they bring what should be product-level details
| into the focus of the developer. And frankly, they don't match
| how we fail to communicate about software in real conversations.
|
| A better way to write user stories
|
| Write clear, simple stories that describe features in plain
| language. Write your own stories. Discuss the user experience at
| the product and feature level, not the implementation level.
| Instead of spending time creating tasks, spend it talking to
| users and thinking through features before writing your stories.
|
| ...
|
| You get the picture. This article is picking a fight with user
| stories but the substance of the post remains fundamentally the
| same when you swap some of the words around. They're ascribing a
| failure of process to the wrong thing and contributing another
| entry to the long list of Agile Syllogisms.
|
| I think this post would have landed better if they just focussed
| on what they did in a more descriptive sense. The useful
| information is clouded by a desire to editorialise it.
| tibiahurried wrote:
| > The project owner writes specs and gathers feedback until we
| feel like we have the right approach. Only then do we start
| writing code.
|
| Uhm, it is hard to say what is the "right approach". I personally
| prefer a more iterative approach. You draft an architecture to
| solve the issue at hand and you iterate based on new
| requirements.
|
| I generally don't like when a group of "owners/architects" close
| themselves in the basement to come up with a bunch of specs and
| documents describing : THE SOLUTION
| cgrealy wrote:
| Yeah, the whole point of stories was to get away from "Software
| Creationism _"
|
| _ the belief that with a sufficently detailed specification, a
| normally talented group of engineers can magic a perfect
| solution without any customer interaction.
| twh270 wrote:
| I don't think the problem is "user stories" vs "tasks" vs
| "issues".
|
| I think people have taken the (relatively simple) concepts from
| agile (as described in the Manifesto) and surrounded it with a
| lot of (often rigid) process and structure.
|
| Many people really like the comfort that comes from knowing what
| the process/structure is. And problem-solving tends to add to an
| existing solution rather than examine whether something should be
| removed (per recent HN post).
|
| Consequently, rules/structure/process grow "unbounded".
|
| Fighting this tendency is hard because it goes against the easy,
| "natural" path.
| stakkur wrote:
| _" The best product and engineering teams understand their users
| deeply and are familiar with how their product should work."_
|
| Surely not. And ironically, it seems the writer is describing a
| developer-centric view, not a user-centric one.
| conductr wrote:
| As a self taught developer who only works solo I'd agree. Tasks
| is exactly how I think. I've never found a use for stories.
| However, I can imagine how they are helpful to teams who
| individually do not have the holistic bigger picture or may not
| have the context of knowing the end goal/UX component. For me,
| the tasks are brush strokes of the bigger picture and spelling
| it out in story form just to break it down to tasks is
| duplicative.
|
| That said, sometimes my tasks are bigger strokes like "Add edit
| profile functionality" where it's obvious I'll have to touch
| the backend, database, frontend, etc. I don't have to break
| this into tasks.
| macspoofing wrote:
| No kidding. If you write software for specialized domains, you
| may not be able to get developers with in-depth knowledge of
| the space (e.g. writing software for Radiologists).
| kube-system wrote:
| Whether this works on not depends on the team structure and
| person writing the task. Yes, directly writing tasks is more
| efficient, but it requires the person writing the task to deeply
| understand the perspectives of _both_ the development team and
| the people using the software.
|
| Most teams don't have (enough of) these types of people. It is
| fairly common for teams to primarily consist of people who are
| non-engineer users, and technical engineers who aren't intimately
| familiar with the users' jobs. If your team has these groups
| working together, and these lines aren't clearly drawn, then you
| often get people overstepping their bounds: users demanding
| technical changes that make no technical sense, and developers
| building features that make no business sense.
|
| And this isn't a fault of the users or developers, it's a failing
| of process. People inherently want to decrease friction in their
| requests and their interactions. Five completely reasonable
| requests over the course of a year might add up to a horrible
| application -- not because the user or the developer was at fault
| for making a bad decision, but because the entirety of the goal
| was never communicated. This is what user stories do: force
| different groups to fully communicate.
| ozim wrote:
| More humility, please.
|
| They found a way it works for their team and claim that they
| solved software development. Well on their team page they have 9
| super experienced members backed by big investors.
|
| Get a product where you have 3 teams with 30 developers (probably
| 20 juniors and 10mid/senior), 15 testers and and 20 business
| analysts/customer people, maybe 2 or 3 product owners to keep it
| somewhat tidy. Keep it lean because you have pressure from above
| to cut spending as much as you can, because there are no angel
| investors above you dropping helicopter money. Have an approach
| that will work in that environment. Then take it and implement in
| 2 more companies with the same result, then you can write what is
| and what is not obsolete in software development.
| 0xdeadbeefbabe wrote:
| As a reader of your website I'd like to see an example of this
| horrible antipattern or an example that discourages the developer
| from thinking about the hollistic work to be done.
| [deleted]
| simonhamp wrote:
| Hard disagree. User stories are a great pithy way to describe a
| high-level need with a supporting reason. They usually take only
| a few minutes to write quite a few and in group exercises we've
| been able to generate many very rapidly.
|
| The task/ticket however (and work to be done) is separate and
| derived from the user story. This can dive into architecture
| choices, _why_ this solution and _why not_ that one, specific
| implementation details and steps to achieve those.
|
| Both types have their pros and cons and work best when used
| together because they serve different people and different goals.
|
| Don't write something off just because you saw a post make it to
| HN p.1 - try things out for yourself and decide based on _your_
| team and _your_ needs.
| jkingsbery wrote:
| > 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.
| gpmcadam wrote:
| 100% agree. They lost me with the opening premise by displaying
| a fundamentally bad understanding of user stories and
| describing them as "obsolete".
| gumby wrote:
| I 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 wrote:
| > user stories (which far precede 20 years ago and come from
| the advertising world)
|
| Really?
| akiselev wrote:
| https://smallbusiness.chron.com/use-archetypes-
| advertising-3...
|
| User stories are just customer archetypes, themselves based
| on Jungian archetypes, adapted to software development.
| gumby wrote:
| > themselves based on Jungian archetypes
|
| Which has always amused me, given that Edward L. Bernays
| was Freud's nephew.
| akiselev wrote:
| Freud 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
| hk1337 wrote:
| This 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 wrote:
| We 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.
| candiddevmike wrote:
| What's always missing with any kind of feature work is context.
| User stories can kind of provide some context ("why"), but the
| best method I've found is to write expectations--it will do X, Y,
| and Z. Then have some kind of call to confirm understanding and
| provide context.
|
| A lot of companies skip or eliminate this last step because PMs
| are busy, developers are introverts, some other excuse. But the
| fact is, spec-only development very rarely achieves the desired
| outcome because the developer can't or isn't allowed/trusted to
| see the forest from the trees.
| marcinzm wrote:
| I totally agree. Developers are intelligent people who know a
| lot more about how to best execute a ticket than the people
| writing tickets. They however know a lot less about the context
| than the people writing tickets. Converting developers into
| task executing machines seems like you lose a lot of the
| advantages of having intelligent people in the loop.
| smoe wrote:
| I don't really care what it is called and what format it comes
| with, but understanding the why of a task is crucial to me.
| There is a good chance that I over- or under-engineer
| otherwise. And understanding it I can often come up with
| simpler more maintainable results than if someone imposes the
| solution on me without talking about the problem.
|
| Also spec-only development is horribly boring in my opinion.
| splistud wrote:
| So far all of the comments here are just dances around how we
| perform business analysis. It is a role, is it a process, will
| we split it into pieces in our workflow, will we do it along
| with a prototype?
| endiangroup wrote:
| AD: Agreed! I'd look into BDD as an exploration and
| specification process (it's not just a testing methodology!),
| it taps into the goals of your users and features that satisfy
| those goals. See my comment below for a crude example.
| quacked wrote:
| The main issue I've found with Agile is that in the two
| iterations I've seen (one BigGovCorp, one late-stage startup),
| the team ends up with a situation analogous to audience members
| directing a movie. You can collect a list of audience
| requirements (explosions, romance, Chris Hemsworth, a string
| quartet, Garfield) and then your devs can string them all
| together into a single package that _technically_ works, but
| there 's no rhyme or reason or predictable trend of what the
| software _is_.
|
| Furthermore, as other commenters are mentioning, once you start
| focusing on your ticket system, developers feel "done" when the
| tickets are done, rather when they believe that what they've
| implemented is actually a functional, conceptually consistent
| piece of software.
|
| I don't think there's any solution except "get the right people
| and then try a bunch of crap and stick with whatever gets the
| best results measured against the goals of leadership."
| ElijahLynn wrote:
| Article could use some examples. e.g.
|
| Instead of: <user story>
|
| Do this: <suggested format>
|
| Repeat 2x.
| endiangroup wrote:
| +1, without examples it's theoretical none-sense.
| [deleted]
| darkpicnic wrote:
| I'm glad to see this article is eliciting in others the same
| reaction I had when reading it. I'm a huge fan of Linear and use
| it for our company, but this article just has so much hand-waving
| going on it's staggering. Where is a single example? They claim
| that user stories are outdated, inefficient, not valuable and yet
| show no alternative to the seriously difficult problem of
| engineering tasks missing context and purpose, especially after a
| certain amount of time has passed. I can't count the number of
| times I've fired off a one-line task thinking "This is fine. I'll
| remember what I need to do when I get to it" only to, after a few
| weeks, go "WTF?".
|
| The part about writing your own tasks is also strange. So my
| coworker finds an issue and instead of just writing the task out
| with context, explanation and direction, he has to... explain it
| to me in some medium... then I go do it? Really?..
|
| I feel like this article was written as some kind of SEO "let's
| just get people here looking at our product" kind of thing. I
| can't believe this was written by someone who actually writes
| software.
|
| (edited for typos)
___________________________________________________________________
(page generated 2021-04-14 23:01 UTC)