Virtual NoSQL DB event for Java DevsHow to Break the Product Backlog by@fmrigueiroHow to Break the Product Backlog
December 17th 2020 317 reads
How breaking down your product backlog can help your team create great products.
Teams that have mastered Scrum know that the key to success lies in a just-in-time, increasingly refined, breakdown of work on the Product Backlog. They prefer Sprint Backlogs with many small (functional) items instead of just a few large ones. Having smaller items on the backlog improves the flow or development, reduces risks of failing the goal of the sprint and increases velocity. In this article, I will try to highlight some useful strategies to breakdown a product backlog into bite-sized user stories.
Why and when to break down items
Software development is inherently unpredictable. Some Product Backlog Items (PBI’s) on a backlog will require more effort than expected, while other items will require less. So if your sprint contains only a few large items, the impact of incorrect estimation the work, even on one item, will have a significant impact on whether you can achieve your commitment in sprint planning, and since larger items are harder to estimate, the probability of a failed sprint goal increases.
Seasoned scrum teams spend time and effort breaking down large product backlog items into smaller stories. Even though that this process is done during spring planning, this refinement of the backlog should be carried out continuously to make sprints run smoother and not overload the sprint planning; this is possible because as the development is underway new information surfaces regarding the remaining backlog items, and it is the job of the scrum master and Product Manager to keep the backlog up to date and organised. This process should be done implementing the just in time manner, so the team spends less time preparing items for sprints the further they are down the road.
This exercise has many benefits, including a shared understanding of the product backlog that on itself increases the accuracy of the estimation and facilitates the Product Owner in prioritising the backlog.
This process is not easy to do well, it takes practice to do it under time pressure, but thankfully there are strategies to help break down work into smaller bits.
This exercise has many benefits, including a shared understanding of the product backlog, that on itself increases the accuracy of the estimation and facilitates the Product Owner in prioritising the backlog.
This process is not easy to do well, it takes practice to do it under time pressure, but thankfully there are strategies to help break down work into smaller bits.
Breaking down in vertical slices
As I mentioned in my previous article (User Stories in Agile Development), vertical slices of work are superior to horizontal slices. Horizontal slicing is when work is split on what layer of the software the work is to be carried out, backend, UI, database, etc., this method is not suited to break down product backlog items when working in Agile for multiple reasons:
- Individual items do not result in working demonstrable software. It is tough to articulate the user value from work done only on the database layer, as that piece of work cannot be released until the other layers are complete functionality is done. This also means that until the other pieces of work are finished this specific functionality cannot be tested. Only a combination of all the layers, even small can be classed as demonstrable, working and potentially releasable software.
- Increased bottlenecks — horizontal breakdowns are usually referred to as silo-thinking. The work goes through these silos as development is underway, meaning that if at any stage of development, one of the silos is not working as required, all the development must stop. If your database expert cannot complete the work on time, then the backend guy cannot start. This can create a flow where the team is idle until a specific silo has finished its horizontal slice.
- Horizontal slices cannot be prioritised — the Product Owner cannot prioritise horizontal slices of work, as they do not deliver value or working improvement on its own. Horizontal slices might be technical stories that distance the Product Owner and the team.
Even though breaking the product backlog into horizontal slices can result in small items, it dramatically limits the ability to deliver demonstrable working software. It can easily result in bottlenecks when a dependency is not working at the same pace as the other pieces of the puzzle.
Vertical breakdown
In Scrum vertical breakdown is proven to be more useful, as the backlog of functional requirements is broken down into smaller functional stories and not technical stories. These smaller items, although small, can still result in demonstrable working software that can be tested, and released if desired. So if a PBI is ‘As a customer, I can pay for my order so that I can receive my products’, then the breakdown can be made by according to payment method: ‘As a customer, I want to pay for my order using PayPal so that I can receive my products’ and ‘As a customer, I want to pay for my order using a credit card so that I can receive my products’.
The analogy usually used is a slice of cake, made of sponge, cream and topping, if you slice the cake horizontally, you can only give to your guests (this case the users) a piece of sponge, cream or topping, meaning they cannot fully enjoy the cake. And everybody that wants cake will argue that this is not the way that cake is meant to be enjoyed. But if you slice the cake vertically, even in thin slices, you can provide sponge, cream and topping — a much more enjoyable experience.
There are many strategies to help you break down large PBI’s. These allow the scrum team to understand what is most important, aiding as well in the prioritisation of the backlog.
Breaking using workflow steps
If the product backlog item involves a workflow, detailing the user journey, one of the breakdowns that can be done is splitting into individual steps. Imagine a user processing order on an e-commerce website:
As a customer
I can pay for the goods in my shopping basket
So that I can receive them
If this is broken down into steps, you can assume:
As a customer,
I can log in into my account,
so that I don’t have to reenter my personal details every time.
As a customer,
I can add items to the shopping cart,
so that I can buy multiple items at the same time.
As a user,
I can review and edit my shopping cart,
so that I can confirm or delete any item I no longer need.
As a user,
I can review and confirm my order,
so that I can correct any mistakes before I place the order.
As a user,
I can pay for my order using a credit card,
so that I can confirm my order.
As a user,
I receive an email confirmation of my order,
so that I have proof the order was placed.
Even on this very shallow breakdown of the main requirement, we can have a greater understanding of the functional requirements needed to implement the epic. This view of smaller PBI also increases the ability to estimate, as well as allowing the Product Owner to prioritize what work should be carried out first. Some steps might not be as necessary at the moment and can be moved to future sprints. Perhaps the email confirmation can be done ‘by hand’ at the moment, or it might be ok for the customer to have to enter the personal information for every order. This will limit the functionality of the website, but it does allow the scrum team to review and to develop and release functionality to the users at the end of the sprint.
Breaking down by business rules
Backlog items often involve several implicit business rules. Continuing with the theme of an e-commerce website:
As a customer
I can pay for the goods in my shopping basket
So that I can receive them
We can identify some business rules:
As a shop owner,
I can decline orders below 10 pounds
so that I avoid unprofitable orders;
As a shop owner
I can decline customers from outside the UK
so that I avoid shipping costs that make orders unprofitable;
As a shop owner,
I can cancel orders that have not been paid after 48hours of placement,
so that I can sell the items to other customers;
Business rules are usually implicit, and it requires business intelligence and analysis to express them in requirements. Business rules are traditionally harder to test, and the user stories must have acceptance criteria that define these rules.
The Product Owner can then prioritise the business rules he/she thinks are most important. Maybe it’s sufficient for now to add a banner message to the website displaying ‘Minimum order of 10£ necessary’ or ‘Order will not be shipped outside the UK’.
Breaking down by platform
Most web applications support various platforms, like desktop, tablets, mobile phones, etc. It can be beneficial to break down large PBI’s into what platform users might engage with.
Take the example of an online newspaper:
As a user
I want to read the publication,
so that I am informed of world affairs.
We can identify possible platforms:
As a user,
I want to read the publication on my desktop,
so that I am informed of world affairs.
As a user,
I want to read the publication on my tablet,
so that I am informed of world affairs.
As a user,
I want to read the publication on my mobile
so that I am informed of world affairs.
Through breaking down the PBI by platform, the Product Owner can prioritise the platform that is deemed most important; this can be done using previous knowledge of the market and business intelligence. It might be that a desktop version is sufficient by now, but as more and more people read the news using a mobile phone, it will be required to prioritise the mobile platform above others.
Breaking down by operations
PBI often involves several default operations like Create, Read, Update and Delete (CRUD). CRUD operations are widespread when functionality consists of the management of items, such as users, products, orders, etc.:
As a shop owner,
I can manage the products on my website,
so that I can be up to date with my offering to users
By identifying the specific functions required to fulfil this product backlog item, we can breakdown into complex operations:
As a shop owner
I can add new products,
so that customer can buy them;
As a shop owner,
I can update product listings,
so that I can adjust price and information;
As a shop owner
I can delete a product listing,
so that I remove products no longer in stock;
When breaking down PBI’s using this strategy, sometimes it isn't easy to see the value of the individual pieces. But the Product Owner might want to prioritise the addition of products to create value to the shop owner, while deletion can be done manually. This strategy can be used in any case there is a management of entities to be done, such as users, blog posts, etc.
Breaking down by roles
PBI’s often involve many different roles, or segments of users, that perform parts of the functionality. Different user segments can be used to break down large items and to inform the team what work has to be carried out to fulfil a requirement.
Take a blog example:
As a blog
we can publish new articles on the page,
so that our customers can read them
By breaking down into some of the roles that can use these features, we can have the following list:
As a customer,
I can read the new article,
so I am informed about current events
As a journalist,
I can write an article,
so it can be read by costumers
As an editor,
I can review the article before publishing,
so I can ensure the quality of content
As an admin,
I can remove articles from the website,
so I can remove out of date information
As a journalist,
I receive an email when my article has been reviewed,
so I can edit if necessary
Breaking down functionality, according to the role, gives a more clear understanding of what functionality is needed and can more accurately be estimated. This can help the Product Owner prioritise as some roles will be more critical than others, and can be implemented later on. In this case, it may not be necessary to include an editor, or the journalist can email the editor directly before posting the new article.
Other Strategies
There are many other strategies to break down large product backlog items.
Break down according to test case — This is very helpful specially to identify edge cases and to develop according to test scenarios. Break down according to data type or parameters — An example of this might be how a search function works, and by what data type can a user filter results. Break down according to browser — This is a straightforward one, but essential, as different browsers will handle your platform differently. The Product Owner can then prioritise to the most used browser according to data available. Break down according to acceptance criteria — This might seem obvious, but most time is the most prominent and easiest way to break down a story.
Use the most appropriate strategy for each story, just keeping in mind to slice them vertically and with the relevant acceptance criteria, and always keeping the user in mind.
When enough is enough?
When do you know that a story is small enough? A good rule is not to aim for the shortest possible but to the most size-appropriate PBI. This depends on the sprint length and your team, it usually takes some experience and several sprints to find the most appropriate size. In terms of story points, it is relative, as the whole point system is, but aim for consistent velocity and delivering points throughout the sprint and not have an enormous drop at the end of the sprint. This type of burndown shows that stories are not sufficiently refined and pose a risk of not being completed by the end of the sprint.
Even when delivering smaller pieces of functionality, you are still delivering value, in small increments, and with a nice flow and rhythm. The psychological effect of delivering a finished piece of functionality works as a boost to the team, helping them perform better.
Conclusion
Throughout this article, I have highlighted some strategies to break down large backlog items into smaller ones. A sprint should include a lot of small items instead of few large ones, as this might jeopardise the sprint goal. There are many more strategies that product owners, scrum masters, product analysts, and developers can use to minimise the risk of failing sprint goals. All the stories should be broken down vertically to ensure value to the user at every iteration and not only deliver one piece of the layer.
With the users in mind and using some smart strategies, scrum teams can create unique products and deliver real value to end-users.
Tags
Join Hacker Noon
Create your free account to unlock your custom reading experience.