Product backlog
| Product backlog |
|---|
| See also |
Product backlog - a concept related to the scrum method. This is a prioritized list of all tasks that should be done to get the product. In a literal translation, this is a product register. This register begins the entire scrum cycle. This is the only source of requirements for any changes that need to be made to the product. It is the basis of customer requirements for the final shape of the expected product.
The main person responsible for the backlog of the product is Product owner. This scope includes the content of the backlog, its availability and ordering. It mainly consists of features, requirements, proposed improvements that should be introduced in future releases of the product. In addition, the backlog contains the so-called attributes of description, order, respect and value. The backlog elements often contain test descriptions that confirm its completeness after completing the task. The product's backlog grows larger when the product is used and begins to gain value, and product users provide feedback.
Product backlog lifecycle
Product backlog lifecycle:
- The product owner presents requirements regarding the final shape of the product.
- Prioritization of tasks in the backlog.
- The backlog is presented at the sprint planning meeting.
- The backlog tasks are accepted for execution.
- Tasks performed are removed from the backlog of the product.
- Starting the cycle from scratch, i.e. returning to step 1.
Backlog characteristics
The product's backlog is most often available in paper form on the board, which is close to the work of the scrum team. It is important that each member of the team has easy access to the backlog. Constant monitoring of the backlog makes it easier to manage individual elements over time. The product's backlog is never completely complete. It has a dynamic character, it can be modified as the final functionality, usefulness, purpose and competitiveness of the product changes.
Due to the fact that new requirements may still appear, the backlog of the product is a living artifact. Changes in business requirements, business conditions or technology can cause changes in the backlog. Tasks located in the upper part of the backlog are most often more detailed, but also simpler. The lower part of the backlog contains much less detail.
The customer who is the main supplier of product requirements participates in team meetings at the end of each sprint. Importantly, the client actually becomes a member of the team. This situation requires a lot of openness from the team. This is difficult because in the traditional management of projects, the client usually receives the results of work, but does not actively participate with the team in planning the nearest tasks. However, this form of cooperation means that it is not required to create documentation for the client, because he himself is a participant in the team and he learns from conversations. It should be noted that the creation of documentation results from the lack of sufficient communication.
The goal of efficient communication has been introduced in Agile. user stories. They have their application during team meetings. Story is a unit of functionality in Extreme Progamming projects. We show the form of work by providing a tested and integrated code that makes up the implementation of a given story. The story should be understandable and valuable to clients, testable by programmers and small enough for developers to implement six stories for one iteration. These stories take the form of flashcards that contain a description of the functionality expected by the client or system user. They consist of short sentences that set goals for the near future.
Time
The backlog should contain tasks for the next two to four sprints. It is worth mentioning that according to the sprint, it should not last longer than 30 calendar days. Make sure that at least half of the tasks are determined by the entire team. However, the rest of the tasks can be determined in small parts. This allows team members to clearly look at the near future, which has been largely planned. The presented scheme of actions allows to avoid excessive pressure on changes of the software development strategy during subsequent sprints.
The development team is responsible for all time estimates. The product owner can influence the development team by helping them to better understand the process and achieve a compromise, but the team members who will perform the tasks make decisions about the final estimates.
Backlog priority
The backlog selects tasks to be performed in specific sprints - starting with those with the highest priority. There are two forms of prioritizing the backlog:
- Vector form - prioritizing each position with another priority. The advantage of the vector method is to avoid situations where we have given the highest priority to many tasks. There is only one task with the highest priority in this method.
- However, this situation may create a problem in the eyes of the Product owner. The owner of the product, seeing many tasks of low priority, gains the feeling that the team members consider them invalid. This may be due to a lack of trust. The proposed solution to this problem is to present the backlog to the owner in terms of "which tasks should be done in advance" instead of "which task is the most important".
- Dividing tasks into collections by importance - You divide into several sets of tasks of different importance, and then assign the task to a given set.
- The "collections" method is definitely faster than vector. Product owner, who distributes tasks, most often uses these forms. Practice shows that the use of this method creates difficulties when it is necessary to change the way of prioritization.
Refinement
Once the name grooming was used, but today it is used less and less frequently. Refinement is a permanent stage of the work cycle, which consists in ordering the backlog. One of the authors compares this stage to the care of the garden, which when neglected, will soon start to overgrow with weeds. Similarly, backolg, which requires constant care to keep it in the right form. Refinement takes place during regular team meetings with the product owner. During the meeting, the following topics are discussed:
- preparation of the story taking into account the nearest sprint planning
- Setting priorities for individual stories
- estimation of the size level of stories
- Creating new stories or improving old ones.
The refinement stage usually takes about 10% of the total team's working time. Where necessary and the current situation, meetings can be called. The Product owner and the person who will be delegated to this task are entitled to this. Most often, such meetings take place two to three times a week in short sessions or once a week with more time.
References
- Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M.,... & Kern, J. (2001). The agile manifesto.
- Schwaber, K., & Sutherland, J. (2007). Scrum.
- Sutherland, J. (2004). Agile development: Lessons learned from the first scrum. Cutter Agile Project Management Advisory Service: Executive Update, 5(20), 1-4.
