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 great 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 in order 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 organized. 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 prioritizing 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 very hard 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 prioritized — the Product Owner cannot prioritize 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 greatly limits the ability to deliver working demonstrable software, and can easily result in bottlenecks when a dependency is not working at the same pace as the other pieces of the puzzle.
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 enjoys 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 help the scrum team understand what is most important, aiding as well in the prioritization 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 important 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 usually harder to test, and the user stories must have acceptance criteria that express these rules.
The Product Owner can then prioritize 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 prioritize 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 prioritize 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 very common when functionality involves 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 operations required to fulfil this product backlog item we can breakdown into detailed 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 is difficult to see the value of the individual pieces. But the Product Owner might want to prioritize 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 prioritize as some roles will be more important 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.
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 very simple one, but nonetheless important, as different browsers will handle your platform differently. The Product Owner can then prioritize 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 obvious 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 appropriate 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 smallest 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.
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 jeopardize the sprint goal. There are many more strategies that product owners, scrum masters, product analysts, and developers can use to minimize 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 clever strategies, scrum teams can create amazing products and deliver true value to end-users.
For more strategies, subscribe to see part II.