The new sprint begins, and with it comes a fresh wave of tickets, some straightforward, some ominously vague. The air outside is crisp, the kind that hints at the turning of seasons, but inside, the glow of your monitor casts a familiar warmth. You take a sip of coffee, still hot, the first of many.
You lean forward, scanning the sprint board. Your eyes flit past bug fixes and minor tweaks before landing on something more substantial: "Add support for multiple users per account." A proper challenge. Finally!
You feel that familiar mix of excitement and cautious optimism. This could be a clean implementation, or it could unravel into a tangled mess of edge cases and unexpected dependencies.
Either way, it’s yours now. You assign yourself to the ticket, crack your knuckles, and get to work.
Nothing.
No acceptance criteria.
No considerations.
No technical solution.
Just a title floating in an empty void.
And yet, somehow, it has been assigned five story points.
Maybe there's an old confluence page buried somewhere, or perhaps someone, somewhere, has context?
One thing’s for sure, you’re about to go on a…
Scavenger Hunt
Ok so where do you start? You contact the stakeholder / account manager, maybe you arrange a call, but what do you ask?
"Add support for multiple users per account."
Sounds simple enough, right? But then, is it? Let’s explore this further
User Management
How do users get assigned to an account?
Can they be invited, or must they be added manually?
If invited, how do they accept? Email? Magic link? In-app notification?
Can users belong to multiple accounts?
If yes, can they have different roles per account?
Permissions & Roles
What permissions do users have within an account?
Are there different roles (e.g., admin, member, viewer)?
Can permissions be customised per user, or is it role-based?
Who decides a user’s role?
Limits & Constraints
Is there a maximum number of users per account?
If so, what happens when the limit is reached?
Are there tiered limits for different subscription plans?
User Actions
Can users remove themselves from an account?
Can an admin remove a user? What happens to their data?
Can users switch between accounts easily, or is it a separate login per account?
Account Deletion & Data Handling
What happens if an account is deleted?
Do all users get removed automatically?
If a user was part of multiple accounts, does it affect them?
Is there a soft delete or a grace period for restoration?
Edge Cases & Weird Scenarios
What happens if a user is removed while actively using the account?
Can a user be re-added after removal, and do they retain previous permissions?
If a company has multiple accounts, can they merge them?
If a user is on a paid account and moves to a free-tier one, do their permissions change?
Silence. No one has a clue.
Yep. This ticket isn’t getting done anytime soon.
But what’s the alternative?
Err.. yeah just crack on, mate…
Sometimes, you’re told to get on with it and that you’re free to make assumptions, the client just needs to see something, but there’s a slim-to-zero chance of it mirroring what the client is imagining in their head.
Two weeks later, the work comes back (shocker!).
The client sees the final product, and it's not what they expected. They’re frustrated. The budget is stretched. The deadline isn’t going to be hit now.
The thing is… you did exactly what was asked (even if it was a little vague), and yet… here you are, standing with your dick in your hands (I’m assuming you have a dick by the way, but see how assumptions work?).
The stakeholder finally has answers, and surprise! Half of what you built doesn’t match what they actually need. Maybe users were never supposed to belong to multiple accounts. Maybe permissions were an afterthought, until they weren’t.
Now, you're stuck rewriting chunks of logic, refactoring migrations, and untangling relationships that never should have existed in the first place.
Poorly specced tickets don’t just waste time, they erode trust at every level. Developers lose faith in the process when their work is constantly reworked, rewritten, or outright scrapped.
Product managers grow frustrated as deadlines slip and budgets stretch. Clients start questioning whether the team truly understands their needs.
A better way?
The right way? You get in a room with the stakeholder and flesh it out properly at the start!
No vague Jira ticket, no game of telephone through layers of people who don’t fully understand the problem, just real conversations.
Modern agile? It’s barely agile anymore. It’s a ritualistic cargo cult of backlog grooming, point estimation, and sprint velocity metrics that measure movement, not progress.
The buzzwords are there: sprints, scrum, stand-ups, backlogs, but behind the facade is a world of micromanagement, rushed deadlines, and ill-defined tickets.
We claim to be agile, but instead of real collaboration, we’re handed half-baked tickets with no context and expected to "figure it out." To do this right, you need to cut through the noise.
The sales guy who overpromised?
The account manager who barely knows how to spell their own name?
The tech lead who keeps getting dragged into meetings?
Their "specifications" aren’t enough.
To be a great Software Engineer, you have to engage with people—it’s a crucial part of the job. Software engineering isn’t just about writing code; it’s about solving problems. So, how do you do that effectively?
Sit down with the stakeholder. Ask questions. Challenge assumptions.
Prototype screens. Show them what they think they want and uncover what they actually need.
Discuss trade-offs and limitations. Does this feature scale? How will it impact existing users? What’s the simplest solution that works?
Manage expectations. Set realistic timelines. Push back on bad ideas before they become bad implementations.
You’re battling against how modern-day agile companies misinterpret agile.
The Grumpy Dev is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
Bottom line… You need the information firsthand—straight from the person who actually cares about the outcome. That’s it.