Introducing the product backlog for scrum
The basic concept of scrum is not complex, but it is not easy to do well, and everyone knows the importance of the product backlog, but how do we develop and present it, how to assess priorities, and how to perform initial evaluations? Below I will cover some issues related to the product backlog.
The process and terminology in scrum are described in this article, which focuses on the first most important artifact Product Backlog. It is the core of scrum and the origin of everything. It is a list of stories sorted by the level of importance that the Product owner is responsible for making.
First, what is the Prodcut Backlog
The backlog in English means "backlog of work". The product backlog is a prioritized list of requirements, with a rough estimate of each requirement. All tasks that can be foreseen in scrum, including Bugs product feature requirements, defects, bugs, user-proposed improvements, competitive features, and technical upgrades, are defined by priority, which may not be complete or may be changed or added at any time. The Prodcut backlog is always in an incomplete state, and it changes as the product and its use environment change, it is dynamic, and management constantly changes it, determines product requirements, and ensures product suitability, practicality and competitiveness.
- The story on the top of the list is first done by the team
- The Product backlog is not made once, it is dynamic, it needs to be continuously revised, and the story may be added, deleted, modified, merged, or split.
- The goal of any backlog is that it should be short enough, high enough, and no special circumstances to modify. If the backlog changes, then I think you should assume that your backlog is wrong, not a change in demand. Change requirements often mean that the backlog is too long or too detailed, such as writing complex algorithms and logic into the backlog, or writing too vague, and spending too much time guessing what it is talking about.
Ii. What is the use of the prodcut backlog
The Product backlog lists all the features that are about to be developed in the product based on user value, and by simply demonstrating what needs to be done, we can estimate the size of the project and determine the release plan and iteration plan. The product backlog helps us to have a holistic understanding of what we are going to do, and to know where we are now. If there is no backlog, we will not know what the present and future products are made of, due to the unclear product objectives, of course, do not know when to release the product, or the release of the product can bring value to the customer.
Iii. who provides the product backlog requirements
Product owner and customer recently, he knows exactly what the product should look like, so it should be made by product owner. The requirements are set by the product owner or customer, and sometimes the team's needs analysts can define the requirements with the product owner or customer. After development, the scrum Master and team assist the product owner in revising and conducting the initial evaluation, and the requirements are discussed further in the Sprint planning meeting.
Iv. when will the product backlog be modified
If a list is too long or the content is stale, the product backlog is much more wasteful than the value itself, so we must constantly maintain the backlog. The product backlog is provided by the product owner and, when scaled with the team, it is possible to split the merge or add the deletion story, and the initial estimate is also provided by the team to evaluate the estimate. Product owners typically present their own prioritized order to the development team, and the team may ask the product owner to make minor adjustments to the order based on their assessment of the subject.
Five, how to write Story
It is generally described as a lightweight story. The user story is the most basic design unit, which is a brief description of the function from the point of view of the system user or customer. User stories are free in form, with no obligatory syntax. However, it is useful to consider a user story in a way that is roughly consistent with this: "As the type of user", I want to be able to "do this first, and then do that, and you should get ..." The result of the "business value". With such a model as an example, you can get a user story saying: "As a bookseller, I hope to find a book based on ISBN so that I can find the right book faster." "When making a user story, be aware that each user story is in the user's language, it only describes a feature (feature), and the development cycle for each user story is not too long (1-5 days)
We don't need to start with a detailed description of all the stories, but the story that you plan to put in the next sprint should be quite clear. The story of the backlog can be written according to the form in the Smoke book:
ID is a unique identity, it is best to fix it, and use that ID to refer to the story in other work or document.
Name2 to 10 words, a simple description of the story, if a lot of words to express the story, it is likely that the story is too big, or unclear
The importance of this priority determines the story selected by the sprint, the higher the priority of the earlier implementation
Initial estimate This is the team to estimate according to the story description content, the product owner after explaining the story, the team to the unclear inquiry, presumably understand the rough estimate. From the perspective of estimation, the story should not be too short, but also can not be too detailed, do not need to put the specific rules and algorithms written in.
How do demo from the user's perspective, from the operational level of the story how it can be demonstrated through software, but also as a simple test case. "How to demonstrate" is required for high-importance backlog entries.
Notes -related information, explanatory notes, and references to other materials are generally very brief.
Sometimes I also add a classification column to identify the topic of the story, through the topic to see the main content of the demand from a larger perspective, and later can be based on the priority of the topic to initially determine the priority of the story.
"trailblazer" products (financial instruments)-product
backlog
Financial Instruments-product Backlog
| Id |
Name |
Imp |
Est |
How to Demo |
Notes |
| 1 |
Calculator |
50 |
20 |
As a financial instrument, of course, it needs Have a decent calculator, which The function of the calculator must also have certain to The calculator must be able to calculate accurately Each time the financial investment, can give the user An estimate of the benefits of financial investment value or investment loss level information . |
|
| 2 |
Calculation type |
45 |
30 |
The calculations contained within a financial instrument There are some types, such as currency Exchange, compound interest deposit, loan repayment investment rate of return, stock Investment, personal tax Services, Retirement Calculation types such as gold calculations, Easy to cast investors ' return on their investments or Loss A certain understanding of the damage. |
|
| 3 |
To view your Investment information |
45 |
45 |
A financial instrument can certainly see itself Investment information, investment records, investment Income situation, and so on. We just need to sign Record your own account in your own account Investment information, you can select a Each page shows all of the Investment information. |
|
| 4 |
|
|
|
|
|
| 5 |
|
|
|
|
|
| 6 |
|
|
|
|
|
| 7 |
|
|
|
|
|
0511--team Project-Product Backlog