Does the term agile planning seem to be an oxymoron? Do agile teams really spend time planning? Well, actually they do. And the fact may be that agile teams actually spend more time planning than non-agile teams. OK, if agile teams indeed spend so much time planning, why isn't it evident like the planning done by traditional/non-agile teams? There’s a difference. And the difference is in the “when” of planning. Traditional teams focus on doing almost all of their planning upfront. Planning, or rather complete planning often precedes the “doing” in a traditional model. And by “doing” I mean the actual activities resulting in producing deliverables required by your customer. Contrast this with agile teams, wherein planning occurs throughout the project. So, how does this work?
At a fundamental level, agile planning acknowledges the existence of unknowns.
The upfront planning in agile is done based on what is known while acknowledging the existence of unknowns. With this limited upfront plan, agile teams jump right in to the “doing”. This approach enables agile teams to gather new information as they produce which in turn contributes to reducing the unknowns. New information gathered is used to revise plans. Agile planning is a flexible exercise that embraces adaptation of plans through the project as newer information is obtained and unknowns are progressively reduced.
Are unknowns important? Wouldn't an exhaustive upfront planning exercise clarify any and all unknowns? When we do not acknowledge unknowns we assume that the requirements available at the start of the project are complete and accurate, we (and our customers) know exactly what is needed and customers will not want any changes to defined requirements or add any other requirements. Even if we were to assume that the requirements are truly final, do we really know everything required at the start of a project to prepare a plan that need not/should not revised? Agile planning strives to iteratively and progressively reduce unknowns.
Agile planning is an iterative process of planning, followed by execution, (re)planning again while adapting to any new knowledge gained, then followed again by execution, and so on. In each iteration a working artifact is generally available to "show" customers or product owners (the ones who provided the requirements). Iterative planning enables clarifying any incorrect assumptions or estimates made earlier.
Another aspect of agile planning is the focus on delivering features rather than just completing a checklist of activities. This enables bringing together multiple functions to collaborate in pursuit of delivering a feature or set of features in each iteration. An impediment in any area tends to impact everyone else and hence there is the joint effort in speedy resolution.
Each level of the onion contributes to defining goals, setting time frames, ownership and resourcing for the level below. Agile teams are generally involved with Release, Iteration and Daily planning.
A release represents a set of user stories/prioritized features to be produced and delivered as part of a new release. Release planning sets the high level goals for the release, time line, scope and resourcing. A release progresses through one or more iterations.
Iteration level planning looks at the stories/features to be delivered in each iteration (typically of 2-4 weeks duration). Daily planning looks at activities to be performed each day in pursuit of the goals for the iteration. Agile teams generally meet for a short stand-up meeting every day to discuss tasks performed during the previous day, tasks planned for the day and bring up any impediments that may be affecting their work. The other three levels - Strategy, Portfolio and Product are generally owned by Senior Management and Product Management.
Agile planning is about simplicity and flexibility. Flexibility to adapt to changing requirements and make needed course corrections in the plan. Does this flexibility mean that agile teams cannot commit to delivery dates? No. Agile teams are capable of providing realistic completion dates and actually meet them. When plans are changed, dates do not necessarily have to be changed. Changing scope of features, dropping non-essential or lower priority features, adding resources, etc. may be resorted to for maintaining dates.