Milestone-based software development: how to keep a project on track

What a milestone is (and what it is not)

A milestone is a piece of working software, agreed before work starts, with a demo date and criteria for deciding whether it is done. The key word is working: at the end of the milestone there is something you can open, use and check.

A milestone is not a progress percentage. "Backend 60% done" tells the people who will use the software nothing, and nobody can check it. Compare these two:

• Not very useful: "Database finished and half of the API done."
• Useful: "An office user can enter an order, edit it and see it in the list, and the warehouse sees only confirmed orders."

The second one can be checked in ten minutes during a demo. If it works, the milestone is closed. If something is wrong, you see it straight away.

Why milestones protect the client

The main benefit is simple: you watch the software grow instead of imagining it. Several practical benefits follow from that.

• Problems show up early. A missing field or a wrong flow found at the second demo is cheap to fix. Found at the end of the project, it can cost weeks.
• The budget stays under control. You know how much has been done and how much is left, measured in delivered features rather than hours spent.
• Changing your mind costs less. Between milestones you can move priorities around, based on what you have seen.
• Risk goes down. If the project stops after the third milestone for any reason, you still have working software and its code, not a half-finished job.
• The people who will use the software take part. Demos are the right time to involve the people who work with the process every day. They often notice things no document anticipated.

How to define milestones

Milestones are defined at the start, during the analysis, together with the client. These are the criteria we use.

• Start from the users and the processes. Who will use the software, to do what, and what happens today without it.
• Get to a first useful version early. The first milestone after the prototype should already solve a real part of the problem, even a small one.
• Tackle the risky parts first. An integration with an external system or a complicated calculation should be checked early, while there is still time to change course.
• Keep them short. A milestone usually means a few weeks of work. If it lasts much longer, you are back to the original problem: too long without seeing anything.
• Write the acceptance criteria. For each milestone, a short list of things to check at the demo. More on this below.

An example: an order management tool

Here is how a web tool for a company that manages orders with spreadsheets and email could be split up. It is an illustrative example: the number and content of milestones depend on the project.

At the end of milestone 3 the company already has a system that replaces email for orders. If priorities change at that point, for example because an important customer asks for a portal, you can decide to bring another feature forward.

The demo: the most important moment

At every milestone we show the working software in a test environment, not slides or screenshots. The people taking part try the features with realistic data and note anything that does not look right.

After the demo there are three possible outcomes:

• Approved: the criteria are met and work moves on to the next milestone.
• Approved with fixes: small defects to fix that do not block the next stage.
• To be revised: something important does not work as agreed and needs fixing before moving on.

A practical tip: bring the people who will actually use the software to the demo. The project owner sees whether the features are there; the person who enters fifty orders a day sees whether the work is faster or slower than before.

Acceptance criteria: write them first

Acceptance criteria are simple sentences describing what must happen for a milestone to count as complete. They are written before the milestone starts, so both sides know what to expect.

They must be checkable. A few examples:

• Instead of "search must be fast": "with 10,000 orders, searching by customer shows results in under two seconds".
• Instead of "permission management": "a warehouse user cannot change prices".
• Instead of "data import": "the test customer file is imported without errors and duplicates are flagged".

Criteria written like this avoid the most frustrating argument in a software project: "I thought that was included."

When things change

Changes during a project are normal, and often a good sign: the software in use has brought real needs to the surface. The trouble starts when changes come in without anyone weighing their effect on time and cost.

That is why every new request is written down and assessed. The usual options are:

• add it to the current milestone, if it is small and does not move the demo date;
• move it to a later milestone;
• swap it for a less important feature, to stay within the same budget;
• add it to the project, with a time and cost estimate to approve.

What matters is that the decision is made together and put in writing.

Signs that a project is drifting

Whether the project is run by us or by someone else, these signs deserve a conversation:

• you have not seen working software for weeks, only progress reports;
• progress is reported in percentages ("we are at 80%");
• there are no written acceptance criteria;
• demos show static screens instead of running software;
• new requests are accepted without talking about time and cost;
• you have no access to the code or to a test environment.

Milestones, payments and the contract

Milestones also work well for the financial side. A common arrangement is a deposit at the start and a payment when each milestone is approved: the client pays for verified results, and the developer has a predictable flow of work and payments. It is an option to agree in the contract, together with what is delivered at each stage.

The contract should also cover access to the code repository, ownership of the code and what happens if the project stops. These are details you hope never to need, but they make the working relationship calmer.

How we work at Kineto Soft

Every project starts with an analysis of the processes and a clickable prototype. Then we work through agreed milestones, with a demo of working software at each stage and regular updates in between. Code ownership, repository access and handover are set out in the contract.

You work directly with the developer who writes the code, so questions asked at the demo get an answer straight away. This way of working applies to business tools and web applications, mobile apps and SaaS products.

Frequently asked questions