Overview of Agile Estimating
Absolute vs. Relative Sizing
When more is known than unknown, use absolute estimating. A traditional or Waterfall software development lifecycle includes a long and detailed planning period to define requirements before beginning development. Absolute estimating is the practice of applying an hourly, finite estimate to each requirement. Absolute estimating may seem like a good approach when requirements are known, the environment is not complex, and the need is not urgent. However, even if detailed requirements are available, there are common concerns with absolute estimating.
- I know how to do it, so the size reflects my experience versus how complex the ask
- I don’t know enough about the requirements, so the size is a measure of my uncertainty
- I have little experience or high time pressure; therefore, the estimate is influenced
- I am swayed by irrelevant or misleading information, such as budget, so my estimate is biased
The antidote to ambiguity is agility. Agile approaches continue to gain popularity because of the marketplace’s volatility, uncertainty, complexity, and ambiguity. One of the reasons Agile frameworks work so well in complex domains, such as software development, is the balance of responding to change and getting something completed within specified, timeboxed iterations. It’s a different approach than a traditional software lifecycle, but it is necessary. In an Agile approach, the developers only know enough to get started–they don’t know everything needed to complete an item. This intentionally incomplete plan works because they determine what is required through daily collaboration with the requestor during development. The more ambiguous the requirement, the more difficult it is to calculate how long something will take. But teams still need to estimate their work to forecast releases.
When more is unknown than known, use relative sizing. Unfortunately, humans are phenomenally bad at estimating and even worse when working in a complex domain like software development. (2006, Jørgensen and Grimstad). Luckily, people are good at comparing things. Agile estimating uses relative sizing to provide a realistic way for teams to forecast work. This estimating method uses the Fibonacci sequence as a starting scale for comparing items. In the Fibonacci sequence, each number is the sum of the preceding two numbers: 0, 1, 2, 3, 5, 8, 13, 21…
Why use the Fibonacci sequence? Borrowed from nature, this
exponentially increasing scale deliberately creates a buffer in estimating that allows for change.
The Developers on a Scrum Team size the work they are accountable for delivering (Developers in Scrum include anyone needed to develop the work, including analysts, UX, and quality professionals). They discuss each request and assign a number from the Fibonacci scale that correlates to the overall size. They use everything they understand about the request at that point in time and what is expected to call it complete. This method is called Story Pointing, accredited to Ron Jeffries, an Extreme Program (XP) expert, and Agile thought leader. While Story Points include effort, like absolute estimating, it further accommodates the expected ambiguity of Agile requirements. Story Points represent the complexity, uncertainty, and effort (CUE) needed for completing or implementing each work item. The higher the number, the more complex and uncertain the work, and presumably, the amount of effort it will take to complete.
Using the Fibonacci scale, developers compare items to each other; the scale is the same for everybody on the team. Over time, teams start to see the same completion curve as various people work through items with the same point values. For example, 1 Story Point means that CUE is minimal, and the item can be delivered quickly, perhaps in one day or less. On the other hand, an item assigned 13 Story Points means it is very complex and could take multiple weeks to complete.
When using the Fibonacci scale for relative sizing, teams experience the following benefits:
- Establishes a scale for comparing an item’s complexity, uncertainty, and effort
- Involves the whole team; therefore, includes everyone’s perspectives
- The exponential nature of the Fibonacci Scale makes it easy for the entire team to understand what the assigned numbers mean to them and their unique domain
Agile Planning
Trust the Team and the Process
The whole team needs to understand the logic behind the assignment of Story Points to reach a consistent practice. All team members vote–without being influenced by other team members. There are plenty of techniques to do this, such as Fist to Five voting or Planning Poker. Outside pressure or not enough teaming can quickly artificially inflate story points, which then affects forecasting.
Normalizing. A bit of normalization occurs through regular practice that helps ensure everyone on the team makes the same assumptions behind sizing. For example, if one person sizes an item at a “2”, but another person sizes it as an “8,” given they share similar ability, they interpret the requirement differently or approach it from different directions. When this happens, the Developers collaborate with the Product Owner to clarify assumptions and agree on a size. (This does not need to be a consensus – people can agree to disagree.)
While a team is learning what the Fibonacci scale means to them, with their unique set of skills, tenure, and domain knowledge, it is helpful to compare new requests to completed work with shared similarities. For example, when a new item is assigned a Story Point value of 5, compare it to similar things with the same size, then adjust the Points accordingly.
3-touch system. Through the practice of refining, breaking work into smaller, valuable chunks, the Developers continue to gain insight. As each request becomes smaller and more is known, they continually revisit the size. It’s a good practice to provide three touchpoints to help the team with the emerging design, development, and dependency of requirements. Along the way, revisit the Big View of the organization to ensure that strategy continually informs development.
- Pre-View: During Release Planning, an event where a team is looking several Sprints ahead, items are typically substantial. Therefore, high-level forecasting can be completed by comparing large, new work to complete similar work.
- Now-View: During Sprint Planning, the Developers learn more as they break each item down into tasks and then size each task using hours.
- Daily: As the Developers work on each item during the Sprint, they continue to learn and daily re-forecast the remaining work against the Sprint Goal, including any quality measures and tasks needed to achieve their Definition of Done.
Practical Fibonacci
Getting started
The chart below may help your Developers if they are new to relative sizing using Fibonacci. (The term Developers in Scrum includes anyone developing the work, including business analysts, UX, and quality assurance professionals. Getting something to Done means it meets everyone’s expectations of Done, typically written out in the Team’s Definition of Done.) These definitions are meant to be a starting point for a conversation. Ultimately, your team will find their own value scale and their own language that is meaningful to them.
Coaching the Grey Areas of Sizing
This conversation continues with some FAQs and Coaching tips in Part II: Coaching the gray areas of sizing
~Julee Everett
Hone your craft, speak your truth, show your thanks
Visit my YouTube Channel to access a growing library of professional development webinars and subscribe below for more content!
Read more at AmplifyAgility.com