You don't need user stories
If the solution is handed down to you, don't bother with user stories.
If you already know what you’re going to build then there is no need to create user stories. You’re better off using a traditional Work Breakdown Structure to decompose what you’ve decided to build into small executable tasks. For example, if you already have a visual design and a screen flow defined and your team’s job is to implement it, don’t bother writing stories. It’ll be a waste of time and cause an impedance mismatch where you will be pretending to not know what you already know. It’ll be weird and your team will hate it, and somehow poor agile’s already downtrodden reputation will be sullied further.
The romantic idea behind user stories is that we don’t know exactly what to build, and only know that a user’s problem needs to be solved. This is the Card, i.e., the invitation to a conversation. We then have an open discussion on how to go about solving the user’s problem because we genuinely don’t know the solution. We discuss, debate and figure out what to build. This is the Conversation. Then we document in tests what we agreed upon to build. This is the Confirmation.
If you already have a solution, what point is there to pretend to not know how we’ll solve the problem? There is no need for agile theatre and we can skip to the end and just chunk out the design which we’ve been handed. Someone else has already thought about what the user wanted and is now telling you what to build to solve their problem. If you really want to feel like you’re doing something agilish, then just use Gherkin to define your requirements so the developers are clear on what to build, and will have an easier time thinking about the tests to write.
User stories have been reduced to a tool which help you split firm requirements into smaller chunks. That in itself is still valuable, but we should be clear-eyed when using them that way. The nature of the Card, Conversation and Confirmation changes if that is what we are doing.
The Card can more specifically define the feature we want rather than the user’s goal. Instead of:
As a insurance policy holder, I want to know what policies I have, so that I have a view of my account
we write:
Display a table of active policies on dashboard while showing policy number, effective date, and type (auto, home, etc)
Perfect. We skip the part where we pretend to have to discover how to give the use a view of their policies (is it a table? a list? what fields?). We already know it is so just write it down.
The Conversation changes from solution discovery to implementation-specific details. Since we know how to solve the problem, we discuss how to implement the solution, not what the possible solutions could be. We go straight down to the nitty gritty of implementation details, technical design, and feasibility. We cost out/estimate the feature in the interest of uncovering complexity, rather than to determine if it’s worth implementing. Some trade-offs are discussed but we’re more or less dealing with a fixed-scope situation so mostly hang our heads in despair.
The Confirmation is the part that doesn’t change much - we still have to agree upon what constitutes the completion of the task, and good old fashioned acceptance criteria still help us write tests.
Beyond the three C’s, what changes the most is who writes these stories. In Scrum (or whatever agile variant we’re using now), this was the job of the Product Owner, but why do we need the Product Owner to write down what can be better described in a visual design or Figma? Why not just give the Figma to the developers and let them write the tasks needed to implement it. And do it in Github instead of Jira. There, I’ve just saved you a million dollars.
Now, there are some benefits to using user stories even in these environments but they may not be worth it. The main one is this: at least the user’s perspective is explicitly taken into account (albeit briefly) when writing down the requirement. It’s a token gesture but who knows, maybe it’ll spark something someday in someone’s heart to one day ask: Is this what the customer asked for?
—
Note that I’m not advocating doing things this way. The best products are built through collaboration, not passing down solutions. But if you are in a situation where you are being passed the solution and that’s just the way it is and there’s no motivation to change, seek out efficiency rather than following agile dogma.