I suggest you to see together how to manage his backlog from theme to user-stories. It is not complicated, but this article will help those who make their first Agile projects.
A product-produced backlog
In the majority of cases, we will create a product backlog by product. We will consider that it is the highest cutting of the product.
On the big products where it is essential to work with several teams, the team will share the same backlog. we call that agile at scale.
However, in some cases, the teams that manage X products will prefer to have a complete backlog for all their tasks but we will consider this as a special case because it is never good to intervene on several products in a only sprint.
For our article, I will imagine an imaginary ecommerce website “Myshop Partner”. The construction of this ecommerce website will go through a full backlog.
A sprint backlog by Sprint
The Sprint backlog represents the content of the work to be done within a Sprint. If we have several teams working on the same backlog, we can have several sprints in parallel.
A sprint backlog only lasts one sprint and will be replaced by another sprint backlog. It is the Product Owner who will propose the contents of a sprint backlog at the beginning of the sprint that the team will have to develop.
* We will talk about Product Owner in this article because it is the best known role for backlog management with Scrum but it is possible that this role is held by other roles as the customer representative.
A backlog is divided into themes
To facilitate the prioritization work, we will make a first cutting of the backlog into several themes.
It is not easy to define a strict rule of what a theme is because it will depend on the interpretation of each Product Owner (PO). The main thing is that the PO feels comfortable with the themes that he has defined and they will allow him to prioritize at the highest level.
For example for our ecommerce website, we could have:
- theme 1: a cart
- a theme 2: product management
- theme 3: site navigation
Product backlog: cut out themes in Features
Some people prefer to add an additional cutting: the features (features). This can be useful for managing another level of prioritization.
For example with our ecommerce website, we could have:
- feature 1: page cart
- a feature 2: payment method
- feature 3: delivery management
Product backlog: features divided into User-stories
Features can be split into Epics. However Epics are not the grouping of user-stories as some people think. Check out the article on this subject that I wrote to better understand what an Epic is.
Article : What’s an Epic in Agile?
Here is an example. An Epic will become 1 or x user-stories.
We will therefore consider that the features are split into user-stories as shown in the drawing below.
For example for our ecommerce website, we could have for the feature 2 named “means of payment”:
- user-story 4: As a customer, I want to pay my cart in credit card
- a user-story 5: As a customer, I want to pay my purchase in 3 times
- user-story 6: As a customer, I want to pay by bank transfer
If I have simplified the user-stories so that the splitting is understood, in real life, these user-stories would be more detailed.
Product backlog: user-stories split into technical subtask
In Scrum, developers split all user-stories into technical sub-tasks to help them in their work. The level of detail of the technical sub-tasks is defined by the developers themselves: there are no bad splitting or good splitting.
For example with our ecommerce website, we could have for the user-story 4 named “As a customer, I want to pay my cart with my credit card”:
- technical sub-task 1: contact banking API
- a technical subtask 2: create secure connection with OAUTH
- technical subtask 3: display payment method
A theme can define something technical
In frameworks like SAFe, we talk about Enablers at different levels to define architecture, exploration, infrastructure or compliance.
However in this article, we will not talk about SAFe. It imposes an interresting way of doing to know but which is not necessarily adapted to all contexts.
This part of the article is a vision that is not shared by all agile coaches. Some believe that everything must go through user-stories; for my part, I feel that this is not the case. Do not be surprised one day to see other explanations that will contradict this part of the article.
We will allow to have technical tasks at the same level that user-stories to define technical work. Example: installation of a database (probably used by 80% of user-stories).
It is also possible to define a theme as something technical like “refactoring in angular 5”. This will be splitted into several technical tasks or even features if the Product Owner feels more comfortable like that.
Developers will be able to easily split their technical tasks into technical sub-tasks during Sprint Planning. The content of the technical tasks will be the responsibility of the developers and not the Product Owner unlike the user-stories.
Conclusion product backlog
Here is the most common example of product backlog splitting that we encounter (features are less used as an intermediary). I advice you to use these terms to have a language close to other agile teams and other teams.
3 Trackbacks / Pingbacks