Software Estimation in an Agile World

Developing a defendable software cost estimate has always been a challenging endeavor. An accurate software cost estimate begins with an accurate software size estimate! This can come in many flavors, such as functional size assessment (i.e., function point count based on International Function Point User’s Group [IFPUG] rules), analogy to a previous application, or subject-matter expert opinion. Next, the analyst will make assumptions on the amount of software reuse, and whether Commercial-off-the-Shelf (COTS) tools will be used. Once the software size and reuse are factored together, an equivalent size, in either function points or Source Lines of Code (SLOC), can be derived. From that point, a productivity measure, usually in terms of function points or SLOC per person-month, can be used to translate equivalent size into development effort months. Parametric tools, such as SEER-for-Software^®, TruePlanning®, or COCOMO^® II can be used to apply variables such as application complexity, development team capability, and requirements volatility, as well as rapidly produce cost, effort, and schedule estimates.

Function Points

This blog will be written from the perspective of using function points as the sizing mechanism, as they are independent of technology and a standardized metric (ISO/IEC 20926:2009), based from the user’s perspective. Function points were defined 40 years ago by Alan Albrecht at IBM and have been refined over time. While there are various flavors of function points, the most recognizable are IFPUG, which identifies internal and external data groups, as well as input, output, and query transactions[1]. Each function is given a specific weight, which is influenced by complexity (i.e., fields in a data group or data groups in an output transaction). In recent years, Simple Function points (SFP) have become popular, providing a single weight for data elements and a separate weight for all transactions; thus not requiring functions to be evaluated for complexity, to separate internal/external data, or to identify type of transaction.

Agile

Over the last twenty years, Agile has become the most common software development methodology. The Agile methodology is generally characterized by iterative, feature-driven development, time-boxed sprints, focus on customer value, and putting a viable product in the hands of users as early as possible to shorten the feedback look. Agile teams have evolved to develop their own sizing approach. Features are broken into user stories and the Agile teams develop ‘story points’ for each story, which is a relative value of its size and complexity. A set number of story points are implemented per sprint cycle. Features, listed in the product backlog, also are often refined or added during the development period. We have found requirements elaboration meetings with Product Owner and Business Analysts are a very effective means to identify additional scope that is not immediately captured in user stories.

Are Software Estimates needed anymore?

As you can imagine, this has created some friction between Agile development teams and the software estimation community. Within a specific organization, Agile teams (trains) have a specific team size comprised of business analysts, designers, developers, and testers. The sprints are also of uniform length, generally two to four-week periods. Thus, Agile enthusiasts would argue, the software estimate is simply the product of number of planned sprints, cost (or labor hours) per sprint, and number of Agile trains.  However, this approach has a few shortcomings. It fails to consider the project’s scope and funding constraints. Additionally, story points are not a standardized process and differ across vendors and organizations (and are generally not accepted by oversight organizations as a valid sizing metric). Finally, this approach doesn’t recognize that the estimate informs the budget, which in turn determines the schedule.

However, traditional software estimation methods that build estimates to cover multiple years of development are not very useful to Agile projects. This is for the simple reason that epics and features are generally only well-defined for a short period, of a few sprints up to a year. While it is possible Agile teams will understand their scope over a longer time period, our experience has not shown that to often be the case.

We see the best approach to software estimation in an agile world as beginning with an understanding of features that will be delivered. Features, because they are user-defined functionality, fit well into traditional, functional sizing approach, using either IFPUG or SFP counting rules. The estimation process also has to be agile (little “a”) to produce cost estimates quickly that can be useful to the program sponsor and support short term budgetary requirements.

Best Practices

We have identified several best practices that enable effective software cost estimation. Leveraging function point analysis led by trained and/or certified experts results in a repeatable functional size estimation process. Establishing a metrics collection (benchmarking) program to collect programmatic information, scope, effort, and size is vital to establishing an organization’s range of delivery (productivity).  Training estimators to speak in language familiar to Agile teams is helpful in gaining support and creating a trusting and collaborative environment. Agile teams are comfortable discussing Minimal Viable Products (MVP), backlogs, user stories, and features. They are not comfortable discussing Final Operating Capabilities, project requirements, and SLOC or Function points. Thus, it is important to train the estimation community to connect with their Agile clients in a common language. We also stress requirements elaboration meetings, as planned functionality will not always be readily available, are the ideal way to validate the scope of the project.

Please contact Logapps at info@logapps.com for more details on how we can assist your organization with your software estimation needs.

---

[1] Herron, David and David Garmus. Function Point Analysis: Measurement Practices for Successful Software Projects. Addison-Wesley, 2001.