How Can A Product Owner Decide Which User Stories Should Be Defined In A Product Backlog?

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

Importance of defining meaning user stories or product backlog items in scrum
In scrum, it is not so easy to determine what can and should be developed by the team during the sprint. A scrum project can contain several entities which are essential to develop a successful user story, and the product owner has to carefully consider the suggestions put forward by the stakeholders while defining the product backlog items. At times, it becomes difficult for the PO to adjudge whether a suggested item ought to be included in the product backlog or not. The main reason is sometimes certain items seem important when they are initially suggested, and the PO may include them in the backlog for development purposes. The items are subsequently transferred to the sprint backlog for development during the sprint planning meeting, and after they are successfully developed, the PO may realize the items do not hold a significant business value, and were in fact not required to be developed in the first place. The realization comes at the fag end of the sprint retrospective when the stakeholders ...
... inform the PO that the items do not have a great shippable value. As a result, resources are wasted and the investment returns desired out of the scrum project start decreasing due to the increased overheads in terms of remuneration provided to the development team.

Finding out whether the item suggested for a user story is developable or not
It is imperative that user stories be properly stated and defined in the product backlog by the product owner. In many cases, it becomes difficult to ascertain whether a developable backlog item is a user story or something else. The product owner may face a lot of confusion regarding how certain types of user stories should be written, and whether a particular story is developable or not. In practice, the product backlog can include a lot of other stuff such as technical documentation, user manuals, acceptance tests, epics, designing aspects, etc. These types of items are not developable, but are needed to make a particular user story complete and shippable. For example, a particular feature or functionality developed during the sprint may need to be accompanied by a technical reference before which it can be considered as “complete” and shippable. If such is the case, the technical reference is not a developable item, but still needs to be included in the product backlog so a technical drafter can develop it during the sprint when the particular user story is developed simultaneously. At the time of sprint review or sprint retrospective, the team can combine the user story developed by the team along with the reference drafted by the technical person and submit it for approval. It is important to know that not everything that the development team develops is a user story in scrum.

To find out whether a particular product backlog item is a user story or not and whether it should be included in the product backlog try asking these questions:
• Does the suggested item describe a new or changed feature or functionality linked with the product?
• Even if the item is not “developable” is it of significant value to the stakeholders?
• Is the item required to complement some or the other aspect of user stories already defined or proposed in the product backlog?
• Can a proper description or explanation be suggested for the suggested item?
• Can proper acceptance criteria be defined for the item?
If you have answered with a “No” to all of the above questions, the suggested item cannot be a user story and/or it should not be included in the product backlog.

Can the questions be used to determine the validity of all suggested items in scrum projects?
The above questions cannot be definitive, nor can they be accepted as a “thumb rule” for ascertaining whether an item should be considered as a user story or not. This is because not all scrum projects are alike. Moreover, scrum is adaptable. Scrum implementation can change from project to project, and while a particular item may prove to be useless as a user story in one project, the same item may be very important from the development point of view in another one. A lot depends upon the type and nature of the scrum project to be developed. The suggestions can help to clear the confusion faced by the PO while defining the product backlog items.