Why writing user stories is a waste of time

We recently received a clear reminder why writing user stories without understanding the underlying business processes is simply a waste of time.

The Open Commerce team was brought in for a project that included automating payments for vendor purchase orders. The financial department submitted a change request to stop automatic payments and add a “manual payment” button to their payment list. This request followed a serious incident where a payment intended for one supplier was inexplicably sent to another.

The financial team's reasoning seemed logical: they wanted to manually check each payment before sending it to the bank to prevent further errors. The product owner immediately started writing a user story: “As an administrative assistant, I want to manually approve purchase order payments to prevent incorrect payments.” It included everything—wireframes, acceptance criteria—the full package.

But here's the thing: if we had developed this feature, it would miss its purpose.

In a follow-up meeting, we involved the colleague from the financial department who submitted the request and began exploring the actual payment validation process. It quickly became clear that manually approving each payment was not the easy task it seemed. The finance team described the complexity of their process—verifying that company names and bank details match, cross-comparing data with the bank, and making sure payments go to the right provider. If we had implemented the “manual pay” button, it would have overwhelmed the team, with an unnecessary workload.

This is where understanding the complete process is crucial. I'm convinced this sounds familiar to many; situations where a feature request is made—just for a quick fix that further complicates things.

Instead of continuing with the user story as it was written, we took a different approach:

1. We organized a short workshop with the financial team, product owner, and solutions architect to create a detailed diagram of their payment process.
2. We worked with the development team to identify all data points involved in the validation process.
3. We assessed which parts of the process could be automated within the existing automated payment order, instead of stopping it altogether.
4. For controls that still required manual input, we designed an addition to the payment task list that presents all available data to the user so that they can make informed decisions efficiently.

The lesson here? Collaboration is key. By involving the Subject Matter Experts (SMEs) and carefully mapping the process, we can design solutions that actually add value. At Open Commerce, we strongly advocate for this—working closely with internal teams to identify, analyze, and address the real challenges behind the requests.

Before you jump into development, make sure the story addresses the root of the problem, not just the symptom.

‍