In this post we include the article Agile Estimation – What’s the Point? published in IFPUG MetricViews (the IFPUG publication window to the world of metrics). In this, Ian Brown, Director of Operations and Systems Analysis of Galorath, is next up with some thoughts on the pros and cons of Agile story points, introducing a new Agile sizing measure called Agilon. MetricViews edition ‘Sizing up Agile’ (available in PDF format), includes this and other articles on the use of functional sizing and other metrics in an agile development environment.
Agile Estimation – What’s the Point?
Agile is at the forefront of many software development discussions these days. Everyone is asking for it, everyone wants to be Agile. At the same time, there is quite a bit of misunderstanding and misinformation about how Agile works in practice, especially when it comes to estimation. I’ve seen situations where customers ask for organizational velocity, average velocity, or similar metrics for contractual reasons. These requests are problematic and can lead to poorly informed decisions.
In other situations, estimation of software development effort and cost must be done at the macro level to create a project budget or a proposal bid, which is very difficult to do with most Agile estimation techniques. This article highlights Agile estimation principles, discuss where they work, and note where some challenges arise. Then we can discuss another estimation approach that can help overcome some of these challenges.
In my two decades of experience in estimating software development projects, I have learned that two maxims are critical.
- Any approach to estimation MUST enable communication when changes to a project can possibly impact cost and schedule of delivery. Unless you’ve got unlimited budget and no time constraints, you must be able to explain the cost and schedule impacts of changes to project requirements and/or development. Communication, expectation management, and customer buy-in are critical to project success.
- Size matters. Software estimates need to be based on some sort of sizing unit. It’s an industry best practice that too often gets ignored or overlooked. Estimating in level of effort (hours), although widely practiced, does not enable effective communication. Hours is NOT a unit of size. For example, let’s estimate the trip from Baltimore, Maryland to Washington, DC. I estimate an hour and a half, but you say it should only take an hour. How do we reconcile that? We really cannot. It’s highly dependent on the route, our speed, traffic, weather conditions, etc. But if we frame the discussion in “miles,” then we have a common unit of measure with which to have an informed discussion.
“Typical” Agile estimation doesn’t exist. The Agile manifesto values individuals and interactions over processes and tools. The twelve principals encourage Agile teams to reflect on how to become more effective, then to tune and adjust its behavior accordingly – which applies directly to estimation practices. Agile estimation cannot be defined by a specific approach, technique, or tool.
Two key concepts, however, are consistent across Agile estimation methods. First, estimation is a collaborative activity. Teams participate in estimation and planning activities together so many perspectives and experiences can be considered. Second, estimates are iterative. Each additional iteration is informed by experience, lessons learned, and information gleaned from the previous sprint.
We can’t cover all Agile estimation techniques in a single article, so let’s focus on one approach that is widely used.
Story point estimation starts with user stories – short descriptions of a desired function written from an end-user perspective. For example, “As a user of this system, I want X feature so that I can accomplish Y.” User stories determine what functionality will be built. Product owners capture requirements from the business/customer then work with Agile teams to develop user stories and prioritize. Agile teams assign story points sizes to user stories to plan and deliver these priorities.
The Agile team selects what is called a “reference story” and determine the point value of that story. All other stories are evaluated against that reference. No “standards” exist for story points weighting. They are determined on a team-by-team basis.
Neither one of these is wrong, assuming that the teams collaboratively developed the weighting. The key point of this illustration is that story point values are team-specific and typically evolve as the team works together over time. No two teams are going to define story points in the same way. Size comparisons between two teams is an egregious error.
This type of estimation approach works well for a lot of Agile teams. Over time they can become very good at predicting sprints. Data feedback from the previous sprint during retrospectives provides the opportunity for immediate corrections. The relative nature of story points allows teams to tailor and calibrate the size unit. Collaboration and iteration with all stakeholders encourages communication and expectation management.
In some situations, however, story points and velocity do not work well and are insufficient to meet stakeholder needs.
- Initial estimates/project budgets. Story point sizing cannot be applied effectively to estimate a budget early in a project life cycle.
- New Agile development team. With a new team, actual velocity is unknown. Agile teams usually take a few cycles to normalize their estimation techniques. Agile estimation resets any time something changes on a project, even with the loss of a single team member.
- Portfolio management. Effective IT productivity metrics require a standardized measure of software size. As we’ve discussed, story points are completely inappropriate for this. This applies to competitive bidding for development projects as well. Trying to compare bids that have completely different sizing metrics is simply not possible.
Other situations and circumstances can lead to less-thanoptimal application of story point estimation methods.
- Using points as a proxy for hours
- Treating velocity as productivity
- Defining story points differently between customers and the team
Given this range of challenges, I’d like to explore some ideas for estimating software size that can either supplement or replace the use of story points on Agile development projects. If you’ve got Agile estimation techniques in place that work for your team, I would never recommend disrupting that. However, if your team has difficulty applying Agile estimation consistently or is frequently subjected to some of the other pitfalls, I would recommend an alternative approach to sizing.
One idea that is frequently discussed is function point sizing. It’s an ISO-certified (20926:2009) industry standard software sizing measure based on functionality described from the users’ perspective. I am going to assume you are familiar with function point concepts.
Customer-centric sizing, standardized and ready to go… sounds great, right? Unfortunately, function points have a widespread problem in the Agile world: perception. Many Agile enthusiasts don’t believe that function points can work in an Agile environment, even if they have never actually tried it. So how do we deal with this bias against function points and still address the challenges of Agile estimation? This is something a group of estimation experts thought long and hard about, and they came up with a concept called Agilons.
The Agilon sizing method is similar to function points but applied specifically to Agile software development projects. There are five types of Agilons.
- Internal data – managed by the application
- External data – referenced by the application but managed by another application
- Inputs – add, change, delete internal data
- Outputs – reports, calculations based on internal or external data
- Inquiries – search and retrieval of internal or external data
Agilon complexity generally can be determined by the number of data elements involved. However, this detailed information is not always available when an estimate needs to be completed. In this situation, we should simply make an assumption about complexity and document it for future review and discussion. One common technique is to assume that all functions are average complexity.
Here is the standard Agilon weighting matrix:
- This might look familiar to you. It’s not quite a Fibonacci sequence, but it’s pretty close. Let’s take a look at a real user story and apply the Agilon framework.
- As a customer I would like to have the ability to search for and reserve a hotel room in order to spend the night somewhere.
- Data element details are missing, so we’ll just assume “average” complexity. Analyzing this user story reveals multiple Agilon types that need to be decomposed.
In this scenario, if my team’s velocity is around 18 to 20 Agilons per sprint, we’re good to go! If not, we should break the user story up into smaller pieces to make sure we can complete those pieces in a single sprint.
So how does this approach really address the challenges of story point estimation? Let’s revisit some of the most significant pitfalls of estimating with story points.
- Generation of estimates to establish initial project budgets. With Agilons, estimates can be fully documented and explained, even in the absence of requirements, and then can be used to facilitate communication. You can establish a project baseline, but when conditions turn out differently than anticipated, the estimation methodology becomes a mechanism for communicating what has changed and why, as well as what can be accomplished.
- Formation of a new development team with no history together. Applying Agilons as a standardized sizing metric, combined with good historical data or a parametric model, you can provide estimates that stakeholders can understand. You can tailor the estimate to the combined experience of the development team.
- Establishment of organizational portfolio management with consistent metrics across projects. Leveraging Agilons as a standardized size measure across an IT portfolio empowers consistent productivity and quality metrics across an organization, offering real possibilities for improvement.
Ian Brown, Director of Operations and Systems Analysis, Galorath Inc., has over 20 years of professional experience in the areas of management consulting, IT systems analysis, IT performance measurement, metrics program implementation, software process improvement, and cost estimating and modeling. Mr. Brown has been a frequent speaker at national software industry conferences and his “Controlling Software Acquisition Costs With Function Points and Estimation Tools” has been published in Crosstalk: The Journal of Defense Software Engineering. He also received the DCG Innovation Award at the 2009 International Software Measurement and Analysis Conference for his presentation entitled “The Zero Function Point Problem.”
The post IFPUG MetricViews: Agile Estimation – What’s the Point? appeared first on IFPUG.