The #NoEstimates Movement
An alternative to costly and time consuming estimation processes that offers no value to the players.
Traditional estimation methods in software development are flawed due to cognitive biases and unpredictability.
The #NoEstimates approach uses historical data and task completion rates for more reliable forecasting.
Implementing #NoEstimates involves slicing stories thinly, using time-boxes, and updating forecasts frequently.
My loyal readers and those around me know how much I wouldn’t say I like estimations that require a fully fleshed-out specification upfront before development can begin. They also likely know how much I covet probabilistic forecasting with Monte Carlo simulations to answer “When will it be done?”. In this post, I offer an alternative (and often contentious) point of view on estimating software completion dates.
Finding efficient and effective ways to manage and forecast work is crucial for new game development and enterprise-scale live operations. One approach gaining traction in some agile circles is the #NoEstimates movement. Let’s explore what this entails and how it can benefit large-scale game production.
The Flaws in Traditional Estimations
Estimations are Guesswork
Estimations are guesses. You might call them educated guesses, but they are still based on limited knowledge. We’re always solving new problems in a world where technology changes and users’ needs evolve. This means we’re continually researching and adapting.
A fun game feature is, by definition, inherently unpredictable. You’re in a constant state of discovery. Feedback reshapes your understanding of the domain. Future user stories are constantly shuffled, sliced, discarded, or pivoted. If not, you might not interact enough with your players and likely follow an outdated plan. There are always unexpected blockers and obstacles, and the uncertainty only increases for stories you’ll start a week later.
Game development isn’t like carpentry, where tasks can be more easily repeated and estimated. Almost everything a developer writes is unique, bringing unpredictability that makes precise estimation challenging.
Cognitive Biases in Estimation
Human estimation is often subject to cognitive biases, such as the planning fallacy or optimism bias. Focusing on actual completion rates rather than estimates can potentially mitigate these biases.
Parkinson’s Law Influence
Work often expands to fill the time available. This means that even if a task could theoretically be completed quickly, it might take longer due to various factors (perfectionism, procrastination, unexpected complexities).
The “Flaw of Averages”
Traditional estimation often relies on average case scenarios, which can be misleading. The actual distribution of task completion times might be skewed, making averages less reliable for prediction. In traditional estimation, using an average to predict the duration of tasks can result in significant underestimation or overestimation because it does not account for the variability and distribution of task sizes. In contrast, the #NoEstimates method, which focuses on the number of tasks completed over time, tends to be more resilient to these variations.
The #NoEstimates Approach
The Purpose of Estimates: It Depends
The effort put into estimates should reflect how well the team understands the problem and the level of detail needed. Estimates should come from those closest to the work and be enough to make the next decision.
Properly used, estimates are a tool for better decision-making and planning rather than a rigid measure of success. They enable teams to navigate the complexities of game development with greater confidence and flexibility, ultimately contributing to more successful outcomes.
Risks of Using Estimates Incorrectly
When misused, estimates can create a false sense of security for stakeholders, leading them to believe that dates far into the future are set in stone. This can result in unrealistic expectations and pressure on the development team. Additionally, the need for precise completion estimates often drives teams into agile anti-patterns, such as excessive upfront planning. This contradicts the agile principle of iterative development and can delay the start of actual development, reducing the team’s ability to respond to changes and deliver value incrementally.
Task Counting vs. Story Point Estimation
The #NoEstimates approach suggests that counting the number of completed tasks over time can be as effective as using story points for estimating and forecasting. It’s important to understand that story points were never intended to estimate the completion of an entire feature or product backlog. They were designed for short-term objectives like sprints, helping teams manage and plan small increments of work. Story points can be helpful within the sprint framework but can become less reliable for long-term planning and forecasting.
Consistency in Task Completion Rate
A core principle of the #NoEstimates approach is the consistency in task completion rate. Over time, a team completes a relatively consistent number of tasks, regardless of complexity. This consistency emerges from several factors:
Team Capacity: A team’s overall capacity in terms of time and resources remains relatively stable over short to medium periods.
Task Breakdown: Complex tasks are usually broken down into smaller, more manageable subtasks.
Balancing Act: Teams often work on complex and simple tasks simultaneously.
Practical Implementation
Leveraging Historical Data for Forecasting
Instead of relying on subjective estimates, the #NoEstimates approach uses historical data to forecast future completion rates. By tracking the number of tasks completed in a given period (e.g., a month), teams can project future work more accurately. This reliance on actual performance data can lead to more reliable forecasts, helping to manage resources and timelines in game development better.
Simplifying the Process
Estimating story points and calculating velocity can be time-consuming and often imprecise. The #NoEstimates approach aims to simplify this process by breaking down work into smaller, more manageable tasks and tracking their completion. This can free up valuable time for teams, allowing them to focus on the actual work rather than estimation activities.
Self-Regulating Nature of Task Definition
Teams often unconsciously adjust their task definitions to maintain a consistent completion rate. For example:
A very complex task might be broken down into multiple smaller tasks.
Several small, simple tasks might be grouped into a single task.
Focusing on Value Delivery
Learning and Efficiency Improvements
As teams work together over time, they often become more efficient. This improvement can balance out the increasing complexity of tasks as a project progresses.
Focusing on Value Delivery
Proponents of #NoEstimates argue that it allows teams to concentrate on delivering value rather than spending time on estimation. By reducing the emphasis on precise estimates, teams can become more flexible and responsive to changing priorities. This adaptability can be a significant advantage in the ever-evolving world of game production.
Encouraging Continuous Flow and Delivery
The task-counting approach aligns well with the principles of continuous flow and delivery in agile development. It encourages teams to maintain a steady pace of work completion rather than focusing on arbitrary point-based goals. This constant flow can be particularly beneficial in the continuous delivery model of GaaS, where regular updates and improvements are critical.
Adaptability to Changing Requirements
Requirements can often evolve in game production, and project scopes can shift. The #NoEstimates approach, focusing on task completion rates rather than detailed upfront estimates, can better suit projects with uncertain or changing requirements. This adaptability allows teams to pivot quickly and address new challenges.
Adaptability to Unforeseen Circumstances
This approach inherently accounts for unexpected delays or complications common in software development, as these are reflected in the overall task completion rate. By focusing on the rate of task completion rather than individual task estimates, teams can maintain a more consistent workflow, potentially leading to better overall productivity.
Practical Tips for Implementing #NoEstimates in Game Development
1. Slice the User Stories Thinly
To make the #NoEstimates approach effective, try to keep each user story small—ideally no more significant than two days of work, and preferably small enough to be completed in half a day to a day. A quick way to check if a story is small enough is to ask, “Can you have this done by tomorrow?”
By ensuring all stories are roughly the same size, estimation becomes unnecessary. Additionally, each story should be independent and valuable on its own. This allows you to choose not to implement some stories without impacting the rest of the project.
However, breaking a feature into stories can be a waste of time if you decide not to implement that feature or if feedback significantly changes it. Rather than breaking down every feature at the start, use a secondary measure called feature velocity to forecast when features will be delivered. This measures how many features you deliver per sprint.
2. Time-box and Prioritise
It would be best if you could determine the cost without traditional estimates. Use time boxes for both projects and features.
Time-box the project: Instead of estimating the cost, decide your available time. Order the features in the backlog by value. The least valuable stories will be left out if not all features can be completed.
Time-box features: Ensure no aspect or epic of a feature takes longer than a month. Prioritise the stories within features. If not all stories are completed, discard the rest or move them into a new feature and place them in the backlog based on their value. This way, feature velocity will be more reliable, and you can drop low-priority stories if needed.
3. Update the Forecast Frequently
The #NoEstimates approach allows for very lightweight and frequent forecasting. Every week or sprint, you can predict when you are likely to deliver specific features and what will be completed by the deadline.
This frequent forecasting enables you to manage scope effectively throughout the project. If you see you’re not on track, you can decide to remove low-value features or stories from the backlog to stay focused on delivering the most valuable aspects of the project.
User Story Mapping
An effective way to support the #NoEstimates approach is using the User Story Mapping process early in the development cycle. This technique can help teams get a clearer picture of the work ahead and provide a user story count that can be used to forecast a completion date.
What is User Story Mapping?
User Story Mapping is a visual exercise that helps teams understand a user’s journey through the product by mapping out user stories in the order they will be experienced. This process highlights the necessary features and tasks and ensures the team maintains a user-focused approach throughout development.
How User Story Mapping Supports #NoEstimates
Initial Story Count: During the User Story Mapping process, the team identifies and documents all the user stories required for the product. This results in an initial count of user stories, which can be a starting point for forecasting.
Prioritisation and Breakdown: The team can get a realistic view of the workload by organising stories by priority and breaking down more significant stories into smaller, more manageable ones. This detailed breakdown aligns well with the #NoEstimates focus on task counting.
Visual Progress Tracking: User Story Mapping visually represents progress, helping the team see how much work remains and how it aligns with user needs. This transparency supports better decision-making and more accurate forecasting.
Incorporating User Story Mapping into your development process can significantly enhance the accuracy and reliability of forecasts in a #NoEstimates framework. By providing an early count of user stories and leveraging historical completion data, teams can better predict project timelines and focus on consistently delivering value.
Cumulative Flow Diagram for Forecasting
One of the tools used in the #NoEstimates approach to forecasting completion dates is the cumulative flow diagram (CFD). A CFD provides a visual representation of the number of tasks in various stages of completion over time. By analysing the flow of tasks through different stages, teams can identify bottlenecks and predict when future work will be completed. This data-driven method offers a more reliable way to forecast completion dates than traditional estimation techniques.
A Topic of Debate
While the #NoEstimates movement has its supporters, it remains a topic of debate within the software development community. Some practitioners find it compelling, while others argue that estimation still has its place in project planning and management. The effectiveness of this approach can depend on various factors, including the specific context, team dynamics, and project requirements.
Conclusion
The #NoEstimates approach offers a compelling alternative to traditional estimation methods, particularly in enterprise-scale game services. By focusing on task completion and leveraging historical data, teams can achieve more accurate forecasting, streamline processes, and deliver excellent value to their players. As with any methodology, it is essential to assess its suitability for your specific needs and be open to adjusting your approach as necessary.