Product backlog – an artifact is any man-made object.
The main ones in scrum are considered to be the following:
Artifacts
– Product backlog
– Sprint backlog
– Increment
In this article, let’s take a look at the Product Backlog
Product backlog – a prioritized list of what needs to be done in the product:
- The customer must clearly understand
- Changes
- The higher the priority the more detail
- Everyone can supplement. It is the product owner who assigns the priorities.
In scrum, all requirements, wishes, and ideas are first put into a list called a backlog.
The main unit of planning in scrum is the user story. It is a description, from the user’s point of view, of the feature that this functionality provides.
A good user history should answer the following questions:
1) What kind of product functionality needs to be created as part of this user story?
What actions does the new functionality allow?
2) Who (what type of user) uses this feature?
Who needs it?
For example, the authorization window is used by all users of the system, and the reports functionality is used by the accountant. Understanding the target audience gives additional information to the developer. When he puts himself in the shoes of the user, it is easier for him to understand his needs. Otherwise, developers often implement the functionality in a way that is easier, faster, or more beautiful from a code point of view. And from the point of view of the consumer, it can be inconvenient to use. Besides, if there is a possibility to contact the customer, you can communicate with representatives of this type of user and better understand their needs.
3) What does he do it for?
Understanding the goals saves developers from mistakes in understanding and implementation.
There is a difference in the implementation of the following stories:
(a) An accountant gets a report.
(b) The accountant gets the report to reconcile and present to management.
In the second case, it is clear that in addition to displaying the report on the screen, you need to export it to a file or print it.
To present all this information succinctly, it is common for user stories to use the formula:
<When><role>, it <results/can do>[, to .]
The optional element <when> can describe the situation in which a given action occurs. For example, for a learning management system, you could record such a user story:
When a trainee completes a task, the trainee sends a report to the trainer to confirm that the knowledge has been learned and put into practice.
For brevity, the user story is usually given a title. This makes it easy to identify the story in the backlog. In addition to the name, each user story has a numeric identifier, a priority (importance), and an estimate of the amount of work needed for planning. It is also useful to describe the demonstration steps: how to verify that the story is implemented. This is the basis for future testing. Optionally, additional fields, such as categories, modules, request initiator, etc. can be used for convenience.
How to determine key attributes: importance and evaluation we will discuss in detail in the next sessions.
If an estimate of the amount of work on a story exceeds the length of an iteration, such a story is called an epic. It is broken down into parts – simpler stories.
Thus, the backlog can be hierarchical. In this sense, those who have used classical project management will find it easy to transfer the notion of a hierarchical work structure (WBS) to the backlog. Stories, in turn, can be broken down into tasks, so that multiple people can work on a single story.
The detailing of all user backlog stories usually does not happen immediately. First, the highest-priority user stories at the top of the backlog are worked through and described in detail.
As the priority decreases, a description “in general terms” is allowed. There may be no evaluation. It can save a lot of effort given that the backlog can change all the time. After all, under the agile approach, project requirements can be refined and changed at any time when the market, situation, customer understanding, or simply new ideas change.
Any team member can contribute such ideas to the backlog. But only the product owner decides what will be implemented first, what later, and what will lie at the bottom of the backlog with a low chance of implementation.
In the next article, we’ll talk about how the Sprint Backlog helps visualize the process of working toward short-term goals.
