Writing user stories was taking up too much of our Business Analysts’ time. Even after understanding the business need and gathering the right context, there was still a significant amount of manual work involved in turning that information into user stories and acceptance criteria.
But time was not the only challenge. The level of detail often relied on the experience of the person writing them, creating inconsistencies, ambiguity and, eventually, more questions and rework for development and quality assurance (QA).
That was the problem that led us to build StoryWeaver.
We started with a simple question: could Generative AI help us turn business context we already understood into clearer, more consistent user stories, without removing human judgement from the process?
That question became our first Proof of Concept.
The problem was bigger than the time spent writing user stories
There is a part of Business Analysis that I do not believe technology should replace: understanding the problem.
A Business Analyst still needs to talk to stakeholders, understand how people work, identify pain points, challenge assumptions and clarify what the business is actually trying to achieve. That context cannot simply be delegated to a model.
But once that work had been done, we were spending too much time manually converting the information into a consistent structure that developpers and QAs could use.
This distinction became important when we started exploring AI-based user story generation. We were not trying to ask AI what the business needed. We wanted it to help us express what we already understood in a clearer, more structured and repeatable way.
The challenge is that maintaining this level of quality consistently across teams requires time, discipline and experience, and when the quality of the initial requirement varies, the impact tends to be felt further down the delivery process.
Starting with a Proof of Concept (PoC)
Our first version of StoryWeaver was deliberately small. We built a Proof of Concept to answer that practical question: could Generative AI take the context already gathered by a Business Analyst and create a useful first version of a user story?
The output followed a defined structure, including the title, preconditions, description and acceptance criteria. For acceptance criteria, we adopted a Given, When, Then structure that could be easily understood by Business Analysists (BA), developperst and QAs.
The goal was never to generate something and send it directly into development. StoryWeaver creates the starting point, the BA reviews it, challenges it, adds missing context and validates whether it accurately represents the business need.
What changed was the amount of effort required to get to that first structured version. Instead of beginning with a blank page every time, teams could begin with an organized foundation and spend more of their time improving the requirement rather than formatting it.
From a useful PoC to a reusable solution
A PoC becomes interesting when it works once. It becomes truly valuable when it continues to create value beyond the specific scenario for which it was originally built. That was the next step for StoryWeaver.
As we used it internally, the value became visible not only in productivity but also in consistency. Xpand IT’s own measurements showed a reduction of around 40%in the time BAs spent writing user stories. However, the qualitative impact was just as important.
A common structure meant that the quality of a user story was less dependent on the individual writing style of each BA. At the same time, development teams received more predictable requirements and QA teams had clearer acceptance criteria to work with. Everyone could start from a more consistent understanding of what needed to be built.
This matters even more as AI accelerates other parts of the software development lifecycle. Generating code faster does not help if the requirement behind that code is ambiguous. In fact, the faster execution becomes, the more important clarity at the beginning becomes.
UNICRE was the real world test
We soon realized that the problem we had identified internally was not specific to Xpand IT. UNICRE was facing many of the same challenges: the manual effort involved in creating user stories, inconsistent levels of detail, ambiguity between business and technology, and the rework that followed Because Xpand IT already had a strong relationship with UNICRE and understood its delivery reality, we were able to move from internal experimentation to applying StoryWeaver in a real client context.
This was an important step in the evolution of the solution. StoryWeaver now had to adapt to different processes, teams and priorities, which helped us understand where the initial approach worked and where greater flexibility was needed. Involving the relevant stakeholders throughout the process also ensured that the solution remained aligned with the way teams actually worked.
The experience reinforced an important principle behind StoryWeaver: AI should reduce repetitive execution without removing human judgement. By taking some of the manual effort out of requirements creation, teams can spend more time on what requires human expertise: challenging assumptions, analysing dependencies, anticipating risks and validating what ultimately moves into development.
What makes AI user story generation useful in practice?
This is also where I believe there is an important distinction between using a general purpose AI tool and introducing AI into a delivery process.
For organizations evaluating this type of solution, I would look for four things:
- A structured output, not simply generated text. The result should follow a format that BBAs, developpers and QAs can actually use.
- Human validation by design. AI should accelerate the work, not remove responsibility or critical thinking from the process.
- Integration with the existing way of working. The real value appears when the output can continue through the delivery lifecycle rather than becoming another isolated document.
- A feedback loop based on real use. Requirements practices differ between organizations, so the solution has to evolve through the contexts in which it is applied.
These principles are what moved StoryWeaver beyond the initial experiment. The technology matters, but the process around the technology is what makes it useful.
StoryWeaver is a visual tool that supports Business Analysts throughout the user story lifecycle, from understanding and adding context to generation, human review, development and refinement. The goal is simple: reduce manual effort, increase consistency and minimize rework, while keeping people responsible for the decisions that matter.
The lesson behind StoryWeaver
The most important thing we learned from StoryWeaver is not that AI can write user stories. It can. The real opportunity is to identify the parts of a process where people are spending time on repetitive execution rather than on the thinking that creates value.
For BAs, that means spending less time translating the same information into a predefined format and more time challenging requirements, analyzing dependencies, identifying risks and ensuring that what reaches development is actually what the business needs.
For developpers and QAs, it means starting with better context. And, for the organization, it means reducing the distance between an idea and a shared understanding of what needs to be built.
StoryWeaver began because we wanted to solve a problem we experienced ourselves. Turning that internal pain point into something useful for our clients was not a separate innovation exercise. It was the consequence of applying technology to a problem we already understood well.
And that is perhaps the most important lesson. The strongest AI use cases often do not start with the technology. They start with a problem worth solving.
