Failing to Plan is Planning to Fail: Succeed with Agile Planning Framework and its Four Planning Levels

Many people know that agile planning is different from big up/front detailed planning done in traditional or waterfall projects.  However, there are many misconceptions or only partial understandings of agile planning. In this first blog post in a series of six, I will begin to explain the details of agile planning: what and why, and multi/level planning and its benefits. What is Agile Planning? Some people equate agile planning with minimal planning or just/in/time planning or “fluid” or “adaptive” planning or planning to be done by the whole team not managers – all these characterizations cover only some aspects of agile planning.  Agile planning is more involved, more disciplined, and rigorous than what some people think. If done right, agile planning requires modest time and effort. This planning effort should not be viewed as an overhead, or a chore to be done by “agile project managers”. Planning is part of the overall work. If you don’t plan or plan poorly, no amount of execution effort would adequately compensate for poor agile planning. “Winging” an agile plan is expensive and doesn’t work well. As Benjamin Franklin said, “If you fail to plan, you are planning to fail!” The Agile Planning Framework is based on multiple levels of planning / typically four levels / as illustrated in Figure 1.

• Level 1: Product vision and strategy planning – this is the top level of planning
• Level 2: Release planning
• Level 3: Sprint planning
• Level 4: Daily planning and daily Scrums – this is the bottom level of planning

Figure 1 also illustrates the key goals at each of four planning levels.  Each level of planning is elaborated and supported by the next lower level of planning at smaller planning units, but with greater details (elaboration) and on a shorter planning time horizon, as will be explained soon.  Figure 1 is based on a popular poster from VersionOne that you may download for your use.

Figure 1: Four Levels of Agile Planning

The Three Agile Planning Roles Note that these are roles, and not necessarily three distinct sets of people.  Many planners also implement the plan, and many implementers are involved in planning.  In many organizations, the same person may play one or more of these roles. A sprint planner could be a team member doing his/her Daily planning and may also be a release planner. A release planner could also play the role of an agile champion. A software architect could be a team member, sprint planner, release planner, product vision and strategy planner, and agile champion. Each team member is a daily planner and is expected to work and deliver on that daily plan. 1. Agile champions: Agile champions are responsible for implementing, maintaining and improving an organization’s customized agile planning playbook by briefly and effectively documenting the agile planning process at each level as well as evangelizing and teaching the planning process to agile planners. The champions also revise and improve the agile planning playbook based on the feedback from agile planners, agile team members, as well as changing market conditions, competitive response, business conditions, technology changes, etc. These agile champions are the owners of your agile planning playbook. They may be senior executives or senior managers responsible for your organization’s agile transformation. They could also come from your enterprise’s agile Project Management Office (PMO) or they may be a group of enthusiastic and committed ScrumMasters if the agile initiative is started at the team level. 2. Agile planners: Agile planners are responsible for following the agile planning playbook to conduct planning and do re/planning as is necessary. An agile plan needs to be revised and adjusted at an appropriate frequency (based on the agile planning level) based on the feedback from agile team members, stakeholders, and also from the environment, as explained below. Agile planners work with the appropriate stakeholders to seek their input, guidance and expertise in the planning process. 3. Agile team members: Agile team members are responsible for day/to/day work of developing, delivering, deploying, operationalizing and supporting agile project deliverables after each sprint and release cycle. This day/to/day work is driven by agile plans developed by the planners at each level. These self/organized team members should have cross/functional expertise in areas of analysis, software design, user experience design, code development, testing, technical writing, data center deployment and operations, etc. Note that agile team members are not only daily planners, but also sprint planners; some of them may participate in release planning, and some may be called upon to help in product vision and strategy planning. The Four Guidelines for Agile Planning 1. Plan and elaborate progressively at each planning level: Planning done at each level is a pre/requisite for the next lower level of planning. It serves as the context and guides planning at the next lower level.  Product vision and strategy planning (Level 1) should proceed in the context of completed planning at the business vision and strategy done by senior C/level executives responsible for overall business; as this planning is related to the overall enterprise business, it is outside in the scope of this blog series.   Without a reasonable business vision and strategy in place, planning product vision and strategy is difficult and ineffective.  Release planning (Level 2) should proceed in the context of completed planning at the Product vision and strategy (Level 1).   Without a reasonable product vision and strategy in place, Release planning is very difficult.   Sprint planning (Level 3) should proceed in the context of completed release planning (Level 2).  Without a reasonable Release plan in place, Sprint planning could be difficult or at best tactical.  Daily planning and daily Scrums (Level 4) should proceed in the context of completed sprint planning (Level 3).  Without a reasonable sprint plan in place, daily planning is not very effective.  It is not advisable to plan at a level and then skip one or two levels to jump to a lower level; for example, starting at planning level 1, skipping Level 2, and jumping to Level 3 should be avoided. 2. Choose proper planning horizon, and granularity of planning and workflow monitoring at each level of planning: Planning time horizon should start with a typical 1 to 3 year range at Level 1 (product vision and strategy) and should shrink to a single workday at Level 4 (daily planning and daily Scrum). As planning time horizon shrinks, the granularity for planning and workflow monitoring should also shrink from “very large” (at Level 1) to “very small” (at Level 4). Level 1 – Product vision and strategy planning: Large to very large planning and workflow monitoring units, such as product goals and initiatives, strategic themes. These units are typically modeled as initiative epics and may take several months or release cycles to complete. Level 2 – Release planning: Moderate planning and workflow monitoring units, typically modelled as feature epics that can be completed in a single release cycle consisting of multiple sprints. Level 3 – Sprint planning: Small planning and workflow monitoring units, such as user stories and other work items (defects, spikes, regression test cases, etc.) that can be completed in a single sprint. Level 4: Daily planning and daily Scrum: Very small planning and workflow monitoring units which are SMART tasks that implement a story or a work item. A SMART task is completed typically in four hours or less in a single workday.  Acronym SMART stands for: S: Small, M: Measurable, A: Achievable, R: Realistic and T: Time/bound With longer time horizon, it makes sense to plan and monitor workflow at larger granularity of work. When planning horizon is long/term (Level 1 planning), working on small or medium/grain planning units (stories and epics) makes little sense as those small work items usually are not even known during Level 1 planning, and it would be a wasteful practice as many small work items will almost certainly change over time even if we spend effort to identify and model them during Level 1 planning. 3. Identify proper agile planners and stakeholders that must work together with commitment to required planning preparation and allocation of required planning time: Agile champions in your organization should identify the right planners and appropriate stakeholders at each level of planning, and those agile planners must work with the right stakeholders effectively. Agile planners must be well prepared and committed to attend all planning meetings and workshops with their quality time and focus without interruptions.  This often requires a cultural change in many organizations, and may need executive support and sustenance.  This also requires training of agile planners and stakeholders, and guidance by qualified coaches to conduct agile planning workshops at each level of planning. Product vision and strategy planners and their planning time: Executives work with Product manager and other appropriate stakeholders. Three to nine days of total planning effort is typically required depending on the product size, duration and complexity for a one to three year product horizon (240 workdays per year).  A product vision and strategy plan should be revised or fine/tuned at the end of each release cycle.  If you consider additional two to five days of effort to prepare for planning (Practice 1.2), and two to five days of effort to revise and maintain the Product Vision and Strategy Plan, it still amounts to only 3% of total time for planners at this planning level. Release planners and their planning time: Release manager, product owner, ScrumMaster and team leads work with managers and representatives of other related release teams (for large projects). Two to four days of planning effort is typically required for a three to six months release cycle (22 workdays per month).  A release plan should be revised at the end of each sprint cycle.   If you consider additional 0.5 to 1 day of effort to maintain and revise the release plan, it still amounts to a very modest 4% of total time for planners at this level of planning. Sprint planners and their planning time: The whole team (all its members) does planning and works with managers and representatives of other related teams (for large project). Four to eight hours of planning effort is typically required for a two/ to four/week sprint (five workdays per week). This amounts to a modest 5% of total time for planners at this level of planning. Daily planners and time for planning and attending Daily Scrums: Each team member plans his/her individual daily work, typically requiring 10 minutes of daily personal work planning effort.  This planning must be completed prior to each daily Scrum meeting which takes another “2n+5” minutes, where “n” is the number of team members in a team (see my blog series on how to make Daily Scrums Effective and Efficient); it takes two minutes for each team member to present his/her daily work plan and to report against the plan of the previous workday (tasks done or not done), and another five minutes for the team to review key metric such as the burn/down and burn/up reports.  Thus it takes 15 to 23 minutes per day (depending on the size of the team ranging from 5 to 9 cross/functional, self/organized team members) to conduct the daily Scrum meetings.  The total time to prepare the daily plan and attend the daily Scrum is 25 to 33 minutes.  This amounts to a modest 5% to 7% of total time for each team member. In future blogs of this blog series, I will present the details of the recommended schedule and cadence for the planning sessions at all four planning levels. 4. Define workflows at each level of planning and execution: Each higher level of planning sets the context and drives the work at lower levels of planning as illustrated in Figure 2.  Agile planners must define the workflow at each level of planning.  As shown in Figure 2, at Product Vision and Strategy planning level, work items are modeled as Initiative epics and they flow in sequential stages: Approve and Fund, Implement, Deployed, and Measure Return on Investment (ROI).   As an Initiative epic reaches Implement status, it signals that work can be initiated at the next lower level, i.e., Release planning level.  An Initiative epic gives rise to many Feature epics at the Release planning level; when a feature epic is broken down into stories and reaches the Build status, it signals that work can be initiated at the Sprint planning level.  When a user story reaches Development status in a sprint, its SMART tasks are pulled by individual team members to work on and their workflow is monitored on the Taskboard as part of Daily workflow.  When all tasks for a story are completed, the story is Accepted by Product Owner (assuming it passes all its acceptances tests), and gets Deployed.  When all stories for a Feature epic are Deployed, that Feature epic moves to Deployed status on Feature Epicboard.  When all Feature epics of an Initiative epic are Deployed, the Initiative epic moves to Deployed status on the Initiative Epicboard. Agile planners need to define policies for managing workflows at each level (rules for status transitions); and board/level policies, such as Work/in/Process (WIP) limits, cycle time thresholds, etc.   There is plenty of opportunities to customize the workflows, status columns, and policies at each level of planning.   I will explain the workflow at all four planning level in four future blogs of this blog series.

Figure 2: Customizable Workflows at Each Agile Planning Level

Agile Planning Playbook

As my colleague Mike McLaughlin explained in his agile playbook blog, an agile playbook is a helpful guide that briefly documents your agile process. I believe an agile lifecycle playbook should cover the entire value stream from product vision, strategy, analysis, design, development, testing, delivery, deployment, operations, support, and customer value realization. These are not sequential phases of work; often agile team members “swarm” to do many tasks concurrently and in close harmony, such as analysis, design, development, testing; and even deployment and operations as the DevOps movement proposes. An agile lifecycle playbook helps ensure consistency among projects and teams, improves their productivity and quality of work and reduces mistakes and errors. VersionOne’s 9^th Annual State of Agile™ survey has indicated that the consistent process and practices is the top tip for success in scaling agile.    You can and should start using your agile lifecycle playbook even with single teams and smaller projects to ensure consistency across successive sprints, and improve your playbook with on/going experience. An agile planning playbook focuses on agile planning aspects of the agile lifecycle, and is a part of the overall agile lifecycle playbook for your organization. Your agile planning playbook facilitates agile planning in a standard and consistent way across the whole enterprise or at least across a set of common projects or teams. There is no “one size fits all” agile planning playbook that suits all organizations. Consider these very different types of organizations.

• A relatively small company working on its next product over multiple release cycles with four agile teams consisting of a total of 35 members
• A large bank with portfolios of many projects consisting of 1,200 project members and developing software for in/house use
• An organization developing and operating a large e/Commerce service through Internet cloud
• A Department of Defense contractor developing a mission/critical system (hardware and embedded software) spanning five years of development cycle

Each organization, product, program or project, as well as teams and people and their practices, history and cultures are unique.  Therefore each organization or a division or a line of business will need a customized agile lifecycle playbook and agile planning playbook to serve its unique needs and business goals. However, agile planning needs of diverse organizations share a common core based on agile principles, values, and agile framework. The Agile Planning Framework is based on a common core of agile planning principles and practices.  The framework is common for all organizations interested in agile development. Your organization can develop one or more agile planning playbooks from the common framework by customizing and implementing it in ways that best serves your needs. Most of the material in this blog series is written with a focus on the lifecycle of software products or services or embedded software products that are intended for multiple customers in their chosen market segment.  With appropriate modifications, you can use this framework for a number of different situations, such as:

• Single client/specific custom software project
• An entrepreneurial start/up company with a lot of uncertainty
• Scaled agile environments where there may be many portfolios of programs and projects

I will explain how you can modify the Agile Planning Framework to suit these different situations throughout this blog series.