Agile Project Planning

Agile planning should be simple. Agile embraces flexibility, adaptability, and incremental delivery. Therefore, planning processes are designed to be lightweight and time-efficient.

Many organizations struggle with Agile planning. Remnants of the predictive project mindset are often the culprits. The result is impractical plans, wasted effort, and compromised value.

Applying Agile planning principles and practices correctly will reduce the time and effort spent on project planning, offer greater flexibility, and result in more realistic plans and projections of remaining work.

Predictive Project Planning

Predictive projects are plan-driven. As the adage states, “Plan the work, and work the plan.” It is assumed that at the beginning of the project, the scope can be clearly defined, task durations can be reasonably established, and activity dependencies are relatively fixed. This leads to the formation of the Triple Constraint: the delivered scope is a function of the time and resources (cost) expended.

Conventional wisdom asserts that predictive planning is effective for large engineering and construction projects. However, the data shows otherwise. According to Dodge Data & Analytics [1], 61% of these projects are late. Large software projects report similar results. McKinsey [2] reports that 66% of these projects have budget overruns. These findings align with research from the Project Management Institute (PMI) [3] and the Standish Group [4].

Agile Project Planning

Agile takes a fundamentally different approach to planning. It acknowledges that scope is emergent and favors long-standing, stable teams, which simplifies resource planning and cost estimating. Agile inverts the Triple Constraint [5]. Total project costs and duration can be determined based on the investment's economics, thus allowing the scope to fit within those constraints.

The case for an emergent scope is strong. Between 64% and 80% of software features [6] are rarely or never used. So, fitting scope into a time- and cost-bound box reduces wasted effort.

Incremental and iterative delivery establishes new and liberating expectations. Incremental delivery ensures that new functionality is delivered quickly with a predictable cadence, typically every two weeks. Iteration allows the solution to evolve and be enhanced based on feedback.

The product backlog drives planning. It is a consolidated list of all desired features and capabilities, including new user functionality and technical updates. An ordinal ranking (1, 2, 3, etc.) system is used, making prioritization trade-offs explicit and transparent.

Iterative planning promotes just-in-time decision-making. Stakeholders can adjust their priorities in response to external factors, such as market changes, competition, technical considerations, or customer feedback. Development teams avoid over-planning by focusing on immediate tasks and avoiding future items that may never be needed.

Both stakeholders and development teams regularly review the product backlog. Stakeholders verify and adjust the product backlog to align with current priorities. Development teams review, decompose, and estimate the size of items as they move up the backlog.

Items at the top of the product backlog should be small and well-defined. Items lower on the list can be larger and require further refinement. Items ready to be worked should be small enough to be delivered within a few days.

Scrum and Kanban are the two most common Agile frameworks. Scrum delivers value in fixed duration increments, whereas Kanban is a flow-based approach. Both share the benefits of Agile planning. The primary differences are cadence and timing.

Scrum Planning

Scrum teams deliver consumable solutions with every sprint or iteration. Sprints are typically 2 weeks long. This cadence-based cycle enables iterative planning. Rather than planning an entire project, teams progressively plan upcoming iterations.

The sprint planning meeting occurs on the iteration's first day to determine what can be accomplished. The team estimates its capacity—the amount of work can be completed. It reviews estimates for top product backlog items, moving them to the sprint backlog until capacity is filled. A sprint goal is established, and teams commit to delivering it or items in the sprint backlog.

Story points are used to estimate work items and the team’s capacity. They serve as a composite score that reflects the effort, risk, and complexity involved in delivering an item. They are unique to each team; estimation consistency enhances planning accuracy. Story points should not be conflated with effort hours or similar measures.

This relative sizing scale is based on the Fibonacci sequence (1, 2, 3, 5, 8, 13, etc.). The widening intervals indicate that estimating smaller items is easier and more accurate than larger ones. In other words, it's simpler to predict what can be accomplished in a day than in a week or a month.

Teams estimate their capacity—the projected volume of work for the upcoming sprint—based on past performance and known adjustments such as holidays, vacations, or expected unplanned work. For example, if a 5-person team typically delivers 45 story points of work every 2 weeks (9 working days x 5 people x 1 point per day). The upcoming iteration may include a holiday, so the team would only be able to deliver 40 points.

Planning Poker and affinity sizing techniques are commonly used for quick estimation. Both practices draw on individual expertise and group wisdom to produce unbiased estimates. In Planning Poker, team members estimate the story points for an item individually, compare their estimates, discuss differences, and achieve consensus. Affinity estimates rely on T-shirt sizing, using Fibonacci points linked with each category.

Estimation consistency and predictability are more important than precision. The objective is to deliver the sprint goal(s) or items from the backlog dependably. This establishes credibility with stakeholders and enables the prediction of future work delivery with reasonable accuracy.

Kanban Planning

Kanban is a collection of workflow management principles and practices that can be applied to project work. Kanban fosters process transparency, highlighting bottlenecks and other issues. It facilitates the even and continuous delivery of value by limiting multitasking, building quality in, and only initiating new work when capacity is available.

Teams take items from the top of the product backlog and work them through the development process. Work is generally released to production on a regular cycle based on business needs.

Kanban planning is straightforward. Teams are generally long-standing and stable, which makes cost estimation easier. With a consistent velocity, it is easy to forecast the number of items that can be delivered daily, weekly, or monthly.

The product backlog plays a critical role, just as it does for Scrum. Work is prioritized and can be adjusted. As work progresses through the backlog, it should be refined and broken down into smaller units. Items at the top of the backlog should be small enough to be completed within a few days. Consistency sizing makes it easier to estimate the team’s velocity.

A primary difference between Scrum and Kanban planning is that Kanban is not constrained by a cadence-based development cycle. Consequently, iteration planning is unnecessary. Teams work their way down the prioritized backlog. Therefore, they do not need to estimate story size or sprint capacity.

See related articles:

To learn more about our training and consulting services or subscribe to our newsletter, visit our website: http://www.pmessentials.us/ [9].

Image generated by ChatGPT

Watch the trailer: https://youtu.be/QRJhfGmkLd8 [10]