Product Backlog
If you follow our Agile article series, then you should be familiar with the term “Product Backlog”. Here we would like to increase your insight into the topic by sharing the information concerning the Product Backlog, its components and the strategy to create one.
A Product Backlog is a list of tasks to create a new software product. These tasks can have a form of small user-perspective requirements (user stories) or big bodies of work (epics), that could be divided into smaller tasks. The most prioritized items usually are shown at the top of the list; thus, the team is familiar with important features that should be delivered first.
The development team works on the Product Backlog throughout every stage of the project. Hence, eventually it turns out to be a series of new features, new versions of old features, bug fixes, etc.
Now let’s explore the strategy you need to follow to create the Product Backlog for your project.
At the beginning of the project the Scrum team creates the Product Backlog by adding all the ideas that come to their minds easily. Usually, it is more than enough for the first sprint.
The Backlog requires constant maintenance and attention, as the following steps are:
- Throughout the work new items can be discovered and new ideas can appear. Thus, they need to be added to the list.
- If existing issues are not actual anymore, they should be removed or changed, if possible.
- It is very important to maintain the order within the Product Backlog. Hence, the most important issues are to be moved to the top of the list.
- After the testing phase, there might be bug issues that should be added to the Backlog.
It is the Scrum master’s responsibility to be sure that the Product Backlog is well-maintained and in order. A properly made and well-prioritized Scrum Product Backlog is key to increase the efficiency of the whole Scrum team.
To explore the topic of the Product Backlog more, let’s talk about its components: user stories and epics.
User stories
Briefly speaking, a user story is the smallest unit of agile work created in relation to the customer or the end user. It can be a software feature or only a part of it.
One of the principles of the agile methodology is putting people first, thus, a user story fulfils it fully. User stories are written with non-technical or even informal language, so the development team can easily understand the item they are working on and its purpose.
User stories reflect the desired outcome for an end user. Hence, they rarely contain a lot of details. All the requirements and details can be added later as working process will go on.
To measure the complexity of the task, story points are used. An assigned number for each story is the estimation of the amount of effort required to build a feature. In other words, the team should consider the complexity of the feature, the technical abilities of the people involved into the project, etc.
The estimation of story points happens after the user stories were defined. To do so all the Scrum team members need to participate in the discussion, as their skills, experience and filed of knowledge may vary.
Epics
Epics are bigger bodies of work composed by smaller user stories, which help to manage tasks and make the Product Backlog more structured.
The main purpose of epics is to create a structure based on hierarchy with epics on the top, as they can be broken down into small shippable items to deliver the value to the client more often.
Being large bodies of work, epics are usually delivered over multiple sprints.
It’s worth to mention, that in case of a big and ambitious project, entities bigger than epics can be used. Epics are building blocs of initiatives, that are used to structure huge Product Backlogs.
The Livex Software development team is highly skilled in all areas of development and can develop the perfect software system for your business needs.