I recently read an article that suggested, “The ability to focus on a subject or a task and the ability to give something or someone your full attention are the new currencies of effectiveness.” Focus requires the ability to work on a single idea, a single task or a single project to completion. Focus requires your full attention. However, in order to give something your focus and your attention, you necessarily have to take your focus and your attention away from everything else. The ability to unplug from the noise and focus on the important is a defining attribute of successful teams, especially in project work.

Planning Horizons
One of the deterrents to focus is too much work in process (WIP), because it creates distractions to the important work that should be getting done. One way to manage the WIP and also gain focus is through the use of multiple planning horizons. I was first introduced to this concept in lean manufacturing (like a number of other agile principles). If you are a list maker, you probably use planning horizons today without realizing it.
A planning horizon is a view of work, bound by time, under which it is realistic and defensible to forecast when work is going to be done. Appropriately detailed work planning is then done within that time window. In general, the length of each planning horizon is dictated by the degree of uncertainty and the level of commitment to completing the work. The shorter the planning horizon, the higher the certainty, and therefore the higher the commitment to completing the work as planned. Planning horizons help the team and the individual team members direct and maintain their focus commensurate with the timeframe in which the work is planned to be done.

Planning Horizons in Agile — Backlogs
Agile methodologies are typically used on projects that have a high degree of overall uncertainty. On these projects, it is rarely reasonable or advisable to plan out the whole project in detail. Doing so would limit the possibilities and not invite the emergence necessary for creativity. In agile projects, uncertainty is leveraged, not controlled, allowing requirements to change and emerge to deliver the greatest business value.

“Agile projects plan more and plan more often, but that planning is iterative.”

Unfortunately, this acceptance of uncertainty often leads to the misconception that agile projects are not planned. The truth is, agile projects plan more and plan more often, but that planning is iterative. Continuous progressive elaboration of the plan would be a traditional term for it. As work moves into a closer planning horizon, the work and associated plan is revised to meet reality. What agile doesn’t do is plan when the exercise of planning is just to create a façade of certainty. Instead, they seek clarity for better planning.
Agile deals with the various levels of uncertainty through the use of multiple planning horizons. The work in each planning horizon is associated with a specific backlog or work queue and is primarily constrained by team capacity or velocity. Scrum uses four primary planning horizons designed to support and provide a level of planning that is appropriate for the certainty of the work and the priority of the anticipated business value. These are:

• Daily Backlog: This work queue addresses the past 24 hours and the next 24 hours and typically should have the least amount of uncertainty. This is managed individually by each team member and shared via the daily stand-up meetings.
• Sprint Backlog: This is the view of the tactical horizon, measured in weeks with an acceptable level of uncertainty. Work in this queue is managed through the Burndown/Earn-Up chart, showing transparency to commitments.
• Release Backlog: This is the Product or Project horizon, often used in conjunction with a roadmap. It provides a longer view of work based on the business/consumer wants and expectations.
• Product Backlog: This is both the strategic horizon and the idea incubation work queue. Unlike the other backlogs, this one is not constrained by capacity. It is an open container for work that could be done.

Each backlog is not technically a separate queue, but rather a prioritized subset of the queue below it. As each work item becomes better understood through the process of grooming and refinement, it progresses to a higher queue/backlog and receives the appropriate level of consideration and planning. This focus on the right work at the right time, but not before, reduces the WIP and increases throughput.

Estimating by Planning Horizons
In most organizations, it is almost impossible to start a project without a plan. For most executives, this means a time and budget commitment based on foggy outcomes outlining who is going to do what, when, to produce what, so they can hold everyone accountable to it. The goal here is to give the false impression that you have everything under control and success is guaranteed.
With each piece of work needing to be estimated to produce a budget and schedule, the temptation is to plan out the entire project giving each body of work the same level of scrutiny. There is only one planning horizon, the end of the project. It makes sense that estimates can only be accurately done once all requirements are known and stable. However, the farther out the planning horizon is, the more unrealistic this exercise becomes. So, the only seemingly logical solution is to do more requirements definition to improve the estimates. This negative spiral of analysis delivers zero business value and is rarely any more accurate than pulling numbers out of … wherever.
With different planning horizons, detailed estimating can be done for the more near-term horizons (daily and Sprint backlog) where the work is better understood and only relatively sized for work farther out (release backlog). Beyond that horizon, work may not be estimate or sized at all, since to do so would provide little if any meaningful benefit.
I was recently on a project to select and implement a commercial off-the-shelf system. Though the software package had not yet been selected, we were asked to provide a plan with estimates (in hours) for the effort to implement it. Our work would potentially be 6-9 months beyond the point of selection. The desire for prediction far outweighed any rational thinking. Begrudgingly, we inflated our estimates to account for the uncertainty. What else could we do?

Chasing the Horizon
The moral of the story is, don’t plan beyond what you can realistically understand; then get comfortable with the uncertainty. As time moves on and the project progresses, what was once on the horizon will be closer and in better view and a new horizon will be established. Stay focused on the tasks at hand and limit the WIP and you will find greater comfort with the uncertainty and higher throughput for the team.
Next month my wife and I will travel to Europe for 10 days with our youngest daughter Erika and her boyfriend. Other than the cities we will visit and the rooms where we will stay, we have made no plans. We have done some research and are not without ideas for what we would like to do, but the daily plan will be decided when that horizon is closer. Even then, I suspect it will change as new and unexpected opportunities present themselves.
The beauty is that you never know what is over the next horizon. And that is something I look forward to.