User stories? thanks but no
beza1e1.tuxen.de
beza1e1.tuxen.de
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.
If we can't talk about bad practices, we can't fix them.
User stories are great, when they make sense and the people reading them and writing them agree on the methodology. Agile is fine for those who like the model but so is (trigger warning: anti patterns being complimented ahead) waterfall. I prefer Kanban but it works well for my team I'm ways agile doesn't. I like it so much, I talk about it. I also like user stories but for a different use case: SLOs. Surprise! I subscribe to the SLOs.
Any of the things I just said could be portrayed as one form of dogma or another. It's only a bad thing when people don't align. When people share or at least agree to a methodology, they're great.
What leads you to believe that just because you disagree with something then it's automatically a dogma and bad? If you're trying to debate the merits of an idea and you start your argument by dismissing and discrediting proponents, regardless of what they might say or how weak your points are, and to make matters worse you admit the proponents of said idea invariably win over your arguments, doesn't that suggest that there's some likelihood you're in the wrong?
If you read the rest of my post, you'll see that "questions as to the goodness of practices, or the lack thereof, are treated as personal attacks". There are other symptoms too, like questions being answered with non-answers.
Again, when someone claims that their way is the true way, and that everyone else _must_ follow the one true way, I believe that the burden of proof lies on them. Your opinions might vary!
I think you missed a branch in your case statement.
GP comment stated:
> either try to change the way things are done or quit and find a place that suits you better.
To my reading, "do this thing about it, or do this other thing about it " doesn't resolve down to "quit whining".
To merely "quit whining" implies sullen, passive, acquiescence.
Whereas the person you replied to framed it as a choice between two paths, neither of which involved passive acceptance.
I see it as adding a solution to a blog post describing the perception of a problem.
Isn't there a catchphrase of sorts that reads something like "either change company culture or change company"? If you can't change the company culture and you feel strongly about that, why do you think it's not in your best interest to change your life for the better? Sometimes you and your job are a bad fit, and there is no way around it.
I think this is either because they believe all companies are like this, or they can't get hired elsewhere.
> If you feel that way, consider joining an early stage startup
This isn't the only option. There are plenty of teams to join tucked away in corners of big companies that have all kinds of different approaches. Or, another option is to just become a manager at a big company, and then you can lead your team towards whatever system you want. You don't have to work at a startup and live in poverty.
In my anecdotal experience, the "Agile regimes" most commonly take root at non-tech-industry companies pretending to be tech companies. A lot of those places treat software engineering like it's factory work.
One tell-tale sign of a horrible place to work is the "scrum masters." That could be another metric to guide the job search, too — if you see a scrum master, just say no.
https://riskfirst.org/misc/Post-Agile
In an industry where it's common for customers POCs to sometimes span 6 months, never mind 6 weeks, we expect product teams to deliver mana from heaven in 6 week sprints.
Big ticket deliverables just don't work that way any more.
We can't go back to pure waterfall. But pure Agile is also a fictitious goal.
Whatever methodologies we use today tend to be different strata all happening at the same time, only at different layers. Some things can be solved in a week or two. Others in a month or two. Or a quarter or two. And some jobs are so big they are literally super-annual deliverables. Each happening in parallel at the same time, but on different tracks or lanes of traffic, fastest to slowest.
What leads you to believe that "pure Agile is also a fictitious goal"? Unless you're using weasel words to refer to Agile in a way you can cherry pick claims to argue that practices that work aren't Agile because they are not "pure", Agile is ubiquitous and is used in countless success stories.
I wouldn't read too much into it. At best the author is just venting steam, and at worst he's complaining about things he doesn't quite understand. The blog post reads like a rant to get things out of the author's chest without much care on coherence or intent to express well founded opinions.
Sometimes stuff that random people say online is just that.
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.
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.
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.
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”.
Modularity requires redundancy, it's inefficiency that buys us resilience. But forcefully erasing emergent social boundaries on one side and forcing overtly complex structures for the sake of some ill define ideal on software architecture (OOP! microservices!) just nets us the worse of both worlds.
- 2 standups (One Slack-based, one Zoom)
- A sprint grooming session
- A project retrospective
- A product planning meeting
- A documentation review meeting
In the 3 or so hours I get to work per day (in like 30-45 minute chunks) are mostly spent dealing with updating Jira or asking product teams on clarification.
It's a total disaster.
But there are more obstacles, like cultural ones: I can't count how many time I heard "client pays, client demands" without want to hear any feedback or guidance.
There are also obstacles on work organization level, for example: people who have final say how should system look/work have no time to even grasp general ideas about the system.
And god forbid if your client has experience with software developers who were silently and blindly (which means: inefficiently) developing everything that client demanded, because it creates a wall that will be very hard to breakthrough.
You're dead on with the business vs software cultural divide. It is both bred by this situation and a moat around it. I am trying to come up with a way to find profit in going against the grain, because I think this is the only way to drive change (or at least preserve my sanity).
I know what you mean, but I think the profit is already there, with some good soft skills you can show your value to the client by doing it the right way. Although it won't be always pleasurable or smooth sail as you need to speak up or tell harsh words to others, but, you know, if there is no tension in bicycle chain it means you are not pedaling. Of course, you need to do it in gentle and respectful manner - that's why soft skills are so important.
Agile concepts are a reaction to authoritarian companies that do "big design up front," where the programmers were supposed to do what they're told, assuming the people who wrote the requirements knew what they were doing. XP was invented by consultants working on a payroll system at a Detroit auto maker. [1]
Often the requirements were bad, resulting in expensive delays or outright project failures. This was meant to be empowering developers in a system where they were at the bottom of the org chart.
If those aren't the kinds of problems you have, maybe user stories aren't the solution?
A related concept is "access to a user representative" where, if you don't understand a requirement or it's ambiguous, you can ask a domain expert what it means. You shouldn't need to call a meeting to do it, either. Originally this meant physical proximity. Unfortunately this gets watered down a lot.
These days we have a lot more communication, often remote. I think there might still be problems getting accurate requirements and with plans changing, though?
[1] https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...
- they are easy to understand as everyone is familiar with concept of telling stories
- they enforce a way of thinking about the feature, e.g.: "when click X, then Y happens", which is easily translatable to workflows
So I wouldn't be so eager to discard them completely - they are very useful tool, although, not the only tool you should use.
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.
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.
Oh yeah, fam.
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.
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.
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
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.
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.
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...
I mean sure, if there truly was some uncertainty about this left.
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.
But it's clear what the real issue is in those cases.
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.
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.
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....
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.
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.
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.
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!
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.
And that "something" you're doing quick is based on...user stories! Unless you're making up something entirely in your head, with the idea that "if we build it they will come," i.e. a solution in search of a problem.
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.
>> > 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).
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.
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.
It seems to be working, if you are one of those people who leave quickly or if you don't care about anything except closed tickets. Even if most of those tickets are bugs, same bugs again and again in cycle.
I think better said: user stories as completion requirements are good.
Can the user do it? Then check that off.
If the PM comes back and doesn't like how they do it, the PM needs to write better user stories.
Full disclosure: I am a PM.
Always reminds me of Bill Bailey's speaking as a mother skit.
> easy-to-fix issue
I see you haven't worked with people! :D
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 ...
Of course "as a $role I want $feature so I can $purpose" is still pretty brief, and I've seen far more detailed templates, but it's good to have something at least.
And yes, these stories don't remove the need for more comprehensive requirements and design. They're good for the additions to that, but shouldn't replace them entirely.
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.
At least that's the idea.
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.
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.
In a large organization or product, using user stories might devolve into chaos, with people using them way beyond their intended and reasonable use.
That way, you don't wind up implementing a data model that doesn't map nicely to a UI.
Look at old KiCad with it's feedforward pipeline approach full of manual "finish and move to the next tool" compared to other apps. Core functionality and user experience aren't always easy to separate. Starting with user stories lets you design the core of the app in a way that won't constrain the UI or require nasty piles of hacks to get 5he results you want.
They also make edge cases more likely to jump out, in a story it's easy to see steps where stuff could go wrong, as opposed to a requirement that isn't like a story, which might be described in a more isolated way and not connected to other features, and not reveal the issues you might have at the interfaces.
A tenet of agile development is to quickly get functionality into the hands of the customer or product owner, so they can provide feedback and get a better understanding of what they want. The user story describes a unit of functionality with can be presented for the product owner. It is described in terms of what the user experience (rather than underlying implementation) because this is what the product owner will evaluate.
The article gets lost in definitions and classifications, which is the opposite of agile - that is, the agile which value people over process, not the Big Process agile.
User stories are not requirements, because you don't know the requirements before the software is finished, at which point formal requirements are rather useless anyway.
It's spelled out in the name of the manifesto. How much more clearer can it be made? The thing is not even two pages long, and yet there are probably less people who read it than there are certified practitioners of this or that process supposedly bringing it to you - where the situation is now about arguing whether some random artifact best conveys a backlog item (won't even get there, you already lost) or requirements (face to face conversation much?).
Lost cause.
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.
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.
My point is that iterative design processes tend to work better than waterfall (for new software projects).
Architect / construction worker - sure. It is hard to iterate on a building - it has to be more less built as designed and therefore there is a huge onus on the architect to get it right the first time. Software is more malleable, at least at the start.
Not really worth a read unless you like to hear people rant, when its clear they are missing the whole point and have misunderstood fundamentals.