Scrum Practices: Product BacklogPosted by BrainConcert
In the previous article we had a look on the Daily Scrum, a very important Scrum Practice but which can be easily applied in any non-Scrum project. In this article we will on how requirements are managed inside a Scrum project by using the Product Backlog.
In the simplest definition, the Scrum Product Backlog is a list of all the things that needs to be done in the project, ordered by their priority, with the most important showing at the top of the list. The list is derived from the project roadmap and its requirements and is updated constantly by the Product Owner. Each item on the list contains a short description of the functionality desired in the product. This is different from the traditional approach where you need to put a consistent effort upfront to generate a comprehensive (and usually lengthy) document which contained (almost) all requirements of the product and on which the customer has to agree upon before the development starts The reality has proved that such an approach is very costly and does not deliver the best results, as the customers usually do not have a complete, upfront, full picture of what they want it will be practically impossible to generate such a document without later to significantly updated it. Which makes the initial effort quite useless.
The Scrum approach is to start with high-level requirements (sometimes called epics), and delve in to each of these epics to identify more detailed, more refined requirements, called user stories.
To give an example, almost any product has some sort of User Management facility, which can be seen as an epic (is a high-level requirements). Further more, the epic can be deconstructed in several user stories which are more concrete and the developers can work on them like: create an account, update account information, reset account password, deactivate an account. For each of this stories, a short description is provided by the Product Owner as follows: As a anonymous user, I want to be able to create my own account on the application with minimum information provided: first name, last name, e-mail address and password. The structure of the description is recommended to be as in the example because:
- it is showing the user perspective so it will be better understood by the customer;
- it helps identify the role in the application who is allowed to access the functionality;
- it provides sufficient details in order to start development.
Later on, during Sprint Planning Meeting, when the team decides to start the work on this user stories, the rest of the details will be identified (like if is the case for the password to have special format, or some other optional information like address should also be requested). So, the analysis is actually completed at this stage, the user story is then transferred to the Sprint Backlog, and the developers can start working on it. When transferred, the user story can be broken in more detailed tasks (if is the case) in order to be implemented in parallel by the developers.
There are several characteristics that Product Backlog has, as opposite to a simple todo list:
- it contains only entries that add value - each entry must have some kind of customer value, even if the value is not directly added (like is the case of the technical work).
- is a living document - throughout the project, items are added while existing item maybe modified or even deleted.
- items in the backlog have different levels of details - only the ones that will be implemented in the next sprint are defined in a greater detail, the others are more coarse-grained. That is because it makes no sense to invest time and effort to detail the specification of all items, since some of them will for sure change until the actual implementation begins. However, once the item moves to Sprint Backlog in theory should not be changed anymore; if the change cannot be avoided, then the item is brought back to Product Backlog.
- have estimations each user story is estimated, usually using story points (which is an abstraction of the more common ways of estimating like man-days or man-hours). This estimation has two important roles: it helps in sizing the Spring backlog, considering a specific velocity of the team (= the total amount of story points that a team can implement during a sprint) and also it gives an idea about the complexity of the user story. It makes no sense to put concrete man-days effort until the user story is actually assigned to a Sprint backlog and the actual developer/developers can estimate it. Otherwise, since each developer has its own pace, a man-days estimations will only be relevant to the person that made it which is might not be the developer who will implement it.
- no low-level tasks - the items maybe split in more than one task during Sprint Planning Meeting and they will appear as such in Sprint Backlog but not in the Product Backlog.
Although in theory, the items from Product Backlog are consumed in the order of their priority, and team decides during the Sprint Planning Meeting what items can be implemented in the next sprint, sometimes items with lower priority from the list, but related to the high priority ones are included in the sprint, in order to completely develop a specific user story.
Technically, a Product Backlog can be managed using a whiteboard with cards on it, an Excel file, or one of the many applications and plugins specially developed to manage Scrum practices. It does not matter how it is done as long as it is used correctly. While the whiteboard approach has a more visual impact and developers can always see the backlog in front of their eyes, without opening an application, the more technical implementations are easier to maintain and you get additional features like reminders, more compact views, statistics, etc.
Independent of the way it is implemented, it requires a collaborative effort to maintain it. Even though only Product Owner is responsible for performing changes on it, the whole team is involved: sprint planning meetings, other discussions, the estimations all contribute to clarify the requirements and creates a buy-in from the team.