Pricing up software development is a constant challenge and I’ve talked before about why I believe software is so expensive. But here are two key things I’ve learned over the years:

• the most expensive mistake you can make is building the wrong software
• the pricing model needs to be set up to support a great team culture, focused on delivering working software and achieving goals.

Agile frameworks like Scrum don’t talk about pricing because they assume you have a product team ready to go. And because we’re using Scrum (and other Agile frameworks) on behalf of our customers, we have three pricing models — each driving slightly different behaviours.

When you’re pricing up a software development project, choosing the right pricing model is just as important as the price itself. The model needs to reflect the relationship between the customer and developer.

In our case, we want long-term partnerships with our customers. We want to be on the same team as our clients and so our pricing model needs to reflect this.

Time and Materials

The first pricing model is the most simple. Time and Materials (T&M) simply means you pay an hourly rate for each hour worked, plus any expenses that are incurred.

Sometimes customers don’t like this approach because it can feel like there’s no certainty on the cost or outcome.

One thing to note is that changing to another pricing model won’t provide any additional certainty. Assurance will only come through how the team run the product development and the desired outcomes can often be met cheaper on a T&M basis than with a Fixed Price.

Charging for the hours spent by the team is clean and suits a contractor model, where you’re placing a degree of trust on a contractor’s experience and skills to solve a problem.

The hourly rate therefore depends heavily on the experience and skills of the contractor. Should you pay 5x the price for a junior developer to complete a task as you would for a senior developer to complete the same task?

T&M is also a good model when you’re performing research and development, as the work is expected to be trial-and-error and a T&M approach rewards the effort. A Fixed Price approach only rewards the final outcome.

Fixed Pricing

Fixed Pricing is what a lot of people assume they want, but it also relies on knowing what software you are going to build before you start the project. Any changes, learnings or improvements along the way would be added as change requests.

This model gives the best sense of managing risk, while actually carrying the highest risk that the project delivers the wrong software.

Fixed Pricing fits a project mentality where the job will be delivered and the team will then move on to other things. So it’s a common model when outsourcing.

A good way to manage a Fixed Price project is to break it down into smaller chunks (that can be Fixed Price) and allow for a review period in-between each chunk.

This can be managed through work-in-progress limits (a Kanban concept of ensuring you limit the amount of work that has been started but not yet delivered) forcing a continuous flow — where the customer is signing-off work at the same rate as new work is being started.

The bottle-neck
One of the worst outcomes of any software project is to end up with a huge amount of work awaiting user acceptance testing, which often happens when the delivery team is working faster than the customer can review and sign-off on work. WIP limits will identify the bottle-neck (often the customer) and slow down the entire production to the speed of the bottle-neck. To improve the speed, focus on the bottle-neck.

Sprint Pricing

Sprint Pricing is what you would achieve if you hire a product team. You have a limited budget so you hire a fixed number of people — giving you a fixed amount of resource.

The team will then work in sprints to achieve the goals. With Sprint Pricing, we have an agreed cost per sprint. The team are then working toward agreed objectives and the desired behaviour is to have a motivated team who are rewarded intrinsically and extrinsically by shipping software that advances the agreed objectives.

The team may not achieve everything that was planned into the sprint and remaining work would be re-prioritised into the next sprint. Daily stand-ups and sprint reviews provide visibility on the progress.

The benefit
Developing in sprints encourages continual delivery of working software, which maximises the opportunity for review and learning. Future sprints can then be planned based on actual knowledge — making for better decisions and more accurate estimates.

Sprint Pricing is charged like T&M but with a maximum budget per sprint. Like T&M, it also has a variable scope. Where it differs though is that Sprint Pricing is based on a product team taking ownership of a product and organising themselves to deliver the best outcome.

This can also be achieved with T&M but — back to my original point — the pricing model needs to be aligned with the desired behaviour and both T&M and Fixed Pricing will not drive the “on the same team” approach which you get by hiring your own team or working with a product team using Sprint Pricing.

Comparing pricing models

Who does it suit best?
T&M: Contractors
Fixed: Outsourcing
Sprint: Product teams

‍

What’s the biggest risk?
T&M: Cost overruns
Fixed: Building the wrong software
Sprint: Not shipping often enough

‍

What gets rewarded?
T&M: Individual effort
Fixed: Delivering against agreed spec
Sprint: Team effort

‍

How is technical debt managed?
T&M: Contractor may choose to keep technical debt low, resulting in higher cost initially
Fixed: No long-term view means technical debt is someone else’s problem
Sprint: Technical debt may be incurred in the short-term, especially if features are experimental. Team needs to take a long-term approach to manage technical debt at the right time.

‍

What influences the overall price?
T&M: Experience and skill level
Fixed: Locking in the scope
Sprint: Team working well together

‍

Is it good for R&D?
T&M: Encourages learning from experimentation
Fixed: Discourages failures and learning
Sprint: Encourages learning from experimentation

‍

What leadership style works best?
T&M: Emphasises experience and trust
Fixed: Emphasises planning and project management
Sprint: Emphasises trust with data, metrics and learning

‍

How is support and maintenance managed?
T&M: T&M
Fixed: Allow 20% for warranty
Sprint: Prioritised backlog allows each sprint to address most important work next

‍

Who pays for bugs to be fixed?
T&M: Customer (via T&M)
Fixed: Customer (built into fixed price, or via support contract)
Sprint: Customer (via prioritised backlog)

‍

Who pays for changes to the scope?
T&M: Customer (via T&M)
Fixed: Customer (via change requests)
Sprint: Customer (via prioritised backlog)

‍

What is the procurement approach?
T&M: Look for right skills and experience
Fixed: Arms length — i.e. RFP
Sprint: Look for right team and environment

‍

Our pricing

Because EndGame is a long-term software product partner, our pricing model reflects this positioning. Our squads work in two-week sprints and take ownership of a portfolio of products. In each sprint we’ll advance 1–5 product objectives and provide our customers with an agreed price for the sprint — which determines the pace we set while working on each objective.

Our product development squads include a squad leader, senior developers, full-stack developers, tester and designer. (We’ll be introducing our squads over the next few weeks.)

A Sprint Breakdown

When we use Sprint Pricing, we base it on a sprint breakdown (like the example below).

In this model, we’ve allowed 10% for planning and design, but we’ll often do a lot more that isn’t charged out. We’ve also allocated 60% for development but that doesn’t mean we down-tools when the time’s up. Our goal is to deliver a working increment to the software and achieving this is far more motivating to the team than simply clocking in and out.

‍