Every time that a new project pops-up, one of the first actions that the stakeholders do is to define the product backlog. The backlog can be interpreted as a list of desires or features that the product should have. Having a backlog is crucial for any project that is using Agile methodologies. However, only defining the title of these listed items is not enough to fully understand them, and to gather the details too soon in the process might be a waste of time.
One of the techniques that I always like to use on this list is the Backlog Iceberg. This consists of looking at your backlog as an Iceberg, where the most important items should be on the most visible part of the Iceberg, ie its peak, and the items with lower priority or lesser relevance to the stage of the project should be on the bottom of the Iceberg. These items on the bottom of the Iceberg might be extremely important for the end product, but many other items must be delivered before the team start thinking about them, therefore these items should not be inside the range of the next iteration and it is good practice to avoid paying too much attention to them before the right moment.
Ok, so how can I define the proper timing to detail a backlog item or not?
A few factors can influence this decision, such as your team maturity, the stage of the project, and level of knowledge regarding the product that you are developing. A good practice is to know the rhythm of your team and plan up to three iterations accordingly. Teams that are already using story points to define their rhythm/velocity per iteration will be more accurate in defining the proper timing to detail (or not) the future backlog. If you are using Scrum, we would assume that one possible formula to apply this technique is to define the current sprint to attack, plus the three next sprints.
Why could overly-detailed specifications of backlog items be a waste of time?
One of the statements of the Agile Manifesto is “Responding to change over following a plan”, so whenever you are applying some kind of agile methodologies to your projects, we are assuming that changes will happen and this is not the end of the world, but rather a premise of the project. For that reason, if you focused your team on the detailing of items that will not be attacked on the next three sprints, by the time that this item will be selected as the commitment of a sprint, it might be out of date, and or even obsolete. Please, note that this situation will probably still occur using the Backlog Iceberg technique, but we can mitigate the risk of wasting time due to defining things too early if we use this technique.
How do I know if an item is ready to be attacked?
This can vary according to the company, team or even the project, but one good concept that the Agile world uses to solve this problem is to state the “Definition of Ready”.
This consists of defining some acceptance criteria that a backlog item must meet to be considered ready to be attacked in one iteration. Once the team reach a consensus that a specific item is ready, they can move forward to the next item of the product Backlog Iceberg that has not been detailed yet.
Who should be involved in the detailing of the product backlog?
According to the Scrum, The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. However, they are not the only one responsible for this hard task of detailing the backlog. A good practice is to involve the whole development team of the project to help the Project Owner to add details to the next items, which will reduce the misunderstandings during the further sprints and consequently these items will become more clearer to all participants of the project.
The refinement of the product backlog is an on-going task that will endure until the end of the project. The Backlog Iceberg technique is helping agile teams to be more productive and to avoid wasting their time doing things that could be done in another phase.
The Stake Holders of the agile projects might be resistant and feel uncomfortable with this approach of not specifying the whole backlog in detail until they understand that changes will happen all the time. So a good way to try to change their mindset regarding this is to use some analogy explanation.
Let’s assume that you are in a night hike in the bush with only one torch. Within the beam of the torch-light, the next iterations/sprints of your project are illuminated. Future challenges that are further ahead can’t be seen in the darkness. You already have a lot of obstacles in your field of view (the torch-light), so you should not be bothered about what the darkness is hiding.
The Backlog Iceberg as many other techniques relies on peoples mindset, it is not only a formula that you apply to your projects and collects the results. However, explaining this technique to your team might help you to reach a high-performance flow in your projects.