How to Improve Your Planning Accuracy on Short-Term and Long-Term

When businesses develop software, meticulous planning is essential. Modern businesses tend to use [agile methodologies](https://www.agilealliance.org/agile101/) when developing software, which emphasizes continuous, incremental planning rather than front-loading all the planning, as seen in waterfall development. This iterative approach helps the team understand the volume of work, requirements, dependencies, and budget constraints for the project.

‍

Good planning creates a virtuous cycle, enhancing project efficiency and increasing the likelihood of success. However, inaccurate planning can lead to significant issues. Repeated planning errors can create a vicious cycle, leading to systemic issues and threatening to derail the project. Inaccurate planning obscures the volume of work, making estimates unreliable and preventing stakeholders from making informed decisions. This often results in compromised project timelines and budgets, forcing businesses to either expand their budgets or reduce project scope. Ultimately, these issues can severely impact team morale as persistent delays and unmet expectations erode productivity and enthusiasm.

‍

This guide will show you how understanding the factors that contribute to inaccurate planning  can mitigate these risks. It will also equip you with the terminology, techniques, and tools to conduct regular, accurate planning sessions.

‍

Where Does Inaccuracy Come From?

Several factors can contribute to inaccuracies in planning. Scope creep occurs when the project's scope expands uncontrollably beyond the original requirements without adjustments to time and budget. This happens when new requirements are discovered during development and added to the current work instead of being scheduled for future iterations. This unplanned addition increases the workload without formal acknowledgment, leading to longer completion times and planning inaccuracies. Changing requirements, on the other hand, are managed modifications to the original scope that go through planning and refinement before being picked up in subsequent iterations. However, if new work is scheduled within the current quarter without a buffer, it can lead to either de-scoping other tasks or absorbing additional work, both of which negatively impact timelines, budgets, and morale.

‍

Unplanned work, such as surprise feature requests and urgent bug fixes, also affects planning accuracy. While responding to these is important, it requires an "unplanned work buffer" based on historical data to maintain planning accuracy. Without this buffer, unplanned work can disrupt schedules, similar to scope creep and changing requirements. Regardless of the source, any form of new work that was not originally accounted for also runs the risk of slowing things down further—beyond their "on paper" time cost—due to the detrimental effects of context switching.

‍

Finally, much planning inaccuracy can stem from unrealistic estimates. If the team lacks a refined estimation process, their guesses can compromise the entire planning process. Improving estimation skills over time is crucial to producing reliable planning outputs.

‍

Estimation Techniques

Estimates are the logical place to start when trying to improve your planning accuracy; they are measurable representations of work to be done and the foundation of most other aspects of the planning process.

‍

Several different techniques can be used to estimate units of work—or "tickets"—in software projects. The specifics of each make them suitable for different types of teams and projects.

‍

Story Points

Story points are a common framework for estimating tickets. They are _subjective_ measurements of _effort_ relative to other tickets in the project rather than absolute measurements. This means that two tickets of the same size in a given project should be roughly comparable in effort to implement. Because they are relative to the project and the team, they cannot be compared to estimates given to tickets from other teams and projects as the baseline used to estimate the points will be different. This is notable if you want to track points between multiple teams because, from team to team, points carry different weights, meaning that you cannot meaningfully compare velocities and estimates across teams.

‍

One common tactic for teams who use story points is to restrict the possible point designations to Fibonacci numbers, with 1 being the smallest valid story size, followed by 2, 3, 5, 8, and so on. When done this way, story points are more exponential than linear, with a 5 being "5 times the effort of a 1" rather than a discrete, linear incremental increase from a 3. This adds some degree of standardization to the values used for the estimates, but the actual "size" of a 1-point story is still defined by the team in question.

‍

Function Points

Function points are _standardized objective_ units that seek to provide a quantifiable measure of the _complexity_ of a piece of software. They consider "functions" like inputs, outputs, user interactions, files, and other well-known patterns. A function point estimate will be a number that is calculated by counting the number and kind of "functions" in an application and multiplying the count of each kind of function by a standardized weight.

‍

Function points may be preferable in environments where standardization is necessary, such as when you want to track and compare the workloads of different teams and projects.

‍

T-shirt Sizes

The "T-shirt sizes" approach is similar to story points in that it uses _relative_ units. Typically, acceptable values for T-shirt sizes will be things like _xs_, _s_, _m_, _l_, and _xl_, with each value representing a rough measure of _complexity and effort_ determined through team consensus. T-shirt sizes are more abstract and lower resolution than story points and function points and are often used for rough, high-level estimates to get an idea of the volume of work before subsequent refinements are done using another system that provides better granularity at the cost of more involved estimation sessions.

‍

Strategies to Improve Your Planning Accuracy

To ensure the best level of accuracy when using these techniques in your planning sessions, consider the following strategies.

‍

Involve the Whole Team

When doing estimation sessions, you  must involve as much of the team as possible—ideally, the whole team. One anti-pattern that some teams fall into is only getting estimations from the team members who are expected to be doing the work at implementation time. There are several issues with this:

‍

• Fewer minds: Excluding team members from estimation sessions risks missing valuable insights and context, potentially delaying the identification of issues.
• Knowledge silos: Estimation sessions create an important context for implementation, but if only a few people have this information, when one of them becomes unavailable, others may lack the vital context and need to pick up the work.
• Reduced buy-in: Excluding team members from refinement sessions can lead to a lack of ownership and commitment to the project, as those not involved may feel their input is undervalued or ignored.

‍

To help gather estimates from the team, you can consider techniques like "planning poker." In this technique, each team member will select a card representing their estimation of how big a piece of work is (often using one of the systems described above). Simultaneously, all team members will reveal their cards. Discrepancies will lead to discussions until a consensus can be reached. This technique has the benefit of keeping people's estimates hidden until they are all revealed, which can prevent issues such as a single person suggesting an estimate early and other people simply agreeing rather than thinking about it for themselves, or everyone simply echoing the estimate of the most experienced team member. This also gives you an opportunity to dig into surprisingly high or low estimates. If one team member's estimate differs significantly, it could suggest that they either aren't comfortable with their understanding of the scope of the work or that they have context about the work that the rest of the team doesn't have or isn't considering.

‍

Keep Work in Progress to a Minimum

One common mistake that teams make is allowing work in progress (WIP) to spiral out of control. This happens when the team works on something until they reach a blocker—such as waiting for review or for action from some other party—at which point they pick up a new item and repeat the process. This seems reasonable at first; however, if you don't prioritize going back to those WIP items once they are unblocked, you can end up in a state where lots of work is getting done but nothing is getting finished. You can mitigate this by treating WIP items as high priority and focusing on finishing those tickets as soon as reasonably possible after they become unblocked.

‍

Have a Well-Known Reference

If you use a subjective system for estimation, such as _story points_, you should have a baseline from which to make your estimates. If you're using Fibonacci story points, for example, how do you know what a 1-point story or a 5-point story should be? An effective way to handle this is to form team consensus by finding examples of prior work that everyone agrees is representative of a given size. If you have a well-known reference for each ticket size that you can assign, during estimation, if the team is unable to assign a value to a story, you can ask, "Is this bigger than [reference 3-point story]?" and use the team's response to guide you to an estimate.

‍

Consider Historical Data

Having references for ticket sizes is helpful, but if you find that you are often developing similar kinds of modules, you can take this further. If each API endpoint you implement requires similar boilerplate work, the team should have a deep understanding of that work once they have done it several times. You should be able to refer to historical data to understand how long similar work will take. It is still worth performing estimations on these pieces of work as they may help catch hidden complexity that would otherwise be missed. However, suppose the team provides an estimate for a seemingly common piece of work that doesn't align with past estimates and actual delivery time frames. In that case, it may be worth investigating further to understand why.

‍

Break Work into Small Chunks

Although point-based systems allow for large estimates of 5, 8, or even 11 points (if you're using Fibonacci numbers), if you are getting estimates that are this large, it is a sign that you probably need to break the work down into smaller chunks and estimate them at your next refinement session. The larger a piece of work is, the more uncertainty it can carry. Large chunks of work also have a lower-estimate resolution, further obscuring timeline and budget suitability. Consider setting a soft rule with your team that anything larger than a five needs to be decomposed. This way, you keep your chunks of work smaller and more manageable, allowing them to be developed, reviewed, and merged faster. It also allows you to track the project's progress more frequently as tickets should move between statuses more often.

‍

Budget for the Unexpected

As you know, unplanned work, scope creep, and changing requirements can be leading causes of inaccurate planning. While these factors can be hard to eliminate, you can account for them in your long-term planning. One good strategy is to factor in some buffer time for unplanned work. This way, when these things arise, rather than eating into your carefully managed timeline, you can absorb some additional load without getting derailed.

‍

For you to understand how much buffer you need, it is best to look at historical data to see how much work usually gets injected. Ideally, you should aim to keep the actual injected work as minimal as possible and treat the buffer as a safety net rather than deliberately trying to use it. Once it is all used up, you will begin to feel the effects of derailment, and your planning accuracy will suffer.

‍

It is also worth adding buffer capacity to account for sick days. Even if you do everything else right, a few of your team members coming down with the flu can derail things. Factoring in a certain amount of buffer for this at a quarterly planning level can help insulate you from the unexpected, especially for things like sickness, which are largely beyond your control otherwise.

‍

Meaningful Prioritization

Prioritization is a critical part of planning. There is always more work than there is time to do it, so prioritizing the correct work is necessary to ensure the best outcomes for the business. As an added benefit, regularly prioritizing and accounting for business priorities before each sprint also helps mitigate the risk of scope creep and changing requirements, which in turn helps keep your team's morale high. However, knowing what to prioritize can be difficult. You need to consider factors such as business value—what will put the business in the best position to succeed? However, you also must consider the dependencies—can this work be done now, or does something else need to be done first?

‍

There are techniques you can leverage to help you answer these questions.

‍

Critical Path Analysis

Critical path analysis helps you understand the sequence of essential deliverables that need to be completed to satisfy the "critical path." You might provide the business objective or idealized outcome as input and use this to determine what needs to be true to get there. This path can be used as a road map to help determine what the critical tasks you need to complete are and where time and budget should be spent to achieve the desired outcome.

‍

Dependency Mapping

Dependency mapping involves identifying and visualizing the relationships and interdependencies between pieces of work in a project. The dependency map you create through this process can be used to optimize the work sequencing and identify potential bottlenecks that could put the work at risk.

‍

Clear Communication

Software development is collaborative by nature, and as with any collaborative activity, communication matters. It is understood that planning and estimations will not always be accurate. However, when work begins to drift and estimates are overshot, clear communication is what will keep you on track. Developers need to communicate early and often when things look like they will exceed estimates. This, in turn, allows product owners to manage expectations with stakeholders early and for plans to be adjusted as necessary. The alternative is a lack of communication that causes stakeholders to only learn of the delays when deadlines are missed, which isn't a pleasant experience for anyone.

‍

Data-Driven Decision-Making

At the heart of agile development is the idea of continuous improvement through iteration. This applies not just to the software you are developing but also to the practices you apply throughout the development process. Planning is one of the areas where this principle is highly effective. By necessity, _planning_ and its related processes produce a lot of data and artifacts—things like estimates, timelines, sprint burndowns, and velocity. This data is a trove of valuable insights that you can use as inputs for your future decision-making. By having this information produced regularly by your processes, you have the ability to see how changes to your ways of working impact your performance. While there is no silver bullet to immediately fix a broken process, having visibility and measuring the outputs means that you can make meaningful improvements over time.

‍

However, you need data to do this—the more of it, the better. DevStats can help with this. DevStats produces detailed reports that can give you actionable insights into your team's sprints, planning accuracy, and work allocation. It integrates with services like Jira and GitHub, so you can be assured that this data will be available for you when you need it, without the overhead of manually tracking everything yourself.

‍

The sprint report shows you what has been committed to and completed in a given sprint. This helps you understand whether your sprint planning is accurate and effective or if work is rolling over between sprints and being injected midway through. This provides a short-term view of your planning accuracy on a per-sprint basis.

The allocation report helps you understand how much of the work you've done was planned work that was pulled from your roadmap and how much was unplanned work that needed to be injected. This gives you a longer-term view of your planning accuracy across several sprints.

Wrapping Up

Planning is a crucial part of software development, and often, the outcome of planning is used as the basis for business plans in the short and long term. Because of this, it can be problematic when your planning turns out to be inaccurate. Inaccuracies are often caused by factors like surprise work and unrealistic estimates, both of which can be mitigated through discipline and data-driven continuous improvement. One of the most powerful allies in your quest for more accurate planning will be historical data. By measuring your planning accuracy and team performance with reports like those produced by DevStats, you put yourself in a position to experiment, iterate, and improve.

‍