Agile point-based pricing
There are three rules for success when building digital products:
- There is no substitute for actual functioning software
- There is no substitute for actual functioning software
- There is no substitute for actual functioning software
:)
Non-tech companies (like the one I work for) increasingly rely on speedy software delivery to achieve important business goals. Agile delivery is now being institutionalized within enterprises so that they can roll out actual functioning software as quickly as possible. These enterprises often rely on 3rd-party suppliers to build their software. The working agreements between businesses and their software delivery suppliers often rely on either Time and Materials or Fixed-bid contracts.
Traditional contracts don’t work for Agile
Attempting to adopt Agile while still using contracting models centered around paying for time discourages true Agile adoption.
- Software delivery teams are pressured to burn hours gathering requirements up front in an attempt to verify detailed project scope, at the expense of delivering functioning software.
- Once this initial (likely inaccurate) scope is defined, there is often little recourse for the customer to change requirements once delivery is underway (particularly with fixed-bid projects).
- A change in requirements could entail a dreaded Change Order which uses more hours to redefine (likely inaccurate) scope and plenty of administrative overhead to process the Order.
- There is no real distinction between work that delivers functioning software and work that doesn’t.
Point-based pricing: A new funding model for Agile delivery
Story Points are the Agile currency for complexity. Software development teams use Story Points to document the complexity, effort, and risk inherent to delivering features.
Story Points are a natural billable unit:
- They can be aggregated into batches and purchased in bulk
- The price per point is negotiable
- Point criteria outline a shared understanding of complexity and risk between customer and supplier
An Example
Let’s say we’re a software development firm and a customer has engaged us to build a new blogging platform. We figure that the overall project is a “medium-sized” project, which translates into a bucket of 500 points. Our standard rate is $500 per point. After a little bit of negotiation, the customer purchases 500 points at $490 per point. Once the points are purchased, the software delivery team begins writing user stories with the customer, building a product backlog, writing code, and rolling out features.
Each delivered story debits from the bucket of points. For example, a group of stories about user account management (create an account, log in, change password, etc.) consumes 50 points, leaving 450 for remaining features.
After 200 points are spent, our customer feels enough basic functionality has been delivered to launch a beta version to the public. There are enough features outlined in the product roadmap (and loosely defined in the product backlog) to consume the remaining 300 points.
However, our customer begins to notice that the majority of the user-generated content on their blog platform is about baking recipes. By the time they identify this pattern, they have 50 points left to start introducing new features to support the content that is organically generated on their platform. They work with our delivery team to define new stories and refine existing ones to explicitly support user-generated recipes. The remaining points are spent delivering these stories.
This example may not seem that much different than a classic contract that simply buys hours that the delivery team bills against. However, there is a critical difference: user stories (features) get points, bugs do not.
Pay for features, not for bugs
User stories define product features and story points are the development team’s input into how hard it will be to build these features. Once a story is done and delivered, its point value can be billed to the customer. Bugs, whether found during development or in the live application after launch, are given no point value and major bugs must be remediated immediately before work can continue on stories.
- Since bugs aren’t assigned points, the effort to remediate them isn’t directly billed to the customer.
- User story work is paused for however long it takes to remediate major bugs.
The end result: customers are paying for completed features free of any major defects.
Agile Contract Criteria
Any contract that aims to fund development using point-based pricing must establish a few core principles:
- Point value definitions
- Bug severity definitions
- The definition of “Ready”
- The definition of “Done”
Point-based pricing contracts must also include a provision that customers will only pay for user stories, not for bugs.
Point values
Points are defined from the software developer’s point of view. Points are applied to User Stories and gauge how hard it will be to build the story.
Bug severity
Bug severities are defined according to how severly a bug impacts the value of the product. This can range from a broken feature that interferes with the everyday behavior of an application to something that could cause financial loss to the business.
Definition of Ready
Developers must only accept stories that are ready for development. “Ready” should be defined in very concrete terms that outline the elements of a User Story that must be present prior to acceptance by the development team.
Ready means:
- A User Story is created
- The story includes a statement of the value proposition of the story from a business objective
- The story includes Acceptance Criteria (fine-grained testable steps that, once executed, mean the story is complete)
- The story includes wireframes, user flows, design comps, sample data sets, and any other supporting documentation as necessary
- The story is given a point value by the development team
- The story is prioritized into a product backlog and pulled into a sprint by the team
Definition of Done
The customer must only accept features if they meet terms agreed between the customer and the supplier. “Done” might include requirements around test automation and code coverage as well as manual testing.
Done means:
- A User Story has been made Ready
- Features defined by the story have been developed
- These features have been tested and all major bugs have been remediated
- These features have been accepted by the Product Owner
- These features have been launched into production
Ground rules
- Every point has a price
- Every user story has a point value
- Points can be grouped into larger sellable units (Small bucket: 250 points, Medium bucket: 500 points, Large bucket: 750 points)
- Bugs don’t get points
- Bugs must be fixed before user stories can considered done be delivered
- Suppliers receive payment once stories are done and delivered
FAQs
How much is a point worth?
Suppliers will need to price points to accommodate bug remediation as well as any administrative and setup tasks that their teams will need to perform throughout the life of an engagement. Once these overhead costs are considered, labor costs and desired margin determine the rest of the price per point.
How can suppliers make a profit?
By delivering software with as few bugs as possible and fully orchestrating infrastructure creation and management. Suppliers can differentiate themselves by exercising solid DevOps practices and assembling high-performing teams that are focused on one customer engagement at a time. Suppliers will likely have a minimum point count (for example, 100 points) for engaging with customers. Point values are negotiable and customer discounts might be provided for purchasing larger bundles of points.
How many points should a customer buy?
No customer will ever decide to go into a supplier engagement blind to scope and related costs. The customer should spend *some* time up front roadmapping features into deliverable milestones and T-shirt sizing the effort for these milestones. If the customer has Solutions Architects in their organization, then the SA’s can work with product owners to come up with an estimate for how big the bucket of points will need to be. If no SA’s are handy, then the customer can fund a separate up-front effort with the supplier to roadmap deliverables and determine which bucket size they should buy.
What could go wrong?
A few things could subvert a points-based pricing engagement…
Keys to success
A high-functioning Agile supplier paired with a customer that understands digital product ownership will produce good outcomes for both parties.
Suppliers will succeed if…
- They have a strong Agile delivery discipline and can quickly and easily establish DevOps pipelines that routinely deliver safe and stable software at a rapid pace
- They can maintain a dedicated cross-functional team for the life of a project
Customers will succeed if…
- They have a strong product ownership skill-set: defining product vision and establishing detailed requirements through user stories
- Product owners devote daily hours to validating the direction of the product and are immediately available to answer questions as they arise from the delivery team
The goal of a point-based pricing contract is to incentivize the right behaviors for successful software creation. Customers and suppliers with the right skills acting in concert and playing by a few simple rules should greatly improve the value of software to businesses and end users.
