Imagine this scenario: you’re out in the street watching the city in front of you. Buildings, cars, people and other things are distributed from where you are standing to the distant horizon. To describe what you see, what level of detail can you use in your description? Now imagine your next software development project. When you plan it from the very beginning until, let’s say, six months from now, what level of detail can you use in your planning?
In the city, you can look at what is closer to you and describe it in excellent detail. However, as you look farther away, the details you can use in your description will decrease gradually. If you try to describe what is far away in great detail, as you walk toward the horizon you will see that your description doesn’t entirely reflect reality. In fact, the farther away you are looking, the more inaccurate your description will be, if it is detailed.
Traditional planning usually attempts to describe in detail what will be done during the entire project, or at least all the work required until the next delivery, for instance. It’s very common to see these plans described in Gantt graphs, which show tiny tasks and allotted “resources” over time. This practice can be compared to describing all of a long path in detail, from what is closest to you to what is farthest on the horizon – thus, in a lot more detail than is actually possible. The result of this practice is a plan with a very small chance of success. What’s the point of a plan like this?
Agile Planning
In Agile planning, we use only the level of detail we can “see”. To plan work to be done by the following day, for instance, we can use a very high level of detail – that is, describing each small task to be performed. For the two following weeks – one development cycle, for instance – we can use a level of detail that is still reasonably high, but lower than for only one day.
When planning a delivery that will happen two months from now, or even in one full year of the project, the amount of detail decreases as we look farther ahead in time, using very few details to plan what is further down the line.
Scrum’s list of business needs, called Product Backlog, reflects this Agile planning. The top of the Product Backlog includes items with finer granularity, i.e., smaller items representing more detail. As we look down the Product Backlog, we can see that the items become bigger and less detailed.
As the project moves in time, the Product Backlog items must be continuously refined in more and more detail, reflecting only what we can “see” at each given moment.
Read more:
Controversy: Can the Product Owner participate in the Retrospective?
How detailed should the backlog be?
Daily Scrum – Myths and Facts
Upcoming training:
Certified Scrum Master (CSM)
Certified Scrum Product Owner (CSPO)
