Agile Estimation Using Functional Metrics, Part 1
by Thomas M. Cagley Jr.

The term agile has come to mean many things to many people.  The definitions and connotations range from how work is organized within a project to a description of the speed at which work is completed or alternately a radical rethinking of organizational culture.   Regardless of how you define agile I would suggest that we all would agree that agile methods are now maturing.  Part of the process of maturing is the incorporation of best practices from other methods and frameworks creating a hybrid.  The fringe is influencing the center and the center is influencing the fringe.  The hybrid is at once better than any of the absolutes and threatening to those who believe in absolutes.

Estimation has been a lightning rod for the discussion all methods (agile, waterfall, iterative or water fountain) with the issues of predictability and standardization radiating outward.  Because of the controversy this is an area where a wide range of hybridization has always occurred.  Organizations adjust techniques to fit governance structures, culture and risk profiles.  There is no one size fits all solution.   This paper provides a path for incorporating the use of function points into agile estimation techniques.  The process will yield an estimation process that combines one part functional metrics, one part parametric estimation techniques with two parts agile estimation (heavily influenced by Mike Cohn).   I would suggest that functional metrics provide a path for incorporating the best practices of robust software sizing with the collaborative techniques championed by the agile community in a manner that increase standardization without ignoring the principals of the Agile Manifesto.

Budgeting, Estimation and Planning

I’d like to begin this discussion by challenging your preconceived notion of estimation as compared to the activities of budgeting and planning .  These three concepts are sometimes thought of as being synonymous however I believe it is important to understand just how different these concepts are.  Each has different inputs and outputs, uses different tools and techniques and is generally used by different groups within the organization.

A quick overview of the macro differences are:
•    Budgeting
o    Defines how much we have to spend based on the influence of scope
o    Tends to ignore the cone of uncertainty
•    Estimation
o    Presents an approximation of effort and duration based on size and project nature
o    Focused by the cone of uncertainty (a range based on knowledge)
•    Planning
o    Defines tasks and allocates resources
o    Focused on the narrow part of the cone of uncertainty (a much smaller range)

Estimation, planning and budgeting might be related but they are certainly not the same.  The use of functional metrics in agile estimation is targeted at the estimation layer of this three layer cake but provides support for planning.  Developing a basic understanding of the components of estimation (we are going to ignore budgeting as bastion of guesses) and its relationship to sizing is critical to using these techniques.

Estimation

Estimation is several parts science and a least one part magic.  This strange confluence of science and magic defines the transformation of requirements size, skills, people and equipment into how much the project will cost and how much effort it will take .  The whole process of transformation is bound by a cone of uncertainty.  Uncertainty builds boundaries around the false precision of the estimate providing a range around the estimate based on what is known and unknown.  Collaborative estimation techniques are good at increasing team knowledge while reducing the amount of self-deceit that can occur when knowledge is discussed.

The amount of art increases as the estimation discipline is replaced by the planning discipline.  The art of planning matches specific tasks with people thru a process of assignment.  In a perfect world estimates and planning would be able to be done together in seamless workflow but estimates happen generally earlier in the project lifecycle before you can decompose work into tasks which is required for planning.

The simplest form of any estimation model, human or tool based is a mathematical mash-up of size (implied or counted), team and organizational behavioral attributes and degree of difficulty (technical complexity) applied to a productivity signature.  As the level of sophistication in the mathematics increases tools SEER, SLIM or KnowledgePlan make sense.  Other methods raise level of collaboration and do any of the required math in the heads of the participants.  These techniques include Delphi, analogy or planning poker. The process in this paper splits the difference leveraging collaboration to increase participation and self knowledge while suggesting the use of a simple spreadsheet based parametric models to increase consistency and standardization.

Sounds simple, right?  Estimation has been a nagging pain in every IT manager’s backside since a user asked how much a project would cost and when it would be done.   We have gotten pretty good at budgeting using techniques like “x number of people times 20 hours in a day and you’ll get something next year” methods.  It’s when we try to figure out how much functionality will be delivered in real life that  things start to break down or least get very, very complicated.

There are three main categories of problems that cause estimation to be problematic in the real world.
1.    Uncertainty: how much do you know about what you’re building?
2.    Self knowledge: what you do really know about yourself and your team?
3.    Consistency of method: do you have a process for estimating?

Possibly related posts: (automatically generated)