Estimation — the one loose thread in the tapestry of Agile. There is plenty of material describing what doesn’t work, but despite our best efforts as an industry, none of the solutions thus far have seemed to work. Traditionally, there has been an implicit lack of consensus on the purpose of software estimation. What precisely are we measuring, and thus estimating? Is it the time it will take to complete a task, the date when we can ship, or the cost of the development effort? The answer usually depends on whom you ask.
A Trip to the Store
Consider a shopping trip to the grocery store in preparation for a party. You have a list of items and a budget. Notice what we don’t consider: the number of transactions, the size of the shopping cart, or the number of shoppers. Why? Our limiting factor is our budget, and our goal is to purchase everything on the list. Adding more shoppers or using larger shopping carts will not change that budget.
Once you have identified your limiting factor, you can either take a predictive or an adaptive approach to planning your shopping trip.
The predictive approach is to try to guess how much all the items on your list are going to cost. Assuming you don’t have the option of looking up the prices online, you’re going to have to make your best guess using knowledge of prior shopping trips, maybe some old grocery receipts, and awareness of how prices have changed recently.
The adaptive approach is to write a list of the items you want to purchase, and determine your budget for the trip. That budget is normally dictated by external factors, and not by the items on your list. You would probably also prioritize your shopping list, so if you find your budget isn’t sufficient to cover everything, you can easily determine what to skip.
Often, you’d take some sort of hybrid approach that combines both techniques. Knowledge of prior shopping trips and market rates may help you write a realistic shopping list, and then you can iterate on this list once you’re at the store.
Which approach makes more sense for your shopping trip? It depends on the situation. Regardless, if you don’t know your budget, none of these techniques will work!
What Do We Measure?
In software estimation, we deal with finite resources as well, such as financial budgets and time constraints. Starting our thinking from these is dangerous, however, because neither directly correlates to how many items on a list of software development goals we can complete.
The real limiting factor in software development is Developer Energy. Human beings have a limited amount of cognitive energy each day and each week, and once that is exhausted, the quality of their work diminishes significantly. (This is a major reason why the adage “never ship on Friday” exists; errors are more likely at the end of the workweek.) One cannot overcome this limit by simply demanding overtime or paying additional money
That is not to say that time and money cannot be used to increase Developer Energy. You may eliminate unnecessary meetings to free up Developer hours, or add additional headcount (while taking Brooks’s Law into account.) These are merely ways of expanding your “energy budget,” but Developer Energy is still the limiting factor. Once a Developer is “out of gas”, you’re not getting any more work out of them until they recharge in whatever manner they need to.
Once we have identified the limiting factor as Developer Energy, we can begin the task of software estimation. Unlike traditional story pointing, the Quantified Tasks methodology actually provides a technique for repeatably measuring, tracking, and estimating the developer energy budget.
How Do We Measure?
The problem with traditional Agile Story Points is that they only indirectly measure the Developer Energy required. It’s a bit like going to the store with no clear budget, but a vague sense that the ice cream will cost twice as much as the coleslaw. What’s worse, because the amount of effort a Story Point represents varies from team to team and project to project, you have no frame of reference when planning effort on a brand-new project. It’s as if every grocery store lists prices in its own original currency.
By contrast, Energy Points in Quantified Tasks are an objective, repeatable unit of Developer effort. Instead of translating an arbitrary assessment into (say) a Fibonacci number, Energy Points are calculated from three objective 1-5 scores:
Distance: raw effort if you knew everything about the task,
Friction: available resources to inform the task, or the lack thereof, and
Relativity: how much uncertainty exists in the task.
Any two Developers may have different ideas about how “big” or “hard” a task is, depending on their experience level and other factors, but it is fairly easy for everyone to agree on a score for each of these three measures.
Energy Points are calculated via the formula (Distance + Friction) * Relativity. This estimate is thus defensible, as each of the three factors are objective, and it bears the authority of team consensus. Not only this, but because it is based on three predefined, fixed metrics, the Energy Points estimate can be compared directly to any other task from any other project or team using Quantified Tasks.
Energy Points thus represents how much Developer Energy is needed to complete the task.
Budgeting Developer Energy
Given Energy Point estimates on every task, we are now only missing one piece of information: how much Developer Energy do we have? What is our budget?
Every Developer is a unique individual. They will have different strengths, weaknesses, and experiences. Thus, for a Developer who is brand new to Quantified Tasks, it will be difficult to guess how many Energy Points they can complete in a sprint. However, after only one or two sprints, each Developer will begin to form an understanding of how much work they can complete under the circumstances.
For example, as a Principal Software Engineer in Python, I found I could complete an average of 25 Energy Points per sprint. It did not matter what the project was — as long as it was a Python-based stack, that estimate held true. If I was not proficient in the language, I could complete about 10-15 Energy Points in a sprint. Thus, I was able to select work for myself during Sprint Planning, and nearly always complete that work by the end of the sprint. (Estimates are exactly that — estimates.)
What’s further, Developers can use Distance, Friction, and Relativity to select work appropriate to their experience level. Someone brand new to a language should probably avoid taking on a high-Friction task, while someone who is more senior in that language should try to leave some of the easier work to the less experienced members of the team. Although two tasks with the same Energy Point estimate require roughly the same amount of energy, different Developers can handle different styles and cadences of effort.
As a Developer begins to track their Personal Velocity (the average Energy Points completed per sprint), it will become easier to set realistic goals for sprints and releases.
Measuring Developer Productivity
Energy Points not only allow you to estimate effort, but they can also serve as a reliable metric of how much work was completed. As long as the Quantified Tasks methodology is applied correctly by the team, and scores are updated as more information is learned, Personal and Team Velocity become good representations of Developer productivity.
There are a few things to be aware of with this, however, including:
Each Developer has a unique, fixed energy budget. This can be further impaired by external factors. Use Velocity as an indicator to trigger further inquiry, never a goal to be met.
Be wary of comparing Personal Velocity across Developers. No two people are identical, even if they have the same seniority and experience level.
If you want to use Quantified Tasks to measure Developer Productivity, please see this article:
Measuring Developer Productivity...for Real!
Over the years, Managers have faced the challenge of measuring Developer productivity. There have been many failed attempts at solving this: Counting lines of code written encourages writing complicated code, and doesn't reward Developers for improving efficiency and code health, which will typically result in negative line counts.
Getting Started with Quantified Tasks
If you want to get started using Quantified Tasks with your team or company, check out the Overview.
Overview
Your Tasks, Measured. How do you measure a task? The question has plagued project managers, software engineers, and product owners alike for decades. Do we measure in urgency? Estimated time? Work produced? Or can tasks only be measured relative to one another? None of these answers ever quite represent all the complexity a single task contains.
Please also subscribe to get the latest articles and updates delivered right to your inbox!
agree
I can suggest a cool and free SaaS service for presale process Presale.Ninja it helps with estimates and makes a professional document for your client