Updated: Mar 28
Since Backlog is vital to the long-term work of Planning Game for Project Management and even the Scrum team, today we will take a detailed look at what Backlog is? What a reasonable Backlog looks like.
Backlog is the core and origin of Scrum
This is easier to understand. Because Backlog is simply a collection of a series of requirements. In the final analysis, agile development still fulfills specific requirements. If there is no demand, then everyone has nothing to do. So there is no doubt that Backlog is the core and origin of Scrum. This leads directly to the next point I want to highlight.
Every role is responsible for the normal development of various activities of Scrum! Therefore, although PO is the Owner of Backlog, other Scrum team members, especially the Research and development (R&D) team, also have the responsibility and obligation to help PO organize the Backlog, especially to determine the priority of requirements!
Because PO only considers the importance of demand from the perspective of business needs or product development paths and is not necessarily a schedule for maximizing Return On Investment (ROI).
For example, if A demand can bring 100w of income to the company, but it needs to invest 10 people in the research and development team for 3 months.
And B demand, although it can only bring 2w of income to the company, it can be launched in one day of development by one person. If you are a PO, how should the priority of the demand be arranged? Obviously, the business importance of B's requirements is not as good as that of A because the investment is very small and the ROI is high, the priority of the requirements should be higher than that of A.
Regarding the amount of work, it takes to realize a specific requirement, or whether a large requirement can be further divided and delivered gradually, the Research and development (R&D) team is more professional, and the input of the R&D team is crucial for PO's priority prioritization.
Therefore, in a Sprint, it is strongly recommended that the R&D team leave some time to sort out the Backlog of the follow-up Sprint with the PO and clarify the initial priority.
*Note: The priority here is still the "preliminary" priority before the Planning Game meeting. The priority of the specific requirements in the Sprint is actually finalized in the Planning Game for Project Management.
I have also used some demand management tools, but the one that really feels convenient and efficient is Excel. Let me introduce to you what an actual Backlog looks like.
The real Backlog may add some columns according to actual needs, but the columns shown in the figure are the most commonly used and indispensable in actual implementation. Let us explain the meaning of each column in detail:
ID: As the name suggests, it uniquely identifies a requirement (user story), and a row represents a requirement or user story.
Name: It is used to simply describe the function of the requirement, and can be used as the text posted on the whiteboard.
Imp: Importance, that is, the priority of the demand. It is represented by numbers here, the higher the number is the higher priority demand. But there are no multiple relationships. For example, the above figure shows that demand 1 has a higher priority than demand 2, but it does not mean that demand 1 is three times more important than demand 2.
*Note: Why use numbers instead of the common "5-level method" (primary, important, common, secondary, lowest - or other description)? It is to avoid two problems that are also the "primary" priority. That is, in the Backlog of Scrum, no two requirements have the same priority, so you must distinguish between high and low. Moreover, the priority sometimes needs to be adjusted temporarily, and it is more convenient to use numbers. For example, I think that a requirement priority is more important than 10, but 15 is not as important. I can set it to 12, or even 12.5, 12.55... You can always prioritize two requirements.
EST: The size of the demand, or story point. It should be noted that the scale here is also a preliminary estimate (it can be input by experts with more experience in the R&D team), and the final estimate needs to be collectively carried out by the team in the Planning Game.
How to Demo: In fact, it is how to accept and define the DoD (Definition Of Done) of requirements.
Notes: Remarks or other information related to requirements (links to detailed requirements description documents, UI design, etc.)
*Note: Of course, it is best to record and clarify requirements in the form of user stories. If it is not possible for the time being, you can also use Backlog as an index for requirements management, and view detailed requirements documents as links.
The Backlog stays at the business level
Backlog's clarification of requirements should be described from the user's point of view or from the business point of view, and should not output specific solutions.
Why do you emphasize this point? Because I have met some students who are making products from technology transformation, and they often bring their own thinking about technical solutions. This actually needs to be avoided as much as possible.
For example, I once saw such a demand description: "Add an index to the order database table". I asked this PO: "Why do you need to add an index to the order database table?" He replied: "We are too slow to query orders now. I hope the experience of querying orders can be improved." I said, "Good. Is it troublesome to adjust your needs? You can change it to this [As a user, I hope to see my historical order information on the order query page, and press the query button to return the result within 0.5 seconds] OK?".
Why do you adjust this way? Because we want "professional people to do professional things". PO as the demander, just put forward your business needs. As for adding an index to the order library, it may be a good way to implement it, or it may not. The specific implementation is left to the R&D staff to decide.
Now, you should have a basic idea of how Backlog should be organized, right? So, where is the fun working method? Let's break it down next time!