Avoiding Product Backlog Pitfalls – Get The Most Out Of Scrum

By Author: Mrugesh Panchal
Total Articles: 48
Comment this article

The product backlog is the heart of scrum in many ways. All the technical requirements needed to develop the product are included in the form of user stories in the product backlog. It is important that the product backlog item, or the user story, should be properly defined and narrated within the backlog. A product backlog item consists of several types of information, which actually define the exact requirement to be developed by the developed team during the sprint. It is very important that the product owner, the person who defines the user stories in the product backlog, avoid certain pitfalls, which can mess up the readability of the user story, or make it ineffective for development purpose.

• Creating the product backlog without any prioritization
Estimation is an integral part of scrum, and burn down charts are created to reflect the velocity at which the team is currently carrying out the daily sprints. Estimation is possible only if backlog items are prioritised with ...
... user stories.

• Creating the headline and not adding any explanatory description
Adding a title to mention the story name alone does not suffice. The team needs more information regarding the story to be developed.

• Using less priority levels
The user stories should include at least three priorities – high, medium, and low. Using only two priority levels such as “urgent” and “Later” fails to give a proper idea to the team as to how important the story is from the development point of view.

• Committing the release date without prior communication
The team should be initially consulted and a release date worked out before apprising the stakeholders about the date.

• Creating tasks instead of user stories
During the second half of the sprint planning meeting, the team segregates the user stories into individual tasks. The product owner should not define individual tasks in lieu of user stories in the backlog.

• Long running sprints
The sprint should ideally last up to two weeks. If the cost effectiveness of product development is to be maintained, the sprint should be properly decided. It should not be too long so that feedback is availed after long intervals, and it should not be too short so that the team does not have enough time to develop the tasks. Both the aspects should be properly balanced.

• Preparing a limited number of user stories
When the scrum project is planned, the product owner should create the entire product backlog. Creating a few stories to “start” the scrum process defeats the very purpose of implementing scrum, since proper estimation cannot be carried out, and velocity too cannot be determined in an effective manner.

• Meeting only once a week
The product owner should be available as and when required by the team members and the scrum master. Meeting only once a week can prevent the team from proceeding with the development in case any problems are encountered during the sprint or additional information is required to understand the user story.

• Answering your phone during the meeting.
Perhaps the most irritating aspect is answering cell phones while a meeting is underway. It not only wastes time, but also breaks the concentration levels.