Continuing the FAQ Scrum series, today we will talk about Stories and Product Backlog. In the post Learning the Scrum Terms – Glossary, we have learned the definition of these two terms. Here is a reminder of what they mean:
“Stories – Are the Product Backlog items that represent the part of the product to be implemented. Stories should contain a detailed description of what should be implemented.”
“Product Backlog – List of items or stories that should be implemented to create the desired product or project development.”
Ok, but how does this work in reality?
Let’s start with the Stories:
As stated above, they represent a part of the product to be implemented because the Product Owner (PO) requested it. Generally, the stories are raised during a meeting between the team, Scrum Master and PO and there is no level of granularity pre-set for them. A story can described as anything from changing a label on the screen to the creation of a new system functionality. The important thing is to check that what should be implemented to make the complete the Story was really understood by the team.
It is possible that in some stories the team feels the need to split the task required in order to have greater control over what should be done. That is not a problem. In fact, it is highly recommended. During the meeting, the team can and should suggest to the PO that a particular story is divided into different ones or has changed its description. The function of the team is not only to develop the desired functionality, but also to find, along with the PO, the best way to complete each story.
Now let’s talk about the Product Backlog:
All Stories the PO comes up with should be on the Product Backlog. In it are listed all the needs identified for the project, sorted by priority by the PO. In addition, the Product Backlog is never complete. It should be updated as the project development progresses and new needs are met. At each iteration of the project, it is possible that new stories enter the Product Backlog and new priorities are established.
Before starting the development, each story should be divided into tasks. Each task should represent a step that must be completed within one day of work to finalize the functionality included in that story. An important point to be considered when establishing the duties of a story is that, ideally, the whole team must work on developing it. That way everyone can share knowledge related to that Story and also increases staff productivity.