Feature Request vs User Story vs Change Request

A feature request is raw input: a customer, colleague or stakeholder asks for something, usually in their own words and usually as a solution. A user story is the team’s own statement of a change worth building, written from the user’s point of view with a reason attached, and it only exists once someone has decided the request is worth pursuing. A change request is different in kind: it asks to alter something that was already agreed, a signed scope, a contract or a baseline plan, and it goes through a formal approval because money, dates or obligations move with it. The short version is that a request is evidence, a story is a decision to build, and a change request is a negotiation about a promise.

None of these terms has one official definition, and usage varies between teams, tools and industries. What follows is how most teams use them. For the forms themselves, see the feature request template and the user story template; for how stories break down into work, see user story vs task.

Three documents, side by side

• Who writes it. Feature request: anyone outside the team who uses or pays for the product. User story: the team itself, usually led by whoever owns the backlog. Change request: either party to an agreement, customer or supplier.
• When. Feature request: whenever a need is noticed, with no schedule. User story: when the team decides a need is worth meeting, typically during refinement. Change request: after a scope, plan or contract has been agreed and someone wants it to be different.
• What it contains. Feature request: the problem in the requester’s words, their workaround, how often it happens, and often their idea for a fix. User story: who, what and why, plus acceptance criteria. Change request: what should change and why, its impact on cost, time and risk, and a decision.
• What it commits anyone to. Feature request: nothing, beyond a reply. User story: a place in the backlog order, and nothing more until it is selected. Change request: once approved, a changed obligation, often with changed charges or dates.
• Where it lives. Feature request: an inbox, form or board. User story: the backlog. Change request: a change log owned by whoever controls the baseline.

The feature request: evidence, not a specification

People describe what they want as a solution, because that is how they experience the gap: “add an export button”, “make it work with our calendar”. The GOV.UK Service Manual’s advice on learning user needs↗ (opens in a new tab) is to focus on the problem rather than possible solutions, and a feature request is most useful when it is read that way: as evidence that a need exists, from a named person, with a cost attached.

That is why a request should not be copied straight into the backlog as if it were a story. Ten requests may describe one need in ten different ways. One request may hide two needs. And some requests describe a bug in disguise: “please add a way to fix the totals” often means the totals are wrong. The request is kept, because the requester’s own words are the best record of the problem, but the decision about what to build is a separate step.

The user story: the team’s decision, in the user’s words

A user story is written by the team, not the requester. The GOV.UK guide to writing user stories↗ (opens in a new tab) says every member of the team should write them, and that a story should always name the actor, the narrative and the goal, with enough information for the product manager to decide how important it is. It also makes a point worth keeping when a request arrives as a solution: if you are struggling to write the goal, reconsider why you think you need that feature.

A story is also meant to be a unit of delivery. The Agile Alliance describes user stories↗ (opens in a new tab) as functional increments the team divides the work into, in consultation with the customer or product owner, each expected to add to the value of the product once implemented. A request has no such shape; it is whatever size the requester’s problem happens to be.

How a request becomes a story

1. Search for the same need. If a story already covers it, add the new requester and their words to that story as evidence. Demand is easier to judge when it is gathered in one place.
2. Restate the problem. Replace the requester’s solution with the need behind it: not “CSV export”, but “the accountant needs monthly totals without anyone copying them by hand”.
3. Decide whether to build it at all. Most requests end here as a polite no, a “later”, or a pointer to something that already exists. Write down why, and tell the requester.
4. Write the story. Who benefits, what they can do, and why, with acceptance criteria someone other than the author could check.
5. Split it if it is too big. One request often becomes two or three stories, each worth delivering on its own.
6. Link back. Keep a reference from the story to the original request, so the people who asked can be told when it ships.

Request (from a customer, by email):
  "Can you add a CSV export to the Reports page? I copy
   40 lines into a spreadsheet for our accountant every month."

Story (written by the team after triage):
  As a finance lead, I want this month's totals sent to our
  accountant in a file their software imports, so that nobody
  copies figures by hand and the numbers arrive on the 1st.
  Done when: the file imports cleanly into the accountant's
  system; totals match the Reports page; it arrives by the 1st.
  Evidence: 3 requests, linked.

The change request: when scope is a promise

Change requests belong to work where the scope has been agreed in advance and someone is held to it: a fixed-price project, a public-sector contract, a statement of work with an agency. In that setting, a new idea from the customer is not simply added to a backlog, because it changes what one party owes the other.

UK central government’s model contract shows the formal version. The Model Services Contract guidance↗ (opens in a new tab) says either party can request a change by sending a Change Request that sets out a full description of the proposed change with its advantages and disadvantages, the likely costs and a target date. The supplier then produces an impact assessment covering, among other things, the effect on service levels and charges, and a Contract Change can only be implemented once it has been authorised by the buying authority. Smaller changes that do not affect cost or risk go through a lighter operational change process instead.

Outside contracts, the term is used more loosely. Some teams call any change to agreed scope a change request; IT operations teams use it for changes to live systems; and some product teams use it for an enhancement to an existing feature. Before using the word with a client, agree which meaning you both have in mind.

Change requests in agile work

Agile methods lower the cost of change on purpose. One of the principles behind the Agile Manifesto↗ (opens in a new tab) is to welcome changing requirements, even late in development.

In Scrum the equivalent is simply reordering the backlog: the 2020 Scrum Guide says that those wanting to change the Product Backlog↗ (opens in a new tab) can do so by trying to convince the Product Owner. No form, no impact assessment.

That does not make change requests obsolete. If the contract fixes the scope and the price, a new story is still a change to the deal, however the team works internally. A common arrangement is to agree a budget and a backlog rather than a fixed feature list, so that swapping one story for another of similar size needs no formal change, while anything that adds cost or moves a date still goes through change control. Write down which kind of change needs which route before the first argument, not during it.

Common mix-ups

• Filing requests as stories. The backlog fills with solutions nobody has examined, in the requesters’ words, and ordering it becomes a vote.
• Calling every new story a change request. In a team with no fixed scope, this adds paperwork without protecting anyone.
• Treating a change request as approved because work started. In contract work, a change that was built but never authorised is a dispute waiting to happen.
• Losing the requester. Once a request becomes a story, nobody remembers who asked, and the people most likely to use the feature never hear it shipped.

On a fenbs board

fenbs does not have separate record types for requests, stories and change requests. Every task is a feature, an enhancement or a bug, sits in one of four lanes, To Do, Next Up, In Progress and Completed, and has a note for the problem and a plan for how it will be done. The three documents map onto that without extra fields:

• A request lands as a task in To Do, filed by the requester if they have the Reporter role, which can add tasks and edit only their own. Their words go in the note, which is the problem and is written once.
• It becomes a story when the team rewrites the plan and sets a priority from 1 to 10. A duplicate request becomes a comment on the existing task, and a declined one is moved to Completed with how it ended: Won’t fix, Duplicate or Obsolete, so it never counts as delivered.
• A change to agreed scope is a decision, not a task field. Record it on the Decisions page with who decided and why, and link the tasks it affects. Deciders are always people.
• History records every move with who made it and when, which is the evidence trail a change dispute usually lacks.

What fenbs does not do: there is no approval workflow, no impact-assessment form, no costing and no link a client can open without being added to the board. If your contract requires formal change control, keep the change log where the contract says, and use the board for the work that follows each decision.