Knowledge Base / Why Scrum? / Waste reduction
Plan using only as much detail as possible
Traditional methods seek to plan, at the beginning of a project, all the work that needs to be done to develop the product (or, at least, the next delivery), with a high level of detail. The plans thus generated often describe each of the product’s features, who will produce them and when they will be produced. The result is that these plans, in general, do not translate into a future reality.
While Scrum does not have this initial detailed planning phase, that doesn’t mean the product can’t be described from start to finish. However, the basic principle here is that we only plan with the level of detail that we can see and do so with high frequency.
With Scrum, we use a goal or a vision of a product that represents, at a high level, the problem to be solved based on the use of the product. To realize this goal, we can perhaps define a high-level plan that breaks it down. Such a plan can establish the main business goals to be carried out in each delivery, for example, and envisage approximately when this will occur. For the work to be accomplished by the next delivery, we can create a plan with the likely work to be done and the next business goal to be carried out after that work, which is an increment to achieving the product’s goal. For each product development cycle of a team, its members plan in detail what work they will do in that cycle and how they will do it, aiming to realize a business goal, which in turn is an increment to the realization of the goal established for delivery.
Except for the current cycle plan, which already has a finer degree of granularity, these plans are frequently modified in order to reflect the reality that presents itself at each moment. This behavior is best demonstrated by the horizon analogy.
Definition: horizon analogy
Let’s say you are looking at a city and you can see the buildings, cars and people that are closest to you until what is on the distant horizon.
By looking at what is closest, you can describe what you see with an excellent level of detail and fine granularity – that is, with small pieces of information. What is a little further away, you can still describe with a good level of detail, albeit less, and with somewhat coarser granularity.
But as you look further and further away, the details that you can use in your description gradually become less and the granularity gets coarser and coarser. If you were then to try and describe everything you see with a high level of detail all the way to the horizon, your description would certainly not correspond to the reality, and you would be quite wrong. The further away you look, the more incorrect your detailed description will be, and the greater the waste generated.
But if, on the contrary, you describe only what you really can see, with only as much detail as possible, then as you walk towards the horizon you can refine your description, adding details as you see them better, as well as reflect the changes that occurred during your journey.
A traditional plan usually describes in detail what will be done during the entire product development, or at least all the work until the next delivery, months ahead. It is very common to see these plans described in Gantt charts, which show detailed tasks and the allocation of “resources” over time.
This practice can be likened to describing the entire journey in detail, from what is closest to you to what is nearest to the horizon. The result is a very high precision plan – that is, detailed –, but with a very low chance of being correct, leading to a significant generation of waste.
By using Scrum, we only plan with as much detail as we can see. To plan a job that needs to be done, for example, by the next day, we can use a very high level of detail and very fine granularity. For the next two weeks of work – a product development cycle, for example – we can use a still reasonably high level of detail, but less than the detail for just one day.
In turn, when planning a delivery to be done in several weeks or when planning an entire six months of work, the further we look in time the number of details decreases and the granularity becomes coarser, so that very little information can be used to plan what is further away. As product development progresses through time, this plan is refined and more details are gradually added, as well as reflecting on changes that may occur along the way.
Plans with items to be developed by a team or teams in Scrum reflect this form of planning. The items at the top of this list, called the Product Backlog, have a finer granularity. That is, they are smaller items that represent more details. As we go down the list, the items get bigger and with less detail. Having more details than what is necessary and sufficient means the generation of waste.
In other words, we don’t work with a detailed scope from the beginning of the product development work. And this is a basic principle of Scrum. The very short-term scope is sufficiently detailed to be developed. The short-term scope, on the other hand, receives a slightly lower level of detail, and if it is necessary to detail the medium and long-term scopes, they will have even less detail the further away in time they are.