Requirements vs backlog
A requirements document and a sprint backlog split when stories are authored from a paraphrase instead of from reviewed answers. The BRD stays in Confluence. Jira holds the work. From day one they describe two products.
For business analysts, product managers, and engineering leads who keep a BRD in one tool and a sprint backlog in another, then argue about which file is right.
The documents have already split if
Requirement drift is what happens when a shared answer later changes in only one place. A split is earlier: the organization never had one record. Analysts maintain a requirements document. Developers maintain a sprint backlog. Each file is faithful to its author. Neither is obligated to stay in sync, so they do not. User stories become a second product, not a decomposition of the first.
A requirements document is written to be complete. A sprint backlog is written to be pulled. Completeness and pull-readiness are different jobs. When they live in different systems, the queue silently becomes the spec.
Someone reads the BRD, attends a refinement, and types a story that “captures the spirit.” Adjectives change. Exclusions fall out. The story is now easier to sprint and harder to trace.
When the document says staff-only and the backlog has a public-status story, the team debates which source wins. That debate is the split. There should have been one record to point at.
Stop treating the requirements document and the sprint backlog as two deliverables. Reviewed answers are the spec. Stories are slices of those answers for a sprint. The board is a view, not a rewrite. If a story cannot point at a parent requirement, it is a new request—not a backlog item.
Freeze the answers that change behavior in requirements gathering software so stories slice reviewed requirements instead of starting a second spec in the backlog.
A complete request from software project intake is what the requirements document should still be attached to when the first sprint opens.
If a story cannot point at requirements gathering software, it is a new request—not a backlog item that “captures the spirit” of the BRD.
Do not export a “final” BRD and then let Jira become the only file developers open.
A locked Word doc or a Confluence page that nobody updates after sprint 1 is already the left half of a split. The living record has to be the same place later decisions are written.
Every sprint item should point at a reviewed requirement. Orphan stories are how a second product starts.
“As a user I can view status” is not a child of “staff submit a complete request and see its status” unless complete, staff-only, and the exclusions are on the story or still on the parent. If the link is missing, you are already splitting.
If refinement needs a rule that is not on the record, the missing answer is the work—not a clever ticket title.
A public status page that “would be easy” is not a story. It is a change to the first-release boundary. Write it on the requirement, re-estimate if needed, then slice. Do not hide it in the backlog.
A standup clarification that changes behavior belongs on the spec, not only on the ticket.
If developers agree “status does not email the client in v1,” that sentence must land on the requirement before the next tester reads the story. Otherwise the backlog is the newer, quieter source of truth.
Sprint planning sequences approved work. It does not author a second requirements document in Jira.
When someone asks “where is the spec?,” the answer should be the same thread the stories point at—not a BRD in Drive and a set of epics that drifted on day one.
Practical template
If a row fails, you already have two sources of truth. Fix the record before adding more stories. Examples use a fictional client intake change.
| Check | If this is missing | Example of “one thread” |
|---|---|---|
| One living spec | A frozen BRD plus an active backlog is already a split. | Reviewed answers for complete request, staff-only status, and named exclusions stay editable on the project. |
| Stories have parents | Orphan tickets become a second product. | Each story points at a reviewed requirement. “Nice-to-have export” is parked, not committed. |
| First-release boundary on both views | The document lists exclusions; the backlog quietly includes them. | Public self-service is out of scope on the requirement and absent from the sprint. |
| Same outcome sentence | The BRD says “complete request.” The epic says “intake portal.” | Staff can submit a complete client request and see its status—used on the spec and on the story. |
| Decisions update the spec | Refinement comments become the real rules. | “No client email in v1” is written on the requirement the same day, with a date, then the story is updated. |
| QA knows which file wins | Conflicting documents force testers to guess. | The tester opens the reviewed answers. The sprint item is a pointer, not a competing spec. |
| No day-one epic rewrite | Retyping the BRD into epic Description starts the second document immediately. | The epic summary names the outcome and links to the requirement thread instead of pasting a new brief. |
Worked example
A fictional Client Intake Portal is specified as staff-only, complete submissions, no public status. Sprint planning produces stories from a verbal recap. By the end of week one the two files disagree.
| Artifact | What it said |
|---|---|
| Requirements document | Staff submit a complete request and see status. Public self-service is later. |
| Sprint backlog | Stories for a status field, an optional public link, and a “polish” export |
| How the stories were written | Typed in refinement from memory of the BRD, not traced to named answers |
| What developers optimized | The public link, because it was on the board and the BRD was not |
| What QA received | Tickets that say “user can view status”—no definition of complete, no exclusion |
| The split | Two sources of truth from day one. Not drift after agreement—never one record. |
| The correction | Delete or park the public-link story. Point remaining stories at the reviewed answers. |
The team did not fail at Agile. It authored two products: a requirements document and a sprint backlog. Alignment returns when stories are slices of reviewed answers, and the board is not allowed to become a second spec.
| Requirements document | Sprint backlog item |
|---|---|
| Staff submit a complete request and see its status | “User can view status”—complete was never a rule on the ticket |
| Public self-service is later; staff-only is in writing | An optional public link, because refinement remembered “polish” |
| Named exclusions travel with the spec | Exclusions live in a BRD nobody opens after sprint planning |
| A living record later decisions can update | A queue of stories that became the newer source of truth |
A PDF feels like closure. It is how the requirements document becomes an archive and the sprint backlog becomes the product.
Refinement is a poor photocopier. If the story cannot cite a reviewed answer, you are inventing a second spec in the room.
An epic Description that restates the BRD is not a pointer. It is a fork. Keep the outcome sentence; link the thread.
When the document and the backlog conflict, teams follow whichever is in the tool they already have open. That is usually Jira. The quieter spec dies.
In Precision Foundry
Precision Foundry holds reviewed requirements on the same project record as stories, the sprint board, testing, and release. Developers do not inherit a paraphrase in another tool. The backlog is a view of that thread—not a competing requirements document.
Common questions
Because they are authored as two deliverables. The BRD is written to be complete. The backlog is written to be pulled. When stories are typed from a paraphrase instead of traced to reviewed answers, the queue becomes a second product from day one.
Drift is change after agreement: one answer later exists in two versions. A split is earlier. The organization never had one record. Analysts kept a document. Developers kept a backlog. They disagreed before anyone changed a decision.
No. Write stories as slices of reviewed requirements for a sprint. Do not write them as a rewrite of the BRD. If a story needs a rule the spec does not contain, update the spec first.
Yes, if one of them is a pointer. If both are edited as the spec, you already have two sources of truth. Pick the living thread and let the other tool link to it.
The document (or better, the reviewed answers) says what must be true. User stories slice that work for a sprint. Stories are not a second, shorter requirements document.
Precision Foundry keeps this guide attached to the request so the template does not live in a forgotten doc.
Join the private alpha waitlistOptional cookies
We use optional technologies only with your choice. Strictly necessary cookies for sign-in and security always run. Cookie Policy
