The stories backlog is a list of requirements detailing the functionality of an application. Creating and maintaining the stories backlog is one of the most important tasks that a team does throughout the software lifecycle.
It provides everyone involved in the project with a list of what is required, how important each requirement is, what users are involved in it, and what platform it belongs on.
The backlog is the basis for how the project is estimated and the roadmap constructed. It is broken down into epics and user stories. The epics are large groupings of functionality, while the stories are the small individual tasks the user performs on the product.
Before you start
This is one of the most important migration kit activities as it sets the stage for success. This activity is traditionally performed by a business analyst. Find as many domain experts on the legacy system as possible and any documentation that might give clues to the intention of the application. If the domain expert cannot be found, then someone must become the domain expert. This can be very much a computer forensics activity, so get your detective hat on.
Details
Level of difficulty
Moderate
Stage
Understand
Suggested time
Varies depending on the project, ideally less than the maximum iteration length (typically 2 weeks).
Participants
- Business analyst
- Squad lead
Materials
- The Codebots Platform
- Issue tracking software, such as Jira (optional)
Steps
- Decide on the location where the backlog of requirements will be kept. The backlog should become the single source of truth for the requirements of the application. For some organisations, they may already have a policy on this like inside Jira.
- Create a new project in Codebots and fill out the basics of the product, or select a previously migrated project.
- Gather all your research and idea development along with assumptions, and begin turning them into epics. These epics shouldn’t be too general, and large features should be broken down further. An epic is a description of a coarse-grained requirement in a story form. It may represent a theme, which can be used to categorise a bunch of related user stories. Epics are created and maintained within the Codebots project.
An epic may look something like: As a [type of user] I want to [do some action] so that [reason for action] - Once you have the epics in place, start breaking them down into the stories. A user story is a description of a fine-grained requirement. Each user story belongs to exactly one epic and describes part of the epic in more detail. A user story is the unit of delivery for iterations, so by definition it must be sufficiently small to deliver in a single iteration.
A user story may look something like: As a [type of user] like [persona] at [environment]. I want to [do something] using [device] so that [reason for task]. This will [user goal]. - Before the project can proceed to development, the stories backlog needs to be finalised and all information added. The more the better, as it keeps accountability of the project moving ahead.
Justification
A great business analyst combines both the art and science of understanding a domain. In the academic world this is sometimes referred to as requirements elicitation, and in the agile world as requirements gathering. This is a very widely discussed and written about topic.
Without over-simplifying this field, there are a few main points we would like to address. First and foremost, keep it simple. It is easy to get carried away with the complexity of requirements gathering and try to do too much too early. Modern business analysts are embracing the ethos of methodologies such as Lean thinking, where the MVP that is the first milestone to be achieved. That is a good way to think about it, however it needs to be applied in the context of legacy systems i.e., what is the minimum set of requirements needed to satisfy the user stories for the people using the legacy system. By setting the priorities of the user stories (requirements) and engaging with the people on the project early, you can carve out the MVP of the legacy migration project. A few scenarios on how to deal with legacy systems are covered in the Bots That Code book, such as the firecracker and the divide-and-conquer migration patterns. Both of these should fire up your imagination on how to tackle the legacy system.
It is also worth revisiting some of the tactics laid out in Chapter 3 of Bots That Code, especially the use of models. The insanity of legacy systems is that the cycle keeps repeating itself. When we rewrite an application or deploy a new off-the-shelf application, we expect a different result but we are simply creating the legacy system of tomorrow and the cycle repeats. However, if we are able to make the requirements (the knowledge) of the application as important as the application itself, the next time we need to change the application to better fit the people using it, we are already on the front foot because the whole idea of reverse engineering the requirements is a mute point. You will already have them.
Written by Tessa Mylonas
Head of Support and Education
If Tessa isn’t busy answering support questions or educating you about the Codebots products, she is typically found putting together flat-pack furniture, playing with her chocolate Labradors or hoarding houseplants.
