When a backlog item is first added to a product backlog, rarely will it be in its final form. At a minimum the user story (u/s) and acceptance criteria (a/c) will change as the Product Owner works on refining the business value each item describes.
Later, when the Scrum Team has an opportunity to preview each backlog item during a Story Time meeting, even more dramatic changes may be required. This is because the team will be thinking about how the item might be implemented and make suggestions according to their theoretical approach. They may recommend splitting the item into two because of size, or the discussion will result in new backlog items spawning from the original idea. Combining items may also be suggested where the team believes they can gain efficiencies.
The following sections explain the different types of metamorphoses, when they might occur and why.
Splitting the Backlog Item
Sometimes a backlog item represents a scope greater than what can be completed by a Scrum Team during a sprint. The obvious thing to do is to split it up into two or more items but therein lies the challenge, how can it be divided?
The first area to look at is the user story (u/s) to see if the business value it describes is defining functionality at too high a level. For example, a backlog item that describes a user’s ability to log into a website and include the functionality to recover their username/password might be split between logging-in and account-recovery functions. Yes, they are both essential to a complete website experience but arguably, having the ability to log in is more valuable and therefore could be separated and completed first.
The second area to look at is the acceptance criteria (a/c) to see if they represent more than one theme. Returning to the example of a function that enables a user to recover their username/password, the acceptance criteria could be separated into two groups, one for usernames and the other for passwords each within their own backlog item.
Spawning a New Backlog Item
When a backlog item has dependencies necessary to either begin or finish the work, new items may be spawned and placed at a higher priority to ensure they are completed first. This could include a research spike to give the Scrum Team time to learn about a technology, design work on a database, or prototyping to decide what the final strategy will be.
Newly spawned backlog items aren’t only for prerequisites, they can also reflect work necessary as a result of completing the original backlog item. For example, if a website was going to collect statistics on performance then someone will want a report or interface to access the data later.
Combining Backlog Items
As a Scrum Team looks ahead at upcoming backlog items they may see patterns in the requirements or how implementation might proceed. Combining backlog items could make sense in order to gain efficiencies in either the coding or testing necessary to complete the work.
For example, if a backlog item described enhancing the monthly sales report to include commissions paid out and a completely different item described adding a column for partner revenue sharing totals, the Developers may want to complete both enhancements within the same item because to “open the hood” on the reporting engine is time consuming and doing it once is preferred.
———-
© 2012 William Patrick Swisher
