Product backlog: Difference between revisions
m (Infobox5 upgrade) |
m (Text cleaning) |
||
Line 43: | Line 43: | ||
==Examples of Product backlog== | ==Examples of Product backlog== | ||
* '''User stories''': A user story is a simple description of the functionality that a user requires from your product. It helps to define the requirements from the user’s perspective. For example, | * '''User stories''': A user story is a simple description of the functionality that a user requires from your product. It helps to define the requirements from the user’s perspective. For example, "As a user, I would like to be able to search for products in my shopping cart." | ||
* '''Technical tasks''': Technical tasks are specific tasks that need to be completed in order to make a user story work. These tasks can include coding, bug fixes, [[database]] modifications, etc. For example, | * '''Technical tasks''': Technical tasks are specific tasks that need to be completed in order to make a user story work. These tasks can include coding, bug fixes, [[database]] modifications, etc. For example, "Create a search feature that allows users to search for products in their shopping cart." | ||
* '''Design tasks''': Design tasks involve creating the visual elements of a user story. These tasks involve creating the user interface, logos, graphics, etc. For example, | * '''Design tasks''': Design tasks involve creating the visual elements of a user story. These tasks involve creating the user interface, logos, graphics, etc. For example, "Create a simple and intuitive user interface for the search feature." | ||
* '''Research tasks''': Research tasks involve conducting research in order to better understand user [[needs]]. These tasks involve user interviews, surveys, usability tests, etc. For example, | * '''Research tasks''': Research tasks involve conducting research in order to better understand user [[needs]]. These tasks involve user interviews, surveys, usability tests, etc. For example, "Conduct user interviews to better understand user needs for the search feature." | ||
==Advantages of Product backlog== | ==Advantages of Product backlog== | ||
Line 79: | Line 79: | ||
* Schwaber, K., & Sutherland, J. (2007). ''[http://www.volaroint.com/wp-content/uploads/dlm_uploads/2014/03/DC-VOLARO-Training-Scrum-What_Is_Scrum.pdf Scrum]''. | * Schwaber, K., & Sutherland, J. (2007). ''[http://www.volaroint.com/wp-content/uploads/dlm_uploads/2014/03/DC-VOLARO-Training-Scrum-What_Is_Scrum.pdf Scrum]''. | ||
* Sutherland, J. (2004). ''[http://www.toolshero.nl/wp-content/uploads/agile-development_lessons_learned_jeff_sutherland.pdf Agile development: Lessons learned from the first scrum]''. Cutter Agile [[Project]] Management Advisory [[Service]]: Executive Update, 5(20), 1-4. | * Sutherland, J. (2004). ''[http://www.toolshero.nl/wp-content/uploads/agile-development_lessons_learned_jeff_sutherland.pdf Agile development: Lessons learned from the first scrum]''. Cutter Agile [[Project]] Management Advisory [[Service]]: Executive Update, 5(20), 1-4. | ||
[[Category:Project management]] | [[Category:Project management]] |
Latest revision as of 02:40, 18 November 2023
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.
Examples of Product backlog
- User stories: A user story is a simple description of the functionality that a user requires from your product. It helps to define the requirements from the user’s perspective. For example, "As a user, I would like to be able to search for products in my shopping cart."
- Technical tasks: Technical tasks are specific tasks that need to be completed in order to make a user story work. These tasks can include coding, bug fixes, database modifications, etc. For example, "Create a search feature that allows users to search for products in their shopping cart."
- Design tasks: Design tasks involve creating the visual elements of a user story. These tasks involve creating the user interface, logos, graphics, etc. For example, "Create a simple and intuitive user interface for the search feature."
- Research tasks: Research tasks involve conducting research in order to better understand user needs. These tasks involve user interviews, surveys, usability tests, etc. For example, "Conduct user interviews to better understand user needs for the search feature."
Advantages of Product backlog
A product backlog is a list of features and tasks that are necessary for the development and success of a product. It is an essential component of the scrum methodology, as it helps to prioritize tasks and keep the development process on track. The following are some of the advantages of a product backlog:
- It helps to organize tasks and prioritize them according to their importance. This ensures that the most important tasks are completed first and that the development process is efficient.
- It serves as a reference point for stakeholders and developers, providing a clear understanding of the product's objectives and requirements.
- It helps to track progress and identify areas of improvement. This allows for feedback and adjustments to be made quickly and easily.
- It provides visibility for stakeholders, giving them a clear view of the product's progress and any changes that need to be made.
- It helps to ensure that the product meets customer expectations and that the development process is on time and on budget.
Limitations of Product backlog
The Product backlog is a prioritized list of tasks that need to be done in order to get a product, and is the basis of customer requirements for the final shape of the product. However, there are several limitations to the Product backlog that must be taken into account when using it:
- It can be difficult to prioritize tasks as they may have different levels of importance or urgency.
- The backlog may contain tasks that are no longer relevant or needed, which can lead to wasted effort and resources.
- It is not always easy to keep the backlog up-to-date with customer requirements, as customer needs may change over time.
- The backlog can be difficult to manage if there are many tasks and a large number of stakeholders involved.
- The Product backlog does not provide a detailed plan for the implementation of tasks, which can lead to confusion and difficulties in tracking progress.
The Product Backlog is a concept related to the scrum method and is a prioritized list of all tasks that should be done to get the product. Other approaches related to Product Backlog include:
- Estimating and Prioritizing Backlog Items - Estimating the complexity of the tasks and ranking them according to their priority is important for efficient work.
- Refining Backlog Items - During the refining process, backlog items are broken down into smaller, more manageable tasks.
- Adapting Backlog Items - As the development team progresses, it is important to adapt the backlog items to the changing situation.
- Releasing Backlog Items - The final step in the development process is to release the backlog items, allowing the customer to use the final product.
In summary, the Product Backlog is the basis of customer requirements for the final shape of the expected product. In addition, other approaches related to the Product Backlog include estimating and prioritzing, refining, adapting and releasing the backlog items.
Product backlog — recommended articles |
Feature-driven development — Sprint backlog — Behavior driven development — MoSCoW technique — Principles of design harmony — Project status report — Project lifecycle — Project — PMBOK framework |
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.