How to Ensure a Quality Backlog
What is a quality backlog for us? By the word backlog we mean a list of tasks, in particular user stories, that the development team must implement within a certain time frame. As a rule, they appear as a result of the decomposition of functionality.
As for quality, its main criterion here will be the result of completing these tasks. In other words, if we can predict the timing and results of completing the functionality being developed with sufficient accuracy, taking into account risks and priorities, then the backlog can be called high-quality. Let's talk about it. Stay in touch Vladislav Filimonovanalytical engineer at KOMPAS-3D.
In short, for a high-quality backlog it is necessary that:
The analyst knew what he wanted from the team.
The team understood what the analyst wanted from them.
Agreements between the analyst and the team were recorded in a convenient form and updated in a timely manner.
The tasks were prioritized (there was a plan B).
Interconnections and risks were taken into account.
The results of the work could be predicted and controlled
We'll talk about each of these points in a little more detail, but first, a few words about our development process.
The development process of KOMPAS-3D
We work according to the flexible Agile methodology using Scrum. Our development is carried out in iterations lasting 3 weeks. The iterations are combined into technical releases lasting 4 iterations each. As a rule, it takes us several such technical releases (usually 3-4) to release a full version of the product. We devote the first iteration of each technical release entirely to planning. During this iteration, the main discussions of future functionality are held between analysts and development teams, prototypes are made, decomposition into user stories occurs, and, in fact, the backlog is filled. Prototyping allows us to check the readiness of third-party modules, for example, the C3D mathematical core, to determine additional dependencies and better estimate the labor intensity. Therefore, this stage greatly affects the quality of the backlog, and it is during the planning iteration that we work out most of the requirements.
Fire ladder, Fire Systems LLC (Tver)
Requirements decomposition
As we have already defined, one of the criteria for the quality of requirements is the predictability of their implementation. Therefore, all our development entities must have real deadlines.
The functionality (feature) itself should fit into one technical release in terms of implementation time, and each of its components (user stories) should not exceed one development iteration. Thus, with each iteration we get some increase in user functionality, which is coded, tested and can be assessed in terms of the expected result. If at the decomposition stage we understand that the size of a feature or some story does not correspond to the standard implementation time, this serves as a reason to revise the decomposition. Part of the functionality can be allocated to a separate feature, and the story is divided into several.
If we talk about the approach to decomposition, we use vertical partitioning. Therefore, as a rule, one of the first stories is almost always the creation of a minimally working team. The remaining stories, one might say, add new capabilities to the team and ensure the interaction of its result with other parts of the system.
User stories
A user story is a form of presentation of requirements by an analyst for transfer to developers. And since stories are the main components of the backlog, to some extent the quality depends on them. Therefore, we try to make them like this:
Uniformly, according to a single template, where solutions are recorded, mockups are presented and acceptance criteria are written, the fulfillment of which is a mandatory condition for completing work on this task. Sometimes the acceptance criterion may be the execution of a certain previously known scenario on an existing model. We put such scenarios in a special section “Test scenarios”. Their fulfillment is also mandatory for closing the story.
All stories have a single storage location. We have a special section in the data storage system, structured by components and smaller parts of the product. It is important that the requirements are not duplicated, otherwise there is a risk of getting contradictions when updating them. However, for convenience, we use a plugin that allows you to link a page from the wiki system to a task in the task management system and display the requirements there.
The size of a user story should be small. Despite the fact that there can be many acceptance criteria and the list of requirements should be quite complete, we try not to make stories large. Since the more requirements, the more difficult it is to control the result of their implementation and there is a risk of missing some of the requirements.
Decisions made on issues that arise during development are recorded in the acceptance criteria for the story being developed.
An additional tool to ensure the completeness of requirements and not to forget anything are checklists. As a rule, we create them for stories that are often repeated in different features. For example, if you look at the processes of setting parameters when running various commands in KOMPAS, you can find a lot in common: controls, prompts, displaying the result in the work area, using dimensions, characteristic points, etc. In the checklist for describing the process, we have more than 80 checks (analytical questions) that you can run through to not forget anything.
Our checklists were compiled in collaboration with testers, including taking into account the questions that most frequently arose during development, and requirements that were missed only when summing up the implementation. Thus, they contain an excessive number of checks, due to which they are quite universal.
Planning stories with risk in mind
No matter how beautifully they write in various articles about the fact that stories should be independent, in practice this seems unrealizable. At least, it always turns out that we have one or several fundamental stories, without which further development is impossible. Although in the future, stories on increasing the functionality within one feature may well be independent.
In general, when development is possible within a single team, it is quite easy to plan everything. As a rule, this happens when the implementation affects only the functional part of KOMPAS, i.e. no modifications are required on the C3D core side and no new capabilities from the system interface. However, this is not always the case, and from time to time it is necessary to plan the implementation in several teams at once. In this case, in addition to the time required for implementation, it is worth considering the time for transferring the results of work from one team to another, and the risk of blocking errors, which may require modifications from co-executors and block the work of the second. To minimize such situations, we try to transfer between teams only fully completed tasks, i.e. those where both the coding and testing stages are completed. This takes a sufficient amount of time, and, as a result, the implementation of related tasks within one iteration is always a risk. When planning work in different teams in one iteration, there is a chance that the second team will not receive changes from the first. If possible, related tasks should be in the next iterations, but not in one. This will allow us to know the state of the first team’s work results at the start of the second iteration, and, if necessary, to make timely adjustments to the plan.
Prioritizing User Stories
Another risk management tool is requirement prioritization. It is used to create some error in the expected result. There is a well-known MoSCow approach, in which all requirements are divided into 4 levels of importance, but our habit has become to divide them into 2-3 levels depending on the size of the functionality and, in fact, the number of stories. We divide them into mandatory, important and desirable.
Mandatory – those that ensure the execution of the main user scenario.
Important ones are those that greatly affect the functionality and ease of interaction with the new functionality.
Desirables are those that add additional functionality or slightly improve the interaction process. It is acceptable that stories of this priority can be sacrificed if problems arise in development.
The selected priority also affects the iteration in which the task will be completed: the higher it is, the earlier the task should be completed. In addition to the importance for the user, the priority of stories can also be affected by dependencies between teams: if a story has dependents, then its priority is higher and it should be completed earlier.
Changes in requirements
One of the always relevant issues in ensuring the quality of the backlog is changing requirements. No matter how hard we try to avoid it, in practice it is almost impossible. Requirements always evolve, change, and sometimes are completely deleted. As I wrote earlier, most of them are formed at the prototyping stage, i.e. by the time we just start technical development (development of the prototype), there may not be any detailed requirements. By this time, there is usually only a development of the Technical Proposal, from which you can understand the main set of work scenarios required by users, and hypotheses on how this can be implemented in KOMPAS. After the prototype is implemented, the main implementation option is determined, and in accordance with it, a lot of specifics appear in the requirements.
Although we try to work out user stories in sufficient detail, during development we often need to adjust something. The most common reasons for changes are:
Found an unintended use case during testing.
Found technical limitations in the code.
A proposal came from users.
New ideas for improvement came after implementing some of the functionality and analytically evaluating the result.
When situations arise where there is a desire or need to change requirements, we try to do the following:
Assess the necessity of these changes (possibly the changes may lead to regression or unexpected behavior in other operating scenarios)
If changes are definitely needed, estimate the scope.
Record changes and make adjustments to the development process:
Sometimes changes concern one condition in the code and their labor intensity is minimal. In such cases, the requirement simply needs to be added to the acceptance criteria of the user story, within which the change will be implemented and tested.
If the change is large (cannot be implemented within the current iteration) and requires serious revision. It should be allocated to a separate user story or technical task. Then prioritize it relative to other work, taking into account dependencies and user value. In accordance with the priority, you can review the plans for the next iterations, sometimes displacing work of lower priority. If there are many new requirements, but from the user's point of view they are a logically separable revision of functionality, they can be taken out into a separate feature.
In rare cases, it may be that the required changes contradict most of the previously completed work on the functionality. In this case, the work on the functionality may be stopped and the further plan revised. As a rule, a quick resumption of work on the same topic is impossible, since it requires reworking a large number of requirements.
It is important that the requirements resulting from development are up-to-date and correspond to what was implemented in the product.
Monitoring progress and results
The decision on the functionality's readiness (completion of work on the feature) is usually made by the analyst who leads it. And since there can be quite a lot of work being done in parallel, to track the results and make timely decisions we use:
Pages for tracking work, this can be either a separately created page where information is loaded through plugins, or an analytics page in the task management system, where all the features that the analyst manages are displayed, and for each of them a list of stories and tasks included in it with current statuses, development team and iteration numbers where they should be performed.
For each functionality, we create a separate chat in the working messenger so that any of the development participants can immediately ask questions or initiate a discussion as soon as they have them.
Depending on the number of teams developing the functionality, the analyst may also participate in daily standups with the team, or weekly component meetings with team leaders working on the same areas of product development.
And of course, we, analysts, visually evaluate and functionally test on work tasks what is obtained directly in the product.
In general, in addition to all the tools, do not forget the most important thing, that for the predicted and expected result you should not neglect personal communication with the developers, this allows you not only to better immerse yourself in the context of the work being done, but also to learn about the implementation features and technical nuances of the system.
I wish everyone responsive colleagues, interesting tasks and, of course, a high-quality backlog!
