Agile Product Planning

During my work as agile coach and in the Agile and scrum workshops I have provided, I heard many, many times that Agile does not take planning into account. I have overheard many conversations like: “could you please tell me when feature x y z will be delivered?” “No, sorry we are working Agile you know, we don’t do a traditional product planning anymore” Interestingly this statement could not be farther from the truth. Agile has actually many levels of planning. In fact, it has at least six levels of planning. Within the agile methodology a lot more planning and risk mitigation is done, than in traditional project management processes, like waterfall. Agile focuses on planning very often instead of doing comprehensive and assumption based planning only once in the beginning of the project.

When we look at the planning processes within an agile or scrum project we can see that the product owner is responsible for planning the product. The product owner is the business owner and he or she will give guidance to the team, as in what needs to be delivered. The product owner plans the product in layers.  There are different way to show how these layers of planning work together. The “planning onion” is a commonly used example to explain how a product owner plans his or her product.

Most agile or scrum teams are concerned only with the three innermost levels of the planning onion. Release planning considers the user stories or themes that will be developed for a new release of a product or system. The goal of release planning is to determine an appropriate answer to the questions of scope, schedule, and resources for a project. Release planning occurs at the start of a project but is not an isolated effort. A good release plan is updated throughout the project (usually at the start of each iteration) so that it always reflects the current expectations about what will be included in the release.

At the next level is iteration planning, which is conducted at the start of each iteration. Based on the work accomplished in the just-finished iteration, the product owner identifies high-priority work the team should address in the new iteration. Because we are looking at a closer horizon than with release planning, the components of the iteration plan can be smaller. During iteration planning, we talk about the tasks that will be needed to transform a feature request into working and tested software.

Finally, there is daily planning. Most agile or scrum teams use some form of daily stand-up meeting to coordinate work and synchronise daily efforts. Although it may seem excessive to consider this planning in the formal sense, teams definitely make, assess, and revise their plans during these meetings. During their daily meetings, teams constrain the planning horizon to be no further away than the next day, when they will meet again. Because of this, they focus on the planning of tasks and on coordinating the individual activities that lead up to the completion of a task.

By planning across these three time horizons: release, iteration, and day, the agile teams focuses on what is visible and important to the plan they are creating.

In bigger organisations there will be most likely more layers of the onion used. With the implementation of so called Program Management and Product portfolios also the appropriate layers of program and portfolio planning can be added to the onion.

These program and portfolio planning layers are usually outside the concern of most individual agile teams.  Product planning involves a product owner’s looking further ahead than the immediate release and planning for the evolution of the released product or system. Portfolio planning involves the selection of the products that will best implement a vision established through an organisation’s strategic planning.”

As you can see agile planning consists multiple levels of constant planning so you can now explain to your managers all of levels to them calm down, that within agile or scrum planning is even taken more serious than it has ever been.

Final conclusion, agile and scrum teams are only concerned until planning the release. The rest of the planning levels is far away and will be in the capable hands of the (NoNonsense) Product Owner.