Once we said that a Sprint is the basis of Scrum and everything revolves around it. But it’s time to tell you this:
Sprint itself revolves around Product Backlog and its derivative – Sprint Backlog!
A Product Backlog should be clear for everyone (and that is the Product Owner’s responsibility). It should be so clear that both the Team and the Owner could work with it without any problems. And it is pure art to create such a Product Backlog. Very often clients and specialists speak different languages and such a "language barrier" makes an effective communication impossible. If there was such a misunderstanding or the wishes of the client was interpreted incorrectly, there is a risk of releasing a product that is completely different from what was originally planned. Even the slightest deviation from the course could lead to such a result.
A Product Backlog consists of Backlog elements, which are often called User Story. In simple words it is a “wish-list”. The items of such a wish-list are sorted according to their importance. Ok, enough talking. Let’s have a look:
|1||Создание корзины покупок||50||13||Зайти на страницу товара, добавить товар в корзину. Зайти в корзину, показать, что товар добавлен. Перейти на другой товар, добавить его, вернуться в корзину и продемонстрировать, что добавлены два товара, есть отображение цен продуктов, общая сумма. Показать как оформить заказ дойдя до стадии оплаты.||1|
|2||Подключить электронную кассу для оплаты товара (название подключаемой кассы)||45||21||Проделав демонстрацию работы корзины – оплатить товар.||1|
Product Backlog fields:
ID – a unique number of a task.
Name – the name of a task which should be clear for everyone and not dubious.
Priority – It shows the order in which the tasks should be accomplished. First the product should be finished and only afterwards it should be improved and extended. Each company has its own priority scales. For instance, It could be from 10 to 150.
Initial rating – An approximate value assigned by the Product Owner and which could be changed. When a Team work together long enough, the Product Owner understands how much time the Team will need to finish this of that tasks. Afterwards it is reevaluated by means of Planning (Scrum) Poker.
Demo – In order to prove that the work is complete, a demo of the product is needed. What does the Product Owner and the Client want? Is should be described in this field.
Release – in simple words, it is a demonstration of the desirable result after the first Sprint. Very often it is hard to decide what should be done, especially if there are tasks with similar priority ratings. For instance, a Product Owner knows how his Team is doing and what they are still capable of based on the Velocity graph. Some task seems to be beyond the capabilities according to Velocity, but the Team could deal with it. But is it necessary? The Product Owner can decide that this task is not necessary for the current moment and plan it for the second Release.
Notes - Notes are always useful. This field could be either left empty or it can help to understand the task.
There could be other field in Product Backlog. They can extend the understanding of the whole project or separate tasks:
Subject – Which theme or category this or that task falls into. This is necessary to divide tasks into separate blocks, which can be useful during bulk rating.
Components – Any development process always consists of separate components. In coding they could be represented by a database, a file server, API and so on. Such a subdivision is especially useful when several Teams work at the project. Each Team can take its own direction which improves the development speed. Jeff Sutherland provided the following example in his book, which truly represents the basics of Scrum. This example is based upon a sequence of letters and numbers.
At first one should write this sequence in separate lines (1 I A, 2 II B, 3 III C, 4 IV D, 5 V E) and track how much time it took him. Let’s imagine that Arabic numbers represent the Database, Roman numbers – the file server and letters represent API. So, at first you should finish some task with database, than with the fileserver, and then with API. But then the test suggests writing the same sequence in separate columns: 1 2 3 4 5, I II III IV V, A B C D E. And of course you will do it much quicker, because your brain won’t have to switch between several numeric systems and letters as it performs better within one system of coordinates.
Based on this example, imagine that your Team have to work with two types of data. This - 3 III C, 5 V E, and this - 1 2 3 4, A B C. I think you will agree that the Team will be more productive with the latter.
Task initiator – As we know, a Product Owner is responsible for the Product Backlog, but the Backlog can be also edited by others. Task initiator field shows which person created the task in the first place and who do you need to contact if necessary.
ID relationship – Relationship to anything. Sometimes it is necessary to link the tasks from the Backlog to a certain third-party service, to a separate bug-tracker, for instance.
There is a common dilemma, connected with category division: what’s the best way to arrange the work if there are several development Teams? It is better to have a separate Product Owner and a Product Backlog for each Team? Or is it better to have one common Owner and a Backlog?
There are several approaches:
Approach #1 – one Product Owner and one Product Backlog
This is similar to a situation when captains of the sports teams choose their players. At first one captain picks the strongest player, then the second captain picks the strongest among the left, and so on. Such approach can be applied here as well. Product Owner sorts the tasks from the Backlog according to their priority rating and Teams begin to choose the tasks in the similar fashion. Tasks are usually divided according to their Subjects (a separate field in the Product Backlog).
Teams can bargain on certain tasks, group them together, change priority ratings.
When the division is done, each Team works only on their tasks (listed in the Sprint Backlog).
Approach #2 – one Product Owner and several Product Backlogs
It’s the same as previous approach, but the tasks are assigned by the Product Owner. You may ask: “Why does the Product Owner need to assign the tasks himself? The Teams know better who is good at what and the Product Owner may not know all the details of development”. But in certain cases this approach is preferable. Such approach accelerates the creation of Sprint Backlogs. If you know which tasks should be given to this or that Team – this approach suits you best.
Approach #3 – several Product Owners and several Product Backlogs
There is such an approach as well and some companies use it. To tell the truth, it is mainly used in cases when the development is subdivided into several global modules which are interconnected in the end.