How to write user stories retrospectively – business analyst’s guide

I came to Craftware from outside of the IT industry. I got an internship at the Craftware Academy, and here I took my first steps in the business-systems analysis. In a short time, I gained vast knowledge and got to know the tools of a business analyst. I studied under the supervision of mentors who supported academics in the realization of the internship. This project was similar to those that we implement for customers at Craftware and thanks to this, I got familiar with the reality of everyday work.

Even though I had solid, practical knowledge of the basics, the first “real” project I was assigned after finishing the academy proved to be a challenge. Luckily, it soon became clear that we could count on help from more experienced colleagues, not only during the academy but also on a daily basis. Our team leaders are always willing to share their knowledge with us.

I joined the team in the middle of the project. My main task was to create user stories. This is a common technique used in business analysis, especially in agile projects. It involves collecting user requirements in so-called sprints and delivering them in the form of user stories. They are supplemented by acceptance criteria for subsequent elements of the application that is being created for the customer. In this way, we help developers build the solution, and testers can verify its correctness. The stories may also introduce new team members to the objectives of the ongoing project.

User stories – how to write them correctly and keep thinking outside the box?

Unfortunately, a business analyst cannot always prepare stories according to a specific pattern.

This was the case in my project. The team had gathered the requirements before I joined it, and then we encountered problems verifying the process of the requirements overlap (or, in other words, whether the project elements delivered by the developers are consistent with the users’ expectations). Moreover, the scope of the project expanded unexpectedly and posed the risk of misunderstandings and delays. In such critical situations, a business analyst becomes involved in an ongoing project – this is how I join it.

In this article, I am not focusing on how to build a proper user story. There are many online tutorials and guidelines that handle this topic. Instead, I am going to describe how to gather information and prepare a business analysis on the basis of the existing results of the project and the requirements that have already been collected.

I have been in a situation like this several times, which has enabled me to develop my own procedures and best practices. They are based on my own experience, as well as the substantive guidance of my team leader. Now I know how to ensure the best quality of analysis and user stories as a form of documentation. Here is my step-by-step guide to the retrospective analysis.

Careful preparation for the meetings is crucial. This is the time to organize the material you have collected and structure what has already been written down. You need to make a list of questions, prepare online collaboration boards and check if they can be shared.

During discussions with the business, you should specify the main goal of the production phase and the scope of the project, which should be acceptable for everyone and bring business value to the end-users. It is also a good idea to create a high-level sketch of the process and decision flow for the solution during meetings.

In turn, while interviewing team members, confirm what has already been done and outline the scope of the remaining tasks. Also, determine where the list of these remaining tasks (backlog) is stored. Finally, define criteria that allow assessment of the developed functionalities against the requirements of the business.

Interviews should be held periodically – one meeting is not enough. I recommend asking team members to include you in every business meeting, even if your role is limited to being present and listening. Your observations can help you deliver better analysis results.

Grouping requirements

Now you are ready to start creating user stories. It is a good idea to put requirements and features into groups, for example, user interface, data flow, permissions, security, and so on. This will help you build epics and assign user stories to them.

Another idea is to assign each requirement to tasks in an outlined process. You can match multiple requirements to a single task, for example:

TASK:

• User logging into the system

REQUIREMENTS:

• login requires company email,
• notification of incorrect password or login,
• possibility to log in through SSO.

User stories

Great! Now you can focus on creating user stories and acceptance criteria. Keep in mind that if some requirements have already been fulfilled by the existing elements of the application, you still need to include them in the user stories. This is a form of documentation for the entire project, not just the part from which the analyst joined the project team.

Confirmation of user stories with team members and business

The user stories have been collected. Now, you need to confirm if they are complete and have the acceptance criteria necessary to determine that a given requirement has been met. This is a key part, not only for the developers but also for the testers who write tests for the solution.

This is an overall view of the way I work when I join ongoing projects. In this article, I have presented my approach to gathering requirements retrospectively. With a fresh perspective on analysis, I have developed my own procedures, and my engagement as a junior analyst in several different projects proves that they are effective. I adapt my methods each time, and thanks to my experience gained from subsequent projects, the effects of my work are better and better.