Which features belong in the first release?

What belongs in a first release is set by the record under each line, not by price: a line needing a record nobody keeps today goes in, one your records already produce does not. The cut falls between a record and the reading taken off it, never through the middle of one. At the dental clinic every appointment opens against a named step of the plan, and reordering steps carries the calendar along.

The first-release question is asked of the record, not of the feature list

This piece starts after the list has been written. How a list gets ordered, which sentence describes the physical condition of the work, and how you say what one record stands for are all a separate job, and how to describe what you need to a software team covers it. Here the unit of record arrives as an input. The question is the one that comes next: given a need that has been described properly, where does the first release get cut?

One question does the work, and it is asked of every line separately. Does this line require a record that nothing in your business currently holds, or does it produce something that could be read off a record you are already holding? Two answers, two different scoping decisions, and neither of them is visible on a price list.

Take a concrete case. When work started on the dental clinic CRM, the practice was running general-purpose booking software. It held the hour of the appointment. It did not hold where a course of treatment had got to. Three pieces of information were therefore assembled from three places: the calendar for how far along a treatment was, a ledger for what had been billed, and somewhere else again for the month-end figures.

Turn that situation into a quotation and it produces three lines. Treatment tracking, one line. Invoicing, another. Reporting, a third. They look like three separate builds, they get priced as three separate builds, and when the budget tightens two of them are struck out. That is the moment scope is decided, and the decision rests on an assumption nobody states out loud: that the three lines really are three builds.

There is a reason they look independent, and it is the same reason underneath. Because the information lives nowhere in particular, every output has to go hunting for its own source and asks for its own screen. The list ends up copying the current mess back to you, one row at a time. Shortening the list does not shorten the mess. It only picks which part of the mess gets carried into the new system.

The assumption does not hold. The three outputs are three symptoms of one absence. What was missing was a record of which procedure went on which tooth in which session. Once that lands on the patient record, all three outputs are read from the same place. In the system that was built, invoicing draws on the patient record, reports read the same record from a different side, and the practice manager follows which step a patient has reached from one place.

So the first-release question is not “which two of these three do we drop”. It is “which single record, if we do not build it, leaves all three unavailable”. Answering that does not shorten the list. It reorders it.

An output you can derive is not built as a separate feature

That gives the first half of the criterion. If an output can be calculated from a record you hold, it does not go into the first release as a feature line of its own. The moment the record exists, so does the output. A screen still gets designed and a calculation still gets written, but the item is not a standalone entry with its own budget attached.

This gets misread often enough to be worth stating plainly: not built separately is not the same as not there. The clinic issued invoices from day one. What produces an invoice is not an invoicing feature; it is the fact that the work carried out is held on the patient record. Because the treatment given and the treatment billed sit on the same record, no reconciliation step exists between them. Reports read that record too, and the month end needs no second ledger.

The cost of the opposite arrangement is visible in the situation the clinic started from. When the work performed sits in one place and the invoice issued sits in another, the monthly report falls back on someone joining them by hand. Building a derived output as a separate line item in the first release hands that joining work to the new system as well. The money saved by cutting elsewhere looks like a saving. What actually got cut was the integrity of the record.

Testing a line for derivability is not hard. Ask where the information behind that line comes from today. If the answer is “it could be calculated from something we already record”, the line derives, and it does not need a budget of its own. If the answer is “nobody writes that down anywhere”, the line does not derive, and its source has to be built in the first release. What the test looks at is the source and not the label, because “reporting” reads the same in both cases.

The criterion has an edge, and the edge belongs here. It applies to work that has a record for something to derive from. Where no ledger is kept at all, the first-release boundary does not run between record and output. It gets drawn by a different question: does the added layer carry on the work the paper was already doing, or go past it? That is a separate piece of work with a separate test, and it is written up in where the scope is cut when a printed catalogue moves into software.

Which line cannot wait

The second half of the criterion inverts the first. What has to go into the first release is the record nothing currently holds. At the clinic that was the tooth-by-tooth treatment plan the old software never kept: which procedure is intended for which tooth, broken into an ordered run of sessions spread across weeks.

The unkept record does not travel alone. Something else goes in with it, and that something never appears as an item on anybody’s list: the attachment of each appointment to a particular step of the plan. No quotation has ever carried a line reading “link between appointment and plan step”. It has no price, no screen and nothing to demo. Without it the plan record is still half a record, because the plan cannot talk to the calendar.

You can see the link working at the clinic. Add a session to a plan or change the order of the steps and the calendar moves with it, and nothing is left booked against a step that no longer applies. How the calendar follows the plan is its own mechanism, and how an appointment is tied to a treatment plan step sets it out. For a scoping decision, one fact is enough: the link is a property of the record itself.

Which is why it cannot be postponed. The link is made at the moment a record is created. An appointment opened in the first release without a plan behind it cannot later be told which step it belonged to, because that information was never captured on any appointment. A field opened afterwards does not reach backwards; it only holds what comes after it. The gap looks small on a plan, and it covers every record the first release accumulates over its whole life.

The line you cannot negotiate away is therefore not the most expensive-looking line on the list. It is the record and its link. On most lists the two are not even adjacent: the record appears as a heading, and the link appears nowhere at all. Making that second one visible is most of what the criterion is for.

One criterion across three jobs

Before you turn the criterion on your own list, it helps to see it standing in three different jobs at once. In the table below, the second and fourth columns carry what the project pages record. The third column is this article’s reading, which is to say what the criterion says about that row. No row claims that a feature was shelved for a second release. None of the three jobs documents a decision like that; what the table shows is where, in software that is running, a record parts company with a reading of it.

What the three rows share is that every phrase in the first column reads like the name of a feature. “Invoicing”, “climate summary”, “optical mark reading”: each of them would claim its own row and its own budget on a quotation. Behind each one stands a record instead, and it is always a record: patient, day, exam. The column a first-release decision has to read is the second one.

The table also works against your own list. Write your lines out, and under each one write the record that line reads from. Wherever the space underneath stays empty, the line above it is not what belongs in the first release. The empty space is.

Cutting scope is not the same as building the record half-way

“Put the record in the first release” is easily heard as “put part of the record in”. Under budget pressure that hearing is very attractive, because it removes something, and removing something feels like cutting scope.

The wrong cut usually arrives as a sentence like this: leave the treatment plan for a later release, and for now put a notes field on the appointment. It fits the budget and it shortens the delivery date. What it actually does is different. It writes the arrangement the clinic was leaving behind into the first day of the new system: a record that holds the hour and not the stage of the treatment. That arrangement was the reason for changing software in the first place.

The cut runs between a record and what is read off it. It does not run through a record. Build half of one and shelve the other half and you have not made that record smaller; you have made a different record. An appointment with a notes field on it is not a cheap edition of a treatment plan. It is another thing entirely, and it accumulates a different history behind it.

Why a unit described wrongly does not get put right later is a separate question. The claim here is narrower: it is only about where the cut runs.

There is a useful order for building a list of cuts. Write down, for each line, which record it touches. Lines that touch no record at all are the first round of cuts. Lines that reduce the fields on a record are the second round, because a field can be opened later. Lines that change the identity of a record or its links are in no round. That order sorts the list by what each line touches rather than by what it costs.

So where does the money actually come from when the budget will not stretch? From everything that leaves the record structure alone. The number of screens, the layout of the panel, the columns on a report, which notifications ship in the first release: all of it can change afterwards, because none of it touches the identity of a record. Which decisions are expensive to reverse and which are cheap is its own subject, and the list worth having in front of you while you cut is there.

Why a summary is never scheduled for a release

The same criterion shows a different face in a job with nothing in common with a clinic. The daily weather site carries a climate summary: a reading of what a location’s past days add up to. That reading is not wired to a separate data source. It is worked out over the day records held in the archive, and it refreshes itself as the archive fills.

The scoping consequence follows directly. What sets the timing of a derived output is not a release schedule but the accumulation of its source. “Let’s put the climate summary in the next release” postpones nothing at all, because what is being postponed is a calculation and not a feature. A calculation runs on the day it has a source. Without one it runs in no release ever.

Here too, what goes into the first release is the record being kept: a day record written once and not revised afterwards. The site also carries a fifteen-day forecast looking forwards while the archive looks back, and why the two are kept apart is set out in how forecast, archive and summary are kept apart. For scoping purposes only one conclusion matters: if the day record is not kept from the first day, the summary does not appear in a second release either.

The difference from the clinic is exactly here, and it is worth naming. At the clinic the source record fills up with the first patient and the output can be read immediately. On the weather side the source accumulates over time, so the output starts thin and thickens. The scoping decision is identical in both: put the source in the first release, and do not put the reading on a schedule.

A feature added later opens no new record; it writes onto the one you keep

The fear underneath most of these conversations is simple: what if the thing I leave out cannot be added back? The honest answer is not “anything can be added”. What can be added has a recognisable shape, and the shape is worth learning.

The Vipkurum optical mark reading tool is an example of it. The tool was one of the additional jobs developed under the same platform roof, and the platform was already holding an exam record. The result the tool produces goes nowhere new. It is written onto that exam record, where a student’s marked answers meet the answer key.

This article’s reading of that is straightforward. The tool that arrived later asked for no new record; it wrote onto one that existed. That is precisely the shape of a line that can wait. If a feature can make do with what the accumulated records already carry, it can arrive whenever it arrives, and everything recorded up to that day stays where it is.

The inverse reads on the same criterion. If a feature arriving later needs a link the accumulated records never held, that feature was not postponed. The record underneath it was built short. The work then is not an addition; it is the subject of the previous section, which is the record being built again. You cannot tell the two cases apart by looking at the list, because on a list they look identical. The only thing that separates them is what the record holds.

Reading your own list against this criterion once is the cheapest work available before the budget reads it for you. One question per line: is this a record you keep, or a reading of one you keep? Work scoped on that same criterion is on our management software and web development pages.