The Agile Manifesto spawned a revolution in software development almost 20 years ago and continues to change a generation of product developers. From the humble beginnings of 17 software development disrupters penning a manifesto in Park City UT to today’s scaled agile frameworks and a myriad of prescriptive methods, agile has taken over center stage from yesterday’s “waterfall” development approaches.
As with any cultural change (I’d argue that true agile is a culture), there’s been clashes of old school thinking and new school progressiveness…
Old school “staples” for software development included estimating, budgeting, on-time and on-budget project tracking, EVM, scope management, and measurement. Not only do some of these concepts strike panic in agile developers, some have even sparked new “anti-” movements (e.g., #noestimates.) More than once I’ve heard developers refer to “old school bean counters” and “out of touch C suite execs” when the words estimates or budgets are mentioned.
Yet as much as some agile creatives like to assert that estimates are futile (how can one estimate creativity?) and early failures are critical to innovation (it can take 3000 ideas to deliver the right one) – corporate America still runs on dollars and days (budgets and schedules.)
One way forward that has proven successful that satisfies the needs of executives (who want to know progress and early ROI) and also project teams (who are challenged to measure delivered business value) is called “Unit pricing.”
Here’s the approach:
Step 1: Revisit completed projects: Evaluate and measure past completed product releases: delivered software product size, team effort (person hours) to deliver the release, estimated rework (%), number of sprints, team size, cost.
Having such a historical basis for unit pricing is useful, however, publicly available databases such as the Development and Enhancement project repository (International Software Benchmarking Standards Group – ISBSG) can suffice if you don’t have your own historical data.
Step 2: Generate a high level “budget” for your new product delivery (release or project), by first guesstimating a “relative” size (ballpark) for how big could be the software. Some companies use a rudimentary t-shirt sizing scheme (xs, small, medium, large, xl, xxl, etc.) as a comparator.
This estimated size will be wrong from the get-go, but selecting a “ballpark size” gives you an upper limit of software size to guide the project. The overall budget is derived by taking your best guess of the size (in function points) and the applicable unit price in $/FP (as derived from the actual costs of similar past projects.)
Management will then approve the project (or release) based on this “guesstimated” size and budget, and the project begins. (Budget $ / size in function points provides an initial agreed upon rate of $/FP. This can be used as a payment mechanism and/or a gauge of project progress.)
Step 3: Given the “bucket” of project money and an assumed, not to exceed (maximum) product size, you’ve got the unit pricing that you’ll use when bits of software are delivered.
Step 4: The scope of the project is the product backlog as defined by the product owner /customer. (Note that the size of the product backlog is unknown at this point, however, as user stories are completed, they will be sized and recorded along with the sprint they were part of. At the end of the project, the size of the completed user stories will be known.)
Step 5: As bits of software are delivered, they are sized (in FP.) The cost is calculated as the budgeted unit pricing * FP) – and both the size and cost are recorded for the delivery. Costs are tallied and subtracted from the original budget. If a product backlog item is returned to the backlog at the end of a sprint (partial completion), there is no measurement of its size or cost.
Step 6: During the project, the team gets to focus on product development and delivery rather than estimates. However, at any point in time, team members and executives can get a glimpse of where the project is at by looking at the delivery sizes and costs to date, and gauge how muchprogress is being made. Creating product burndown charts (costs expended to date out of the original budget amount) and depicting the growing product size can be done quickly and easily.
The agile teams stay focused on being creative and developing product. At the same time, executives have their progress reporting (delivered size, budget spent to date, remaining budget.) This is a modified approach that follows concepts outlined in the Finnish Software Measurement Association (FiSMA) northernSCOPE method (www.fisma.fi.)
What do you think? Would unit pricing and progress tracking be a way forward for your agile projects?
Comments, brickbats (an old school word for criticism), ideas welcome.