The essence of Agile planning is to work continuously on product development at five well-defined strategic levels.
”We’ve thought it all through, we’ve planned it all, and here’s the specification we’ve written. There is no need to think, it just needs to be made.” – This approach goes against Agile in every aspect.
The ultimate goal of Agile product development is to continuously maximize business value.
This latter is loved by everyone.
What no one likes, and Agile is no exception, is the unnecessary prolongation of tasks.
To maximize business value, we shall be able and willing to respond to the changes of the business environment at every stage of development. We shall be able to incorporate the latest information and knowledge into the product. This requires that, at all levels of design, in all phases of product development, we are constantly thinking (i.e. planning) about whether our current idea is the most valuable one or not, or whether there is a more useful task to be developed, or a concept to be validated.
If the answer to any of these is yes, it is worth including it in the development. Of course, this does not mean that we can rush! If we start something, it is usually worth finishing it at least at a minimum level of market readiness.
The five levels
- Product Vision: the future state of the product, that we wish to achieve
- Product Roadmap: the path along which the product is created, the business logic of the main milestones
- Release: a larger business logic unit which includes a few sprints
- Iteration: Iteration, which means one sprint in scrum teams
- Daily Planning: the daily level of coordination and planning, where we strive to get the maximum amount of work done by the end of the day according to the definition of done
I also want to be a Scrum Master!
The importance of the five-level breakdown
The breakdown into five levels of planning is very helpful for the different actors in the organizational hierarchy. It means that not everyone in a project needs to be aware of everything in order to make decisions according to their own hierarchical level.
Critical managerial involvement is often hampered because there is too much unnecessary information to process to make a well-founded decision.
The product vision
The product vision is an artifact with genre-specific features and rules, which must be established in order for projects to be comparable with each other.
The detailed rules of the product vision will be explained in another blog post. For now, it is enough to know how and what it will be good for. The benefit of a product vision is that it answers business questions about the product itself, such as “why it is important” and “how will it be profitable”. Product Visions are extremely short, they usually fit on one A4 page. By placing several product visions side by side, they allow the strategic level to decide which products to focus on and which not to focus on. Not wanting to focus on something at the moment doesn’t mean we’ve thrown it away. It only means that we will do it later.
We did a good job if we could rank the projects according to some criteria. This helps prioritization at portfolio level.
Product roadmap, the path
The Roadmap comes when we have decided, at least at a strategic level, that we want to deliver the project. The Product Roadmap describes how, and in what major steps we will do that. It is a classic artifact. However, with an Agile approach, it does not need to be too detailed. We need to write the Roadmap loosely enough to be able to adjust the priorities within the project. If we get rigid here, we effectively turn our operation into a Waterfall-type task, which means we will not be able to maximize business value.
The Roadmap provides a convenient opportunity for management to intervene. On lower stages of planning, the strategic level no longer needs to be involved in the development of a product. At this point, Roadmap-level reporting is usually enough: the entire project is green or red.
Release
The Roadmap is followed by the Release. The Release should already include detailed technology and business logic planning. In a Release, many things need to be clarified in detail. What features will be needed, how they will depend on each other, when we can consider it done… To name a few. These are questions that require the help of a Product Owner and an architect.
Be careful! It is rare to have real Product Owners in an organization! Especially competent ones! Properly, it will be the Product Owner who, having sufficient knowledge of the product, the business logic and the domain, will be able to make decisions on an ongoing basis about how the priorities and product details will evolve at the Roadmap level and the derived planning levels.
The Product Owner’s task is especially difficult, because they have to see and understand all planning levels. They shall manage stakeholders at all planning levels.
Release planning is team-oriented. The Product Owner informs the Roadmap or above levels about the expected content, cost and resource requirements of the Release. But the decisions shall be made by the Product Owner, with the obligation to inform.
Iteration (sprint, in the scrum team)
The planning of Sprints is also worth a separate blog post and will be covered. All we need to know here is that the planning of sprints shall be done with the involvement of the team. That’s the least.
The Product Owner should be there at all times, as it is their responsibility to fill the backlog, which is the source of Sprint planning, and should be available to answer questions from the delivery team during the planning. The Product Owner is the person who can make decisions on the product side. However, the team decides and plans “how to create it”.
Daily coordination
Daily Coordination is the planning event where team members, who are definitely needed to work together on a particular product at a particular moment, discuss the main steps for the next 24 hours. What, how and why will be done by whom, and this must be understood by the team members involved. They do this in order to coordinate their activities and, as a result, to increase the daily value delivery.
Which level to focus on?
Of course, planning should be done at all levels. And at each level, we need to continuously improve our processes in order to have better products with more sustainable operations.
The people concerned shall be able to move between the planning levels. The levels may not be organized into silos or hermetically separated into departments. The five levels of Agile planning work if and only if, in the spirit of the agilemanifesto.org, knowledge, information and people are free to move in order to reach the business objectives and project goals.
