[HN Gopher] User stories? thanks but no
___________________________________________________________________
User stories? thanks but no
Author : jandeboevrie
Score : 27 points
Date : 2023-05-19 18:32 UTC (4 hours ago)
(HTM) web link (beza1e1.tuxen.de)
(TXT) w3m dump (beza1e1.tuxen.de)
| namaria wrote:
| There's too much vertical integration in software development. We
| need more 'programming at the edge', with professionals who
| understand a domain well and can write and build software.
| There's way too much bs in between business needs and building
| tools to do the jobs that people need to get done.
|
| There's way too much complexity involved in building software,
| and the reason is pretty self evident. Most hardware and most
| developers are employed by gigantic corporations that extract a
| lot of rent from the rest of the economy.
| joahua wrote:
| I like your "programming at the edge" turn of phrase.
|
| Centralised IT functions have some bearing here at an org
| level, not just the wider market. It's vexed because while I
| deeply believe business needs would be better met locally, we
| still want a line of accountability on things like security and
| availability and data integrity that require a bit of longer
| term thought. Feature factory thinking certainly exists in
| bigger centralised teams, the kind that accrete management-
| speak and overbearing agile processes -- but it's also a false
| dichotomy to say "just build with the business and nothing of
| value was lost".
| jansommer wrote:
| As a developer, I've always thought user stories were kind of
| odd: "As a user, i would like to..." But no one writes like that,
| its user story jargon. Like writing tasks have been formalized in
| a way where you put yourself in the shoes of the person affected
| by the change, writing as if you were that person, yet it's (kind
| of) an order. Not very informal the way the article says they
| were meant to be.
| elric wrote:
| The point of using that "formal" jargonized language is that it
| creates a shared context which builds on top of your shared
| understanding of the application being built. Using jargon
| (understood by the whole team) speeds up understanding and
| reduces the need for verbosity.
|
| At least that's the idea.
| hgsgm wrote:
| How does "As a user, i would like to..." help?
| yamtaddle wrote:
| I'm not a fan of rigid adherence to user story format, but
| when they're used well one tends to prefer _personas_ or
| kinds-of-users over "as a user". "As a job seeker, I...",
| "As an employer, I...", "As a moderator, I..."
|
| At their best, they help ensure that when people are adding
| tasks they have a laser-focus on providing value to people
| using the system--they force you to think about _who it 's
| for_ and _why they might want it_ (what problem it 's
| solving). This isn't always reasonable, so you sometimes
| get really stupid user stories at places that insist that
| _all_ tasks be worded that way.
| WorldMaker wrote:
| It tries to put you into the context of thinking _as_ that
| (type of) user (whether or not you prefer roles, titles, or
| "personas" in the "as" clause). If you aren't building a
| feature with some specific type of user in mind, who are
| you building it for?
|
| I think that relates to why I find the "so that" clause
| _far more_ useful than the "I would like to" clause and
| almost find them backwards in the formula, but
| unfortunately, I think they need to be in the order they
| are in to help reasonably write them (in English). It's too
| easy to take user requests at face value feature requests
| and just keep bolting endless features own and maybe not
| ever properly meet the WHY behind the feature requests and
| what the user's actual goals are.
|
| With all the "so that" clauses filled out in user stories
| on a board, an Engineer has a much better chance to see the
| big picture and find ways to solve multiple problems at
| once, sometimes in elegant ways. Rather than just build a
| laundry list of features, that may or may not meet user
| needs, it can help you build a more comprehensive and
| coordinated approach to building the software.
|
| The article points out that engineers often aren't great at
| knowing the WHY behind a user's request and that's often
| correct, but that puts cause-and-effect backwards: an
| Engineer generally shouldn't be writing the "so that"
| clause, they _need_ that clause for better understanding.
| Good "so that" clauses come from actual users or at least
| user advocates (product owners, BAs, support staff, etc).
| They shouldn't be "optional", the WHY is important to an
| engineer. The format was designed so that all of it likely
| should be written by user advocates rather than Engineers.
| It was designed to be quickly _parsed_ by Engineers, not
| built by Engineers.
| yamtaddle wrote:
| > As a developer
| jansommer wrote:
| I thought Hacker News was where I could bring my user story
| jokes :(
| leroman wrote:
| I'm not sure im reading well into your criticism about user
| stories, it sounds like you dislike how they are used in your
| company.
|
| I find user stories critical because they are the lowest common
| denominator for product/sales/dev/biz etc, everyone gets them,
| can agree if this functionality will or will not he in release X
| and pretty much would set expectation correctly between all
| parties.
|
| Additionally, moving down the dev pipeline, once you have
| wireframes / more specific designs, you can go over the user
| stories to make sure they are all supported.
| tqi wrote:
| > 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.
| jeppester wrote:
| I once built a project management system wherein user stories and
| tasks were separate entities with no parent-child relationship.
| If you wanted to connect them you would have to do so through a
| feature (basically a group of user stories and tasks).
|
| The idea was that user stories could be created and grouped into
| features when speccing a project. Then developers could jump in
| afterwards and populate the features with actual tasks. The
| estimation would be done on the tasks rather than the user
| stories.
|
| In the end I didn't really invest the time and ressources to push
| the idea anywhere, but I still think it's an abstraction worth
| investigating. That is if it hasn't already been.
| elric wrote:
| As per usual, whether or not user stories are useful greatly
| depends on circumstances. Having a team( member) that isn't
| receptive to using them will certainly diminish any usefulness.
|
| I imagine they're not super useful if everyone already knows
| what's being built and why. But I have found them useful in
| elaborating context. Why are we building Feature X? Because it
| makes Story Y possible.
|
| Note that user stories _do not_ tell you how to build something
| (not even really what to build), which seem to be a common fear.
| They 're a tool to help you figure out how (and what) to build.
| If you don't need the tool, don't use it.
|
| Also note that there are other people than software engineers who
| are interested in what's being built. The client. Sales. End
| users. Testers. Designers. Technical writers. Etc. All of these
| role are useful in (many) software projects, and it helps if
| they're all on the same page ...
| Merad wrote:
| > User stories as requirements seems to be the dominant
| understanding.
|
| Really? Maybe I'm just lucky but I've not seen it yet in my
| career (10 years). The "as a, I want, so that" text is normally
| just a summary of who/what/why, and the ticket will include
| acceptance criteria detailing the changes to be implemented. For
| features larger than a couple of tickets PO's and PM's will
| usually keep up with requirements in planning docs that are in
| Confluence, Google Docs, etc.
| jdthedisciple wrote:
| Just one of the many aspects of so called "Requirements
| Engineering" (which some unfortunate souls have even somehow
| ended up spending their entire academic career on) which is more
| or less complete utter BS from start to end if I'm allowed to be
| clear.
|
| I have yet to see _a single_ successful software company that
| attributed their success in any significant manner to practicing
| any or all of the mumbo jumbo that is taught in this pseudo-
| discipline.
|
| Reality has taught us over and over again that absolutely
| _nothing_ beats just _doing the damn job_! Certainly not circle
| jerking around the bush with some nonsense User Stories.
|
| /rant
| EddieEngineers wrote:
| Have you ever written software for critical systems, such as
| pacemakers or nuclear power stations? Or a role where software
| integrates with large electrical and mechanical engineering
| teams?
|
| This is fine for _some_ projects but there are other projects
| where "doing the damn job" is a bad idea or even illegal.
|
| Requirements engineering for a startup iterating quickly is
| pointless but for a well-defined critical system makes more
| sense.
| jdthedisciple wrote:
| While I see your point pointing out potential exceptions,
| your examples imo sound _least_ suitable for something like
| "I as user want to sort my notes alphabetically" aka User
| Stories.
|
| Rather, for those critical cases you mention, frameworks like
| the Waterfall- or V-model, in combination with proper
| testing, perhaps seem much more called for to ensure
| compliance, security, and rigidity.
| codyb wrote:
| I as a user would like to maintain a beating heart is a
| pretty compelling story though.
| jdthedisciple wrote:
| Not a very useful thing to write down though, is it?
|
| I mean sure, if there _truly_ was some uncertainty about
| this left.
| EddieEngineers wrote:
| That's fair, I was focused on defending requirements
| engineering in general than _just_ user stories. But yes
| you 'd follow something like the V-model and you'd need
| these requirements, that could resemble something like user
| stories, to fill out a remarkably boring requirements
| traceability matrix on the other side.
|
| If you look at Appendix C of IBMs manual on writing
| requirements in DOORS [0] you'll see they can easily turn
| into something similar to "I as a user...". Not that I
| think that fits everything, nor do I think anyone should
| need to use DOORS lol.
|
| [0] https://www.ibm.com/docs/en/SSYQBZ_9.7.0/com.ibm.doors.
| requi...
| slothtrop wrote:
| You'll admit however that User Stories =/= Requirements
| Engineering, or by extension AGILE/SOLID. Stories may be a
| component of those, but there are alternatives.
| jdlshore wrote:
| "Agile" is not an acronym, FYI. (And SOLID is a
| collection of five object-oriented design principles. Not
| sure why you put them together like that.)
| theteapot wrote:
| > Reality has taught us over and over again that absolutely
| nothing beats just doing the damn job!
|
| I would have thought practical experience of the last 50 years
| has shown "just doing the damn job" is not something that turns
| out well in software.
| jdthedisciple wrote:
| Like anything, it can go wrong due to lack of experience
| and/or competence, or even technical debt.
|
| But it's clear what the real issue is in those cases.
| micromacrofoot wrote:
| It's clear _in hindsight_
| kneebonian wrote:
| I find it interesting how there are entire disciplines now
| built around doing exactly what was outlined in the OSS Simple
| Sabatoge Field Manual
| https://archive.org/details/SimpleSabotageFieldManual/page/n...
| ebiester wrote:
| When I see something like this, I think the appropriate
| response is that with requirements, there is no "best way" for
| every circumstance.
|
| If you have an internal user or small set of internal users,
| you are likely better off spending time with them, building the
| smallest thing that can solve their immediate problem, and keep
| building from there. User stories are great here because your
| requirements gathering is asking the people doing the job.
| Don't design too much up front unless you have a particularly
| hairy business process.
|
| If you are B2C, you have no idea what people will want. you are
| unlikely to get a statistically significant sample. You are
| often looking at the alternatives and building for personas.
| Small work sizes are valuable here.
|
| If you are replatforming or rewriting, you should be getting
| Gap analyses and real requirements because you've had a long
| time to consider the shortcomings. You may build in a way that
| gets feedback, but you already know what to build. Don't bother
| with user stories!
|
| If you are with a mature system, the easy problems are likely
| already solved. You're building larger features that there is
| no easy MVP because if there was a simple way to unlock the
| value, you would have already done it. You should be spending
| more time in unlocking specifications.
|
| If you are a B2B with larger business systems, they probably
| already have smaller ways to do what you are trying to sell
| them, and they're looking to step up. You likely need better
| requirements than a user story. However, you likely have access
| to customers through your customer support teams, so you should
| be taking advantage of asking them and getting feedback. You
| probably need something in the middle.
|
| Use the tool that meets your use case.
| idopmstuff wrote:
| > nothing beats just doing the damn job!
|
| Okay, but you have to define what the job is. That's what user
| stories are for. You don't have to use them (there are many
| other ways of scoping and defining work), but you literally
| can't just do the damn job unless there is a definition of what
| the job is.
|
| > I have yet to see a single successful software company that
| attributed their success in any significant manner to
| practicing any or all of the mumbo jumbo that is taught in this
| pseudo-discipline.
|
| There are lots of multi-billion dollar companies that use user
| stories. I guess they don't attribute their success to it by
| proclaiming that user stories are amazing on earnings calls,
| but if you're suggesting that there are no successful companies
| that use Agile and related methodologies, you're demonstrably
| wrong.
| jdthedisciple wrote:
| I truly would like to see just one successful software
| company that _started out_ by creating User Stories vs just
| simply creating and building their vision.
|
| Sure, plenty started incorporating all sorts of stuff much
| much later on.
|
| I haven't seen it be a _significant initial contributor_ for
| the eventual success. Especially not vs simply doing.
|
| The vision defines what needs to be done better than anything
| else ever could.
|
| That said, some of the companies with the most budget out
| there ( _cough_ something from Redmond _cough_ ) probably use
| these sorts of modern "techniques" all the times yet manage
| to regularly fail utterly when it comes to basic usability of
| their products.
| jofer wrote:
| I have yet to see a single user story that actually gives any
| correct details of what the user wants or is doing, though.
| They're invariably written by product managers who have never
| been in the users shoes and have absolutely zero
| understanding of what the product is or what the users do.
|
| The engineers building a product have typically actually been
| in the users shoes. The product managers almost never have.
|
| When I start seeing user stories that aren't actively
| harmful, I might feel differently. As it is, the first thing
| you should do as an engineer is throw away the user story or
| management's description of the problem and go straight to
| the actual user feedback.
|
| User stories are like watching a fish try to describe a
| bicycle....
| xcv123 wrote:
| > I have yet to see a single user story that actually gives
| any correct details of what the user wants or is doing,
| though
|
| You're working in soft domains.
|
| Typically a business would have very specific hard
| requirements for processing financial transactions and
| related information. If you work in banking or insurance
| the requirements need to be clearly defined by the
| business.
| jofer wrote:
| No. I'm working in very technical domains. Management has
| zero understanding or background in anything. Engineers
| have a minimum of a PhD in the field + at least a decade
| of experience in the field + software engineering
| experience. We've been in our users shoes. Management has
| not and can't even understand the industry.
| xcv123 wrote:
| You will have a different experience in something like
| insurance, where requirements come from external
| integrated systems, third parties, actuaries, government
| regulations, business analysts etc. Not clueless
| managers.
| TheNewsIsHere wrote:
| I feel for the above commenter. I cannot relate to their
| experiences as fulsomely.
|
| Within my past several roles I have always had a really
| good experience with engineering, requirements gathering,
| and how those disciplines are executed by stakeholders,
| including management.
|
| It's fair enough to say that having worked at a
| cryptography company where the CEO was a mathematician is
| probably fairly rare, but I don't think that this being
| an exception is an indictment on the various methods used
| to go from ideation to implementation.
|
| Edit to say: user stories in particular are as good or as
| bad as those involved in creating them are skilled and
| understanding of what is being requested, what is needed,
| etc. In my prior company we had an entire design team who
| took care of the UI/UX, and decoupled that (largely) from
| logic, implementation, platforms etc.
| [deleted]
| xcv123 wrote:
| > I feel for the above commenter. I cannot relate to
| their experiences as fulsomely.
|
| Not as bad as it sounds, when the requirements are
| provided at a high level. In a User Story the
| implementation details and software architecture are left
| to the developer.
| jofer wrote:
| And interestingly, the product managers I've worked with
| who actually do understand the product and the users have
| generally either abhorred user stories or treated them as a
| meaningless checkbox.
| marcosdumay wrote:
| > you have to define what the job is
|
| Technically, you don't. Defining the work and then doing it
| is an overwhelmingly popular preference, but plenty of people
| do different and, AFAIK, it doesn't impact their success
| rate.
|
| > That's what user stories are for
|
| And yes, there are many other ways to do that besides user
| stories. "X was created to solve Y" is not by itself a good
| reason to use X when you need to solve Y. Whether X is any
| good is important too.
|
| In fact, functionality description (the thing that user
| stories was created to fight against) seems to normally lead
| to much better systems than user-story based designs.
|
| > There are lots of multi-billion dollar companies that use
| user stories.
|
| And well, this stopped being relevant when user stories
| became a fad pushed by more than 99% of the managers.
| Supermancho wrote:
| For sake of clarity, "you" here means someone or some
| group.
|
| >> > you have to define what the job is
|
| > Technically, you don't.
|
| Technically, yes, "you" do. Most developers do not solely
| decide what they get paid for. This sentiment is as absurd
| as my example: I'll bring a toilet in tomorrow and call the
| serial processing job done because I delivered (without
| looking at any sort of work definition).
| marcosdumay wrote:
| Oh, your "you" here implies a manager-managed submission
| relation! Yeah, you can't have that without one of the
| parties defining the work.
|
| Again, that is a widely popular way for people to arrange
| themselves, but it's not obligatory. There are many
| people that do not work that way.
| sdeframond wrote:
| > you literally can't just do the damn job unless there is a
| definition of what the job is.
|
| Sometimes the best way of knowing what the job is _is_ to do
| something quick, gather feedback and iterate until it is good
| enough.
|
| In other words, to know what the job is you might actually
| have to do the damn job!
| chasd00 wrote:
| > gather feedback
|
| that list, in narrative form, is a list of user stories.
| Even more so If you talk to users before you start and get
| their input and insight on the most useful thing to build.
| marcosdumay wrote:
| What the GP is describing is absolutely not user stories.
| For a start, if he talked to the users before he started,
| he would get something completely different.
| sergioisidoro wrote:
| This lacks context of organization size. When you're building a
| product from the ground up, user stories are super useful to
| organize and priorize flows and features. They are a super
| lightweight tool to communicate scope and requirements in small
| teams.
|
| In a large organization or product, using user stories might
| devolve into chaos, with people using them way beyond their
| intended and reasonable use.
| psadri wrote:
| I think any software (and possibly product) development process
| where the starting point is a designer creating mocks / flows in
| isolation and then handing them over to others to build is doomed
| to fail.
|
| The initial designs, created in isolation from real data, users,
| what the tech can actually do, etc..., are 99% of the time
| completely wrong.
|
| A better way is to build a minimal working prototype, with
| whatever actual real data you can get your hands on. Put it in
| front of actual users and listen to their feedback. Iterate. Once
| it has settled into its final shape, worry about making it look
| nice.
| JakeAl wrote:
| I disagree. The problem started when people doing the flows and
| storyboards weren't informed or didn't understand the tech
| side. When waterfall was detailed plans written by people in
| the know, it was great, but only as long as the engineers
| (programmers) actually read the design doc. But they stopped
| doing that and insisted on making it up themselves as they went
| instead. Good product developers can establish proper
| blueprints, but a good product developer needs to understand
| both what the user does AND what the programmer does. Then they
| can articulate a vision and proper information architecture and
| functional specifications that make doing the work as simple as
| following a blueprint/design document. Meanwhile, Agile has
| become this bloated mess with dedicated roles for everything
| that a producer or project manager used to do, and the project
| manager has been reduced to someone just tracking progress
| instead of informed architects beholden to programmers who
| refuse to read the well thought out and planned design doc.
|
| Before there was agile, there was managing complex design
| projects by Dubberly.
| https://www.dubberly.com/articles/managing-complex-design-pr...
|
| Such a process made sure all the appropriate questions were
| answered up front most important, what's the actual problem
| you're trying to solve, not what do you THINK the problem is
| you're trying to solve. In part I think programmers wanted to
| be more than just programmers. It's like a construction worker
| deciding the architect doesn't know what they're doing so they
| have to be the ones designing the house as they build it. Which
| may be true if the architect is an artist and not an engineer.
| chasd00 wrote:
| it takes a lot of professionalism to be an expert in a field
| and yield to experts in other fields. I think many software
| devs think they know everything and people are just worn down
| trying to work with them so you get all these different
| methodologies. Look at the disdain found on HN for marketing,
| sales, executives, any part of an organization that is not
| writing code. In reality, writing the code is maybe 20% of
| the overall effort in producing a successful software
| product.
| idopmstuff wrote:
| I feel like people get way too bent out of shape about this kind
| of thing - user stories are just one way to communicate, and you
| definitely don't have to use them. I use user stories, technical
| requirements and visual designs to communicate the needs - which
| of them I go with depends on the particular context of the
| product and team.
|
| If you work at a place that requires strict adherence to user
| stories or whatever other bit of methodology you find repugnant,
| then either try to change the way things are done or quit and
| find a place that suits you better. I get the impression from
| some posts on HN that people are toiling away under Agile regimes
| for years, letting rage build inside them at the indignities of
| having to estimate/write user stories/whatever else.
|
| If you feel that way, consider joining an early stage startup -
| there isn't strict adherence to much of anything, and you can
| have a lot of impact on how things are done. You might take a pay
| cut, but if you hate the day-to-day so much, that's probably
| worth it. If you won't leave somewhere that you hate working
| because they're paying you $500k and you don't want to make less
| money, I don't think you really deserve sympathy anyway.
| mattmanser wrote:
| I don't really see what this adds to the conversation. It
| basically boils down to "stop whining and leave".
|
| If we can't talk about bad practices, we can't fix them.
| IshKebab wrote:
| I hate them just because they put the most useless information at
| the front and they just sound so damn whiney. Have you ever seen
| a list of user storeys? You have to wade your way through "as a
| user I want to" again and again. And it's in the wrong tense too.
| Why not just have a "target user" column and a "feature/task"
| column? Way less obnoxious.
|
| Always reminds me of Bill Bailey's _speaking as a mother_ skit.
| duncan-donuts wrote:
| In my past roles user stories become problematic when you groom
| and break stuff down. One of the things that I think happens too
| often is this desire to get every unit of work down to some
| maximum threshold. In doing so teams start making weird decisions
| on what the boundaries of something should be and they lose all
| context on why they're doing it at all. I think teams should be
| given the space to say a unit of work is large and complex and
| something taking a bit of time to work out is ok.
| karaterobot wrote:
| > Now let me summarize and you can decide if we have the same
| understanding of user stories here: A user story describes a work
| item. It puts extra emphasis on understanding your users and why
| satisfying their needs is valuable to them.
|
| I don't think a user story should describe a work item. A user
| story may entail multiple work items, or a single work item may
| fulfill multiple users stories. A description of a user need is
| what they are.
|
| Their relationship to features is not simple. I agree that most
| of their value is in deciding if you actually built something to
| address all your important user stories, but of course you can
| only really do that by asking users.
|
| They are useful for organizing your thinking about what you need
| to build, though, so I imagine that is how they get conflated
| with work items or features.
|
| I hate personas. At my current company, we have dozens of them,
| and nobody ever uses them or refers to them. A major effort to
| create, and time wasted as far as I'm concerned.
|
| At a previous company, we had zero personas, but we did have a
| list of actual, real people who represented the kinds of users we
| targeted, and we would meet with them to identify new features
| and validate our designs and prototypes. That was approximately
| one million times more effective than a list of made-up personas.
| You cannot hope to capture the complexity of a real person's real
| needs in an artificial persona.
| hgsgm wrote:
| Do any of those non-persona real people you know use Burmese on
| their computer? Are any of them blind?
| chasd00 wrote:
| i've worked with teams that have gone so far in design and even
| implementation without ever even talking to a user. This is b2b
| stuff too where user interviews are the most feasible, the
| actual users are a teams chat/phone call away. I ask teams all
| the time "have you even talked to the poor souls cursed to use
| this thing?" and just get blank stares.
|
| right out of college I worked at a small independent pharmacy
| chain as a software developer doing pretty much whatever i
| wanted (CEO was a good guy and just giving a kid a shot). One
| of the things my direct boss made me do before i started on any
| of my ideas was go work in each of our pharmacies for a day,
| just helping out where i could and observing. I really learned
| the value of understanding the plight of your users and carried
| it throughout my career.
___________________________________________________________________
(page generated 2023-05-19 23:01 UTC)