This post is a slightly updated version of the one published earlier
Measurement is fundamental to any engineering discipline and the planning of a software creation work is no different. Whenever you plan to make or renew a piece of software the most important metric as the workload size. Measure of size is important because knowing the amount of work to do and the team skills (i.e. velocity) you can easily derive the work costs and duration. Agile software development methods do strive against the overplanning and overdetalization. However, being agile doesn’t mean having no clue on when the work is going to be completed. Vise versa most if not all of the agile methods continuously provide team the current “best guess” on the remaining workload and possibly even options to cut some corners.
Traditional measures of size
Lines of code
- Simple. There can hardly be a simpler measure, than counting lines of code in the program.
- This kind of measurements prohibits refactoring and optimization. The very nature of refactoring is not changing the code functionality while attempting to make it more manageable and understandable. In many cases it means making the amount of code lines smaller. Not too many programmers will like doing work that makes the total amount of work done look smaller. In fact measuring the workload in lines of code can even encourage the ineffective coding: why use cycles, hashing of calculations if hard coding produces more lines of code and the programmer is paid per line.
- Function points are a quite reliable metric based on the number of inputs, outputs and the perceived algorithm complexity.
- Complexity. There are not too many function point experts out there and it is not always easy to explain how exactly the metric has been derived
- Function points are easy to use only AFTER the end of the project where there is not that big use of them. Function points computation is based on such a simple artifacts as number of inputs, files, user inquires, etc. Unfortunately we are living in a world of constantly changing requirements and at the beginning of the project it is quite impossible to reliably estimate all the data required for the function points calculation.
Agile measures of size
Ideal days are the imaginable amount of time that would be spent on the project if there were no interruptions (including email checking), everybody was working full time at full speed without any vacations and everything needed was present from the day one. Pros:
- The concept of ideal time is relatively simple to explain both to developers and their bosses. It is easy to provide the real world example of a basketball game that contains 40 minutes of ideal time, while lasting for 3+ hours of elapsed time
- Since both elapsed and ideal times are measured in the same units, they tend to mix
- Not everybody is eager to accept that in a real world week there can be only two-three full ideal work days
- Since team skills and the understanding of the subject area raise over time, ideal day estimations tend to decay and have to be readjusted often
- Ideal days can be difficult to sum. My ideal days are not equal to yours
User story points
Story points come from extreme programming and propose measuring the workload in imaginable units of complexity. Team assumes one of the relatively simple tasks to be of size 1 or 2 and estimates the size of another tasks by comparing them to the chosen standard. Pros:
- Estimations don’t decay over time like ideal days do. When team skills go up, its velocity changes, not the work size
- Relative values are what’s important. It is easier to reach an agreement on relative sizes, than on a real world related artifacts like days
- Pure measurements of work size - easy to sum.
- More difficult to explain. The benefits of using unitless measurements and the power of relative estimations have to be explained
What kind of work size measurements does your team use? What is the most useful metric to you?