Atomic Agility

Search

SearchSearch

Fibo Lite Estimation

Aug 30, 202417 min read

Context

Imagine you and your friend are about to go on an international trip. Would you plan your itinerary in detail, booking all hotels and restaurants in advance? Or would you wait until the day of departure to try and purchase plane tickets? Now imagine tomorrow you and your friend are planning to stroll through a nearby city. Would you create a precise route plan in advance, or would you decide on your mode of transportation just before leaving?

These two scenarios illustrate the balance between the level of planning and the associated risks. For international travel, we usually prefer detailed planning due to the higher level of unknowns and risks. However, for a city walk, we might lean towards spontaneous decisions as the risks are relatively lower. Similarly, in the development process, can we proceed quickly by addressing sand-level requirements directly? This is akin to making decisions while moving in the dark, a state we refer to as potential risk state.

In software development, the primary purpose of estimation is to help teams better manage risks, understand requirements, and assist in design. Through estimation, the team can make reasonable predictions about the future and formulate effective plans. However, another crucial function of estimation is to align the team’s understanding of the requirements, ensuring everyone is discussing and deciding based on the same foundation. Therefore, estimation is not just a prediction of the workload but a comprehensive consideration of various key aspects of the project.

In the estimation process during development, we need to find a balance between the following two key points:

Risk Control

Estimation is an essential tool for controlling risks. When developers are asked to provide estimates, they typically reassess the complexity and potential risks of the requirements. By using Ping-Pong Splitting alongside Fibo Lite Estimation, the team can better understand and evaluate the risks associated with requirements, thereby avoiding potential issues caused by overly broad estimation granularity.

Time Efficiency

We’ve spent countless efforts trying to achieve so-called more reliable estimates, but ultimately, we cannot escape the essence of estimation.

However, spending too much time on estimation is not always wise. In my experience, whether you spend 10 days or 1 day estimating, the project’s final outcome is often similar. However, delaying time may cause the team to forget the initial estimation details by the time development begins. Therefore, speed is one of the keys to Agile estimation, which requires maximizing efficiency while controlling risks.

Similar Concepts

Planning Poker

Planning Poker generally involves the following options:

?, 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞, Coffee cup

The process is as follows:

  • Prepare the Deck: Each team member gets a set of Planning Poker cards with numbers (such as Fibonacci numbers) and special symbols (like ”?”, ”∞”).
  • Task Description: The product owner or project manager briefly describes the task or user story to be estimated, ensuring all members understand the requirements.
  • Independent Estimation: Each team member selects a card that best represents their estimate of the task, without discussing it with others.
  • Reveal Simultaneously: All members simultaneously reveal their chosen card, showing their estimates.
  • Discuss Differences: If there is a significant variance in estimates, the team discusses. Typically, the members with the highest and lowest estimates explain their reasoning.
  • Re-estimate: After discussion, team members estimate again until they reach a consensus or near-consensus on the estimate.
  • Record Results: The final estimate is recorded for planning and task allocation.

Fibo Lite Estimation differs from Planning Poker in the following ways:

  • No need for large numbers:^no-need-big-numbers
    • Numbers like 13, 20, 40, 100, and ∞ represent risks. We might have given a number simply because it seemed large enough, but if a requirement seems too large, it should be split rather than assigning a number.
  • No need for 0 or ½:
    • These requirements can be merged into a new requirement entry, so they should not exist separately.
  • No need for question marks:
    • If we focus too much on the form of Poker, we end up with these cards. The problem isn’t the priority; advancing the backlog to solve the problem is more important.
  • No need for coffee breaks:
    • Needing coffee suggests that the estimation process is taking too long. A quick process shouldn’t require breaks.
  • Not all members need to discuss every requirement in detail:
    • Many people in the team just go along with the flow, pretending to understand when playing Poker, which is meaningless.
    • The key point is: after all estimates are provided, does every team member agree with the estimates?

Agile Estimating 2.0

From Agile Estimating 2.0 – Cheat Sheet

  • Initial Arrangement: Start with a stack of pre-sorted story cards, arranging them by size from left to right, with the smallest on the left and the largest on the right. Group cards of similar size vertically.
  • Place the First Card: Place the first (highest-ranked) story card in the center of the table or board.
  • Turn-based Estimation: Team members take turns estimating. Each round, players can:
    • Draw a new card from the top of the stack and place it in the appropriate position based on its estimated size.
    • Adjust the position of already placed cards, re-estimating their size.
  • Discussion Rules: While a player is estimating, other members may only ask clarifying questions and should not express personal opinions.
  • Final Adjustment: After all cards are estimated, each member can move one card for a final adjustment.
  • Assign Story Points: Assign story points based on the card groups, using pseudo-Fibonacci sequences (1, 2, 3, 5, 8, 13, 20, 40, 100) or powers of 2 (1, 2, 4, 8, 16, 32, 64, 128).
  • Relative Estimation: The numbers represent the relative size/workload of each story. For example, 3 story points represent about 1.5 times the workload of 2 story points, and 8 story points represent twice the workload of 4 story points.

Fibo Lite Estimation differs from Agile Estimating 2.0 in the following ways:

  • Only use Fibonacci sequence 1, 2, 3, 5, 8:
  • Do not emphasize relative estimation:
    • Only use the numbers 1, 2, 3, 5, 8, and emphasize that if a requirement was estimated as 1 before, similar future requirements should also be estimated as 1 (thus naturally relative estimation).
  • The team can select a few people to provide estimates rather than involving everyone:
    • Those who do not provide estimates can ask questions, such as testers or newly joined team members.

Key Features

Concept

Light Fibonacci Sequence (12358)

The estimation process only uses the numbers 1, 2, 3, 5, and 8, helping to level granularity of the requirements. Requirements smaller than 1 should be merged to provide an estimate, while requirements estimated at 8 should be split.

  • Feedback from the business perspective:
    • Although estimation is a technical task, complexity confirmation can receive feedback from the business perspective. For example, questioning why a previous requirement was estimated as 1, but this one is estimated as 2.
    • Different tasks from different functions, such as testing, frontend, and backend, can be combined into a single requirement as several tasks.
  • Estimation describes the complexity of the requirement:
    • How many database tables are involved? How many interfaces? How many interactions? Are there animations? Is the algorithm complex? How many third-party interfaces are required? These can all be used as dimensions to measure the complexity of requirements, and a simple comparison table can be created for estimation.
  • Not included in estimation:
    • Waiting time:
      • Waiting for third-party completion, waiting for documentation from certain roles, waiting for online debugging, etc., should not be included in the estimate.
    • Defects:
      • Defects are failures of expected functionality, while new features are unanticipated missing functionalities. It is important to clarify whether it is a defect or a new feature.
    • Technical tasks:
      • Technical tasks cannot be perceived from a business perspective, so technical optimization should be done gradually rather than waiting for a massive accumulation of technical debt.

However, it is essential to note that estimation is fundamentally a prediction of the future. If too many responsibilities are placed on estimation in project management, it can lead to a shift in focus. For example, the team might focus more on meeting the estimated numbers rather than the actual quality and outcome of the work. This shift can not only diminish the creativity of the work but also cause the project to deviate from its original goals. Therefore, when using estimation, it is crucial to maintain a clear understanding of its purpose and avoid turning it into a tool for excessive control.

Potential Risk State

“Potential risk state” is not just a common phenomenon in development; it is a critical area in project management that must be constantly monitored and managed. Identifying these potential risks, understanding their origins, and taking appropriate measures to mitigate or eliminate them is the foundation for ensuring the smooth progress of a project.

1. Lack of Estimation

Any requirement or task that has not been estimated is filled with potential risks. These types of requirements often belong to the sand-level category, which, due to their high uncertainty, can easily lead to increased uncertainty in the project. Therefore, requirements without estimation usually imply higher risks.

2. Risk of Assumptions

In development, assumptions are predictions or prerequisites about future situations. Whether or not assumptions are present during the estimation process, they both bring potential risks:

  • Estimation without Assumptions: If an estimation is made without clear assumptions, it is often based on incomplete information or overly optimistic predictions. This situation can easily overlook potential unknown variables or unexpected circumstances, leading to severe deviations in project progress or costs. In other words, estimation without assumptions is, in fact, a risk within a risk.
  • Estimation with Assumptions: Even when assumptions are present, estimation may still pose potential risks. Assumptions are essentially predictions about the future, but these predictions may not align with actual circumstances. If the assumptions do not hold true, the estimation results may deviate significantly from expectations, thereby affecting the accuracy and controllability of the project.
3. Estimation as 8

In estimation, the number 8 represents the maximum value in the sequence, usually used to describe the most complex and uncertain requirements. Giving an estimate of 8 may indicate that the team cannot further refine the complexity of the requirement, and at this point, the risk and uncertainty of the requirement often exceed expectations. Therefore, any requirement estimated as 8 should be considered a high-risk requirement that requires further exploration.

Roles

The Prompter can double as the Challenger, but the Executor should be independent.

Prompter

The Prompter may be a requirement or business-related person or could also be a facilitator.

Responsibilities:

  • Clarify the scope of estimation: Define which requirements are within the scope of this estimation and which can be excluded.
  • Focus on time efficiency:
    • Ask the Estimation Executor why an estimate cannot be made and what assumptions are needed for estimation.
    • Ask the Estimation Executor if the requirement estimated as 8 can be split and whether assumptions can be provided.
    • Record all issues that need discussion, creating a to-do with deadlines for a specific person.
    • Record all information agreed upon by everyone.

Estimation Executor

The Estimation Executor is usually an experienced developer or an architect who is very familiar with technical details.

Responsibilities:

  • Determine the estimation number.
  • Clarify the assumptions.
  • Explain why an estimate cannot be made and what needs to be done to obtain the estimate.

Challenger

Challengers are usually composed of testers, less experienced personnel, or team managers.

Responsibilities:

  • Ask further questions to the Executor:
    • A similar requirement was estimated as a certain number before, but why is this one different?
    • Have specific conditions been considered?
  • Ensure that the raised issues are appropriately followed up.

Process

Here is a flowchart from the Estimation Executor’s (Executor) perspective:

flowchart TD 
start1([Start])  
end1([End]) 
start1 --> Unestimated 
Unestimated --> try[Attempt<br>to<br>Estimate]
try -- Split --> try 
try -- Merge --> try 
try -- Clarify<br>Assumptions --> assumptions 
assumptions --> try 
try -- Clarify --> try 
try -- Answer<br>Questions --> try 
try -- 12358 --> withE("Estimated")
try -. Obstacle .-> toDo 
withE -. 8 .-> potentialRisk 
withE -. No Assumptions .-> potentialRisk 
assumptions .-> potentialRisk 
withE --> end1 
toDo .-> end1
  • Prompter clarifies the estimation scope and participants, driving the Estimation Executor to start:
    • Define Scope: The Prompter clarifies the scope of requirements for this estimation and decides on the number of Challengers to ensure the right people are involved.
    • Drive Start: The Prompter instructs the Estimation Executor to begin estimation and ensures that relevant information and resources are available.
  • Estimation Executor proposes assumptions and conducts initial estimation:
    • Propose Assumptions: The Estimation Executor proposes assumptions based on the complexity of the requirements.
    • Initial Estimation: Use the light Fibonacci sequence to perform the initial estimation of the requirements.
  • Challenger questions the estimation and drives discussion:
    • Question Validity: The Challenger raises critical questions to validate the estimation’s validity.
    • Drive Verification: Push the team to further discuss and verify assumptions.
  • Prompter records issues and drives requirement splitting or merging:
    • Record Issues: The Prompter records issues that arise during the discussion.
    • Drive Adjustment: Drive the Estimation Executor to split or merge requirements and adjust estimates.
  • Estimation Executor adjusts estimates and ensures team consensus:
    • Adjust Estimates: Adjust estimates based on feedback and ensure team consensus.
    • Confirm Results: Ensure that the final estimation results are agreed upon by the team.
  • Prompter records to-do items and follows up:
    • Record and Follow Up: The Prompter records to-do items and assigns responsibilities, ensuring that issues are resolved.
    • Drive Completion: Drive the entire estimation process to a smooth conclusion and summarize improvements.

Key Points in Estimation

There are two key points in the estimation process that can help us quickly achieve relatively accurate results. These two points are:

1. Large Sample Size

Any estimate may contain bias, but from a statistical perspective, if the sample size is large enough, the overall estimation results will tend to balance individual biases, as shown in the figure:

Importantly, if you compare the current requirements with previously estimated ones, you meet the statistical requirement of a “large sample size.” However, if you only focus on estimating a small number of current requirements each time, you will face greater uncertainty.

2. Small Individual Granularity

If 100 is allowed as the maximum unit for estimation, some requirements will undoubtedly be estimated as 100. But does this estimate accurately reflect the actual size of the requirement? Often not. In reality, such an estimate may mean that the requirement’s complexity far exceeds 100, possibly reaching 1000 or even 10000, simply because we lack more significant numbers for differentiation.

In contrast, smaller granularity requirements are more reliable in estimation. Small granularity requirements have a narrower range of variability, and during the splitting process, the variable parts can also be isolated and broken down. You can refer to Ping-Pong Splitting for splitting methods.

Before entering the actual development phase, it is advisable for the team to re-estimate the requirements. The focus of this estimation is not on achieving precise numbers but on re-examining the requirements to understand the implementation approach better and further manage potential risks. Although this estimation is not used for statistical analysis, it can effectively help the team confirm whether their design and implementation paths are reasonable, thereby increasing the chances of successful development.

  • Planning Poker takes too much time.
  • There are too many unnecessary cards (only 1, 2, 3, and 5 are needed).
  • It requires carrying additional items, which may get lost.

Abandoning Estimation

Whether to use estimation depends on the context and the ability to control risks rather than some theoretical correctness. You can choose to use estimation or not. It’s like choosing what food to eat, which should depend on your body’s needs. However, if you can’t accurately perceive what your body needs, the advice of various nutrition experts becomes especially important.

Especially in the field of knowledge work, the challenges of estimation become more pronounced. The creativity and uncertainty of knowledge work make simple estimation methods unable to reflect the complexity and value of the work. In such a context, forcing the use of estimation may lead to underestimating the value of knowledge work and stifling potential innovation. Therefore, when performing estimation, it is necessary to adjust the method and expectations based on the specific nature of the work.

We cannot assert that these experts’ advice is wrong. You can try their methods, observe the reactions, and then make adjustments. This article suggests using estimation in most cases, just as nutrition experts recommend a balanced diet.

If you are working on a self-funded project with unlimited budget and resources, then detailed estimation might not be necessary. You can calculate the ratio of costs to revenue and find the balance. However, if it’s a client-contractor project filled with uncertainties and risks during implementation, abandoning estimation could bring significant challenges and risks.

A few years ago, “Kanban Father” David Anderson prepared to write a book on Kanban practices and sent a researcher to China to collect material. This researcher was shocked to see that every card on the Kanban board had a committed delivery time, estimation, and progress tracking information. He was surprised and expressed that this was not the critical point of the Kanban method, considering it to be almost excessive control and pressure.

However, this approach reflects an acknowledgment of reality. When faced with highly coupled systems, uneven personnel quality, and immense pressure on version releases, this method is widely adopted in China and is actually a reasonable coping strategy. In similar situations, you might adopt a similar approach to manage projects.

Estimation Methods Comparison

In Agile development, avoiding the use of linear sequences (like 1, 2, 3, 4, 5…) for estimation is key. Linear sequences easily give the team a false sense of precision, making it seem like the differences between each number can be accurately measured. However, they fail to adequately capture the uncertainty and complexity of requirements. This illusion might lead the team to underestimate risks when dealing with complex requirements, affecting the project’s progress.

Fibonacci Sequence (12358)

This method uses the numbers 1, 2, 3, 5, and 8 to estimate the size of requirements. These numbers are simple and clear, making them easy to use for direct calculations and for the team to reach a consensus. It is suitable for most teams, helping to quickly produce estimation results, and business personnel can easily understand it.

Power of Two Sequence (1248)

This method uses the numbers 1, 2, 4, and 8 for estimation. These numbers have larger gaps between them, making them suitable for quickly breaking down complex requirements into larger chunks. It is appropriate for situations requiring rough estimation, but it might not be as detailed as the Fibonacci sequence.

T-Shirt Sizing

This method uses labels like “XXS, XS, S, M, L, XL, XXL” to represent the size of requirements. While intuitive, it ultimately requires converting to numbers for calculation. It is suitable for quickly categorizing requirements, but be mindful that the subsequent conversion to numbers may increase complexity.

These methods share the commonality of avoiding linear sequences, using nonlinear sequences more effectively to reflect the complexity and uncertainty of requirements, thus helping teams make more reasonable decisions.

Considerations of Atomic Agility

From the perspective of Atomic Agility, the estimation process should focus on quickly adapting and flexibly responding to changing requirements, rather than merely pursuing numerical precision. By applying the principle of Broader Perspective, teams not only focus on the specific details of the current requirements but also consider potential risks and future changes, making the estimation more strategic. The principle of Stronger Discipline emphasizes maintaining strict rules for splitting and merging tasks during the estimation process to ensure appropriate granularity and avoid getting bogged down by trivial details during execution. At the same time, using the approach of Clearer Gray Areas, teams can strike a balance between detailed planning and improvisation, ensuring they don’t lose their agility by overemphasizing perfect planning. These principles collectively guide teams to remain agile in the face of uncertainty, ensuring that estimates control risks while also promoting flexible project progress.

Graph View

Backlinks