The Almighty Point: A Formulaic Approach to Software Engineering Decision-Making in an Agile World

I’ve been engineering, leading, maintaining developing, and delivering software projects and products for 23 years. Full life cycle from waterfall methodology to various flavors and hybrids of Agile methodology. No team structure has been the same, and I’ve played just about every role there is to play to one extent or another.

But one thing underlies every second of my experience: money. Making money, saving money, predicting money, spending money, budgeting money, investing money, value of money. That may sound cold, but that is the core of the software industry…any industry! If we make the world a better in the process, all the better!

How this works in a traditional engineering operation is clear and well-established. Time is money. The value of that money is determined by how much it saves or how much it makes minus the cost of the time to deliver it.

Along comes Agile. And now we are not estimating features in hours anymore. You can’t say project cost equals engineering rate per hour times hours plus expenses to deliver. Time and materials project. It doesn’t mean we can’t provide estimates. It doesn’t mean we can’t estimate delivery dates. Agile does not excuse us from this. It might even improve our ability to do this, but time is not the key to cost in Agile.

The Cost of a Point

In Agile, story points are a relative value to estimate the level of effort for a feature. Effort is money. So, by proxy, POINTS are money. They have an actual dollar value. Here’s a simplified formula. First, a few variables.

Velocity?is the number of points completed in a given period of time divided by the number of sprints in that same period.

Total Team Rate?is the sum of the pay rate of every team member prorated by how much time on average per day they dedicate to the team. If you have four developers dedicating all of their hours to a sprint averaging $60 an hour, 2 testers split with another team at $50 an hour, a business analyst full time at $45, and a scrum master at $45 then the total hourly rate for the team would be $380 an hour.

Hours in a sprint. A sprint is the number of days for an engineering iteration. At the end of the sprint, you have a new release. Two weeks is common. That’s 80 hours.

So, with this formula, you could roughly calculate the cost of a point:

(total team rate * hours in a sprint) / velocity =?cost of point

And when you know the cost of a point and how many points a feature takes, you know?Total Engineering Cost?of a feature. We’ll need that in the next formula.

The Value of a Point

But in a business, we want to know what we get for that money. The business executives are investing capital into engineering to increase the value and marketability of their products and services or decrease the operational costs (overhead) of the company so that they can show profit. So, we’re talking about the value of a point.

This is how I would calculate the value of a point:

((Operational savings + profit) – total engineering cost ) / total points =?value of point

We want a point to either cut costs or increase profits, and we want the sum of the savings and profit to be greater than the cost of the point. That’s the goal of a software operation. There are other factors of course, like how much does it cost to run and secure the managing a software? How much does it cost to market, sell, manage, etc.? But the core is the money. And we measure value in dollars.

There’s a magic here that I cannot speak much to, and that is how you tie profits (business value) to software features. This requires measurability. I see companies and government entities working hard to measure the value of the software to the business. That is a topic for another time and another writer.

And NOW We Can Make Decisions!

When we know the cost of a point and we can project the value of a point, then we have the ability to make good decisions. There are many kinds of management decisions in software including business decisions, product decisions, and engineering decisions.

Product?develops and proposes features.

Engineering?estimates the points (level of effort) to produce the feature, and if requested, builds the feature.

Business?decides which features to invest in.

Ultimately, every decision made about software comes down to two questions.

1. Does it make us money?
2. Does it save of us money?

NOTE: There is a third question about decisions that I personally care about: Is this good for the world? But that’s another topic.

There are books written about how to measure questions 1 and 2, but that’s what management is about. Isn’t that obvious? Well, not to everyone.

Example. I have worked for multiple companies where decisions about software were not made with these two questions in mind. The most common one is in modernization. Modernization can decrease costs and add value. But it is not a given. There are companies out there doing great with 10, 20, 30, 40, 50-year-old technology. I’ve seen engineers convince companies and government to spend millions of dollars to modernize a system because they wanted to work with the latest technology, but without producing a shred of evidence that it will save money or increase value. Keeping up with the latest Javascript framework does not equal value, and even if it did, you’d never keep up with the framework du jour.

The Role of the Engineering Manager

Currently, I’m an engineering manager, so that is my primary frame of reference. The job of the Engineering Manager is to deliver the software and to control the cost of the Point in the process.

Cost Factors

What are factors that affect the cost of a point? Here are a few:

• Time?– How long does it take to produce a feature? How much time in their day can be dedicated to engineering?
• Maintainability?– How much work does it take to maintain the feature? Design is the biggest factor in creating maintainable code.
• Quality?– How many bugs do they introduce?
• Clarity?– How clear the requirements?
• Hiring?– How many people do we hire? How many of each skill level and skill set do we hire? Will they fit the culture? How much do we pay?
• Process?– Does the engineering process support high performance?
• Growth?– Are the engineers getting what they need to get better at their jobs?

The better the developer, the better the process, the better the design, the better the requirements, the optimal number and skill-level of developers, the fewer the interruptions the less time it takes to produce a feature…

and the lower the cost of the point.

Bugs

I want to give a special shout out to bugs. In agile, we don’t give point values to bugs, because fixing bugs is a zero sum AT BEST. The more bugs to fix in a sprint, the less time we have to spend on features, and that means that a point becomes more expensive if you think about it in terms of hourly rate. That $380 an hour engineering rate spent on bugs means those few precious hours spent adding value to the product ultimately cost more money. The exception is in consulting. If a consulting company is hired to clean up the bugs, then the more bugs they fix and the more bug-proofing they do, the more value they bring to their work. The most valuable bug is no bug.

Time

There is no escaping time, not even in Agile. It is still a key component in our formula. (total rate * hours in sprint) / velocity = cost of point. Time spent on bugs. Time spent backtracking because of poorly written or incomplete requirements. Time spent due to inefficient design. Time spent in meetings, supporting production issues, searching for and providing information.

Levers

As an engineering manager, I have levers to pull to keep the cost of the point down. Here are a few:

1. Hiring?– When I hire, I need to find that balance between quality and cost. So much of software can be developed by mid and junior tier professionals as long as I have a few seniors to guide us. It would not be a good value to hire only senior developers. I also want them to be skilled, professional, and easy to work with.
2. Retention?– Turnover is very expensive. I want to hire people who are interested in staying for a good amount of time and I need to give them reason to stay. I want them to enjoy their jobs, feel valued, have work life balance, completive pay and benefits, and any number of other factors that support people in staying with the company. And when people stay, hopefully, they get better at their job.
3. Process?– The best people in the world can still struggle to execute if the engineering process is poor.
4. Interruptions?– I want my engineers spending their time building software. Any activity that interferes with that or does not optimize that time, makes the point cost more. For example, if my team is receiving constant DMs from other departments for information, then I need to make sure they have ways of getting that information without pulling time away from developers, like providing an online knowledge base. Meetings. Does this meeting add value to the point? Does it lower the cost of the point?
5. Professional development?– I want my developers to get better at their job. That means mentoring, training, skills tracking, assigning stories strategically.
6. Clear requirements?– Some developers handle ambiguity well. That has value. But stories should be defined in a way that is clear to every one on the team and covers all the bases; otherwise, what we produce might not satisfied what the business stakeholder actually expects…and when a feature gets sent back because of poorly defined requirements, that raises the cost of the point.

Is the Point the Way to Go?

Two of the biggest complaints about Agile operations is that no one seems to be able to say when something is going to be done or how much it’s going to cost. But when you know the velocity of a team and the cost of a point, these questions become more answerable.

Agile, in this context, may make it more accurate. The whole point of Agile is to mitigate the inevitability of change in a project. Waterfall approaches this by front loading as much work of the planning, analysis, requirements gathering, and design as possible so that the software development life cycle online needs one round moving forward through the cycle more than it moves back. But inevitably, waterfall fights scope creep. Why? Because sometimes the scope of a project cannot be known until the project is underway. Critical features may not become obvious until certain project milestones have been achieved. This is why project estimation has “fudge factor” in waterfall. There’s an old adage: When you’re done estimating a project, multiple it by three.

Agile address this with smaller more frequent iterations of the software development life cycle, so that as a project evolves in unexpected ways, not as much time is wasted adjusting. Estimating with Agile is out of the scope of this post, but in my experience Waterfall estimates fail way more often than not. And Agile leaders resist giving full estimates, because it’s hard to estimate something that you expect to change.

But the secret weapon in Agile for decision-making is the almighty Point. When you know the cost and value of a point, when you know what your engineering team can deliver in a sprint, and when you know how many points a feature is, you’ve got a formula! You’ve got a shot!