Epic and Feature · review before the tracker · fictional example
Backlog: Epics and Features, in plain language
The whole backlog of the Broker Assistant in one document, written so that a developer, a QA and a sales manager read the same thing. Codes, scope, dependencies and rules are the tracker's; the writing is plain. Everything here is fictional: the brokerage, the people, the numbers and the dates.
How to read: "Write to the CRM" means updating a field in the brokerage's CRM after the broker approves. "Wave" (ondas, in the vocabulary this layout comes from) is a delivery group that ends with something a broker uses. "Points" are Fibonacci story points set by the developer who will build the story.
A tracker board is compact: one card at a time, in a column, without the why, the wave or the team's capacity in view. This document reads top to bottom, with the plain sentence, the chain of dependencies and the points in one place. The planning happens here, in the review meeting, with the whole backlog open: the product manager opens a Feature, assigns each User Story to a developer and sets its Fibonacci points. The bar at the bottom recalculates the load per person and for the team on every click, and turns amber at 80 percent and red the moment someone is above their capacity. The tracker stays the system of record; it is loaded only after the review, from the plan this document exports.
How the planning works. Open any Feature card in Waves of delivery or in a Sprint chapter, mark the stories that enter the target sprint, pick the owner, set the points. Watch the bar. Then close the meeting in Planning, where the plan is listed as it would be written to the tracker, and export it.
Summary
5Epics
14Features
39User Stories
3Features in the MVP
4+1Waves + parallel track
54Points known, 14 of 39 stories estimated
5Developers, 42 points a sprint
In 30 seconds. An AI assistant for the brokers of a fictional brokerage. Wave 1 answers portal leads and makes every CRM write approved and reversible; wave 2 prepares visits and records their outcome; wave 3 keeps proposals from going silent; wave 4 makes the forecast read the evidence. A parallel track syncs the developers' answers. Sprint 3 closed the MVP of wave 1; Sprint 4 is finishing wave 1 and opening wave 2; Sprint 5 is planned in this document.
Short glossary
Term
Meaning
Always-allow
A per-broker, per-capability setting that lets the assistant act without approving each action.
Catalogue
The brokerage's list of units with price, conditions and stand hours, kept by the back office and dated.
Category
Commit, likely or possible: how sure the company is that a deal closes this month.
Developer
The company that builds and sells the launch; it sets discount and payment rules and answers proposals.
Enabler
A story that builds something the other stories need and that no broker sees directly. It has no persona.
Golden set
A fixed set of real, anonymized inputs with the expected result, used to score a probabilistic behavior.
Leads become qualified conversations · A lead from a property portal reaches the broker with context and a drafted first reply, instead of a bare name and phone number.
Every visit has a prepared broker and a recorded outcome · Before a visit the broker knows the unit, the price, the buyer's answers and what is still open; after it, the outcome is in the CRM without typing.
Proposals are followed up on time · A proposal never sits silent: the broker is reminded, the follow-up is drafted, and the developer's answer reaches the CRM.
The broker approves what the assistant writes · Nothing reaches the CRM without the broker seeing it field by field, and everything that was written can be read back later.
The forecast matches the evidence · The stage and the forecast category of each deal follow what happened in visits and proposals, with the reason written next to them.
Closed with 10 stories and 40 points of the 42 planned (illustrative).
What entered
8 stories · 1 items · 33 points
✓ 5 ptsBA-LEAD-F01-US01HelenaReceive portal leads into one queueBA-LEAD-F01 · The lead queue with context
✓ 3 ptsBA-LEAD-F01-US02HelenaShow what is still unknown about the buyerBA-LEAD-F01 · The lead queue with context
✓ 3 ptsBA-LEAD-F01-US03RafaelAttach the listing facts the buyer will ask aboutBA-LEAD-F01 · The lead queue with context
✓ 5 ptsBA-LEAD-F02-US01RafaelDraft the first reply from the lead and the listingBA-LEAD-F02 · The first reply, drafted and sent after approval
✓ 5 ptsBA-LEAD-F02-US02JúliaEdit, approve and send the reply from the queueBA-LEAD-F02 · The first reply, drafted and sent after approval
✓ 5 ptsBA-CRM-F01-US01TomásCreate the single write path to the CRMBA-CRM-F01 · Field-by-field preview and approval
✓ 3 ptsBA-CRM-F01-US02JúliaShow the preview with old and new valuesBA-CRM-F01 · Field-by-field preview and approval
✓ 3 ptsBA-CRM-F03-US01BiancaShow the trail on the recordBA-CRM-F03 · Activity trail and daily digest
1 ptsIMP01improvementShow the time since arrival in minutes under one hour, hours after
Sprint 4 · 6 to 17 April 2026, current
In progress: 7 stories, 25 points planned.
What is in progress
6 stories · 2 items · 27 points
3 ptsBA-LEAD-F01-US04BiancaFlag leads that are waiting too longBA-LEAD-F01 · The lead queue with context
3 ptsBA-LEAD-F02-US03RafaelLearn from the broker's editsBA-LEAD-F02 · The first reply, drafted and sent after approval
3 ptsBA-CRM-F01-US03TomásUndo any write for 24 hoursBA-CRM-F01 · Field-by-field preview and approval
3 ptsBA-CRM-F03-US02BiancaSend the daily digestBA-CRM-F03 · Activity trail and daily digest
5 ptsBA-VISIT-F01-US01JúliaBuild the sheet from the lead and the catalogueBA-VISIT-F01 · The visit preparation sheet
5 ptsBA-VISIT-F02-US01TomásTurn a voice note into proposed fieldsBA-VISIT-F02 · Visit outcome by voice or text
2 ptsIMP02improvementKeep the draft's original when the broker edits
3 ptsBUG02bugThe preview showed the old value of a field changed by the broker a minute before
Sprint 5 · 20 April to 1 May 2026, next
Planned in this document, in the review meeting, before anything is loaded into the tracker.
What enters, as planned in this document
nothing marked yet
This chapter fills itself from the planning layer. Open a Feature card in Waves of delivery, mark the stories, pick owners and points; the list below is what the Planning chapter exports.
No story marked for Sprint 5 yet.
Waves of delivery
Four waves and a parallel track. Each wave ends with something a broker uses in production, a short validation with real brokers, and a release. A dependency never points to a later wave; the generator refuses the document otherwise. Features marked MVP are the smallest usable delivery and depend on no outside access.
Wave 1 · Leads and approval: the lead is answered and every write is approved
4 Features · 12 stories
What becomes usable. The broker opens one queue with every portal lead, its listing facts and the open questions; a drafted first reply goes out after approval; every write to the CRM is previewed field by field, can be undone for a day, and shows up in the evening digest. The first three Features are the MVP and depend on no outside access.
What it does not cover. Qualification happens in the broker's head for now; visits and proposals are still recorded by hand.
queue 1BA-LEAD-F01Wave 1 · Leads and approvalMVPThe broker opens one queue where every portal lead shows the listing, the buyer's message and what is still unknown.L1L1 · First reply within one hourExecution · read weeklyLeads answered within 60 minutes of arrival ÷ leads received in the periodProduces the data for this number.Today: no data yetTarget: 80% of leads in the pilotWhy it matters: A lead answered in the first hour is the one that converts; this queue is where the hour starts.Source: the assistant's own event log and the CRM mirror, read weekly
queue 2BA-LEAD-F02Wave 1 · Leads and approvalMVPThe assistant drafts the first reply to a lead from the listing facts and the buyer's message; the broker edits, approves and it goes out.L1L1 · First reply within one hourExecution · read weeklyLeads answered within 60 minutes of arrival ÷ leads received in the periodMoves this number.Today: no data yetTarget: 80% of leads in the pilotWhy it matters: This Feature is the reply itself; it exists to move the first-hour number.Source: the assistant's own event log and the CRM mirror, read weekly
queue 3BA-CRM-F01Wave 1 · Leads and approvalMVPEvery write the assistant wants to make is shown as old value, new value and origin, and the broker approves field by field.C1C1 · Writes approved without editsResult · read weeklyProposed writes approved as proposed ÷ proposed writesMoves this number.Today: no data yetTarget: 80% after two monthsWhy it matters: This number is the trust the brokers put in the assistant, measured.Source: the assistant's own event log and the CRM mirror, read weekly
queue 4BA-CRM-F03Wave 1 · Leads and approvalEverything the assistant did on a record can be read back, and each broker receives a daily digest of what was written in their name.C1C1 · Writes approved without editsResult · read weeklyProposed writes approved as proposed ÷ proposed writesProduces the data for this number.Today: no data yetTarget: 80% after two monthsWhy it matters: The trail is where the number is read; the digest is where the broker sees it.Source: the assistant's own event log and the CRM mirror, read weekly
Wave 2 · Visits: a prepared broker and a recorded outcome
4 Features · 12 stories
What becomes usable. A one-page sheet before the visit, three fitting slots proposed in the conversation, and the outcome spoken in the car and proposed as fields. Qualification questions run in the conversation and a score the broker can explain orders the queue.
What it does not cover. Proposals and the forecast still live outside the assistant.
queue 5BA-VISIT-F01Wave 2 · VisitsBefore a visit, one page shows the unit, the price and conditions, the buyer's facts and what the broker still has to find out.V1V1 · Visits preparedExecution · read weeklyVisits whose sheet was opened before the visit ÷ visits heldSupports this number.Today: no data yetTarget: 85% in the pilotWhy it matters: A prepared broker closes the second visit during the first one.Source: the assistant's own event log and the CRM mirror, read weekly
queue 6BA-VISIT-F03Wave 2 · VisitsThe assistant proposes visit slots that fit the broker's calendar and the stand's hours, and confirms with the buyer after approval.V3V3 · Visits scheduled from the conversationMarket · read weeklyVisits scheduled by the assistant ÷ visits heldSupports this number.Today: no data yetTarget: 60% in the pilotWhy it matters: A slot offered in the conversation becomes a visit; a 'let me check' becomes silence.Source: the assistant's own event log and the CRM mirror, read weekly
queue 7BA-VISIT-F02Wave 2 · VisitsAfter the visit the broker speaks or types what happened and the assistant proposes the fields: interest, objections, next step, date.V2V2 · Outcome recorded within an hourExecution · read weeklyVisits with an outcome recorded within 60 minutes ÷ visits heldMoves this number.Today: no data yetTarget: 90% in the pilotWhy it matters: The outcome is what the forecast and the follow-up read; without it both read nothing.Source: the assistant's own event log and the CRM mirror, read weekly
queue 8BA-LEAD-F03Wave 2 · VisitsAfter the first reply, the assistant asks the remaining qualification questions in the conversation and keeps a score the broker can read.L2L2 · Qualified before the first visitMarket · read weeklyLeads with the four facts known before the first visit ÷ leads that had a visitSupports this number.Today: no data yetTarget: 70% in the pilotWhy it matters: A qualified lead visits the right unit; an unqualified one visits three.Source: the assistant's own event log and the CRM mirror, read weekly
Wave 3 · Proposals: nothing stays silent
3 Features · 7 stories
What becomes usable. Every proposal has a next step and a date; the follow-up is drafted on the date; counter-proposals are checked against the developer's table before they leave; brokers switch capabilities to always-allow at their own pace.
What it does not cover. The developer's answers still arrive by phone until the parallel track lands.
queue 9BA-PROP-F01Wave 3 · ProposalsWhen a proposal's next-step date arrives, the broker gets a drafted follow-up for the buyer or the developer, with the proposal facts.P1P1 · Silent proposalsExecution · read weeklyOpen proposals with no activity for seven days ÷ open proposalsMoves this number.Today: no data yetTarget: under 10% in the pilotWhy it matters: A silent proposal is a sale someone else closes.Source: the assistant's own event log and the CRM mirror, read weekly
queue 10BA-PROP-F02Wave 3 · ProposalsBefore sending a counter-proposal, the broker sees whether it fits the developer's discount and payment rules, with the rule and its date.P2P2 · Counter-proposals inside the rulesResult · read weeklyCounter-proposals within the developer's discount and payment table ÷ counter-proposals sentSupports this number.Today: no data yetTarget: 100%Why it matters: A counter-proposal outside the rules is a week lost and a buyer told no twice.Source: the assistant's own event log and the CRM mirror, read weekly
queue 11BA-CRM-F02Wave 3 · ProposalsThe broker switches each capability of the assistant to always-allow at their own pace, and switches it back with one tap.C2C2 · Capabilities on always-allowSensor · read weeklyBrokers with at least one capability on always-allow ÷ active brokersSupports this number.Today: no data yetTarget: 50% after the first monthWhy it matters: Autonomy earned broker by broker, visible as a number.Source: the assistant's own event log and the CRM mirror, read weekly
Wave 4 · Forecast: the stage and the category read the evidence
2 Features · 5 stories
What becomes usable. The stage is proposed from the last event with its rule; the category from stage, score and status; the manager's Monday view shows reasons, disagreements and month-end accuracy.
What it does not cover. Revenue projections and automatic stage writes stay out until the rules have two scored months.
queue 12BA-FCST-F01Wave 4 · ForecastAfter a visit outcome or a proposal event, the assistant proposes the deal's stage with the reason, for the broker's approval.F1F1 · Stage matches the evidenceResult · read weeklyDeals whose stage matches the last recorded event ÷ open dealsMoves this number.Today: no data yetTarget: 90% in the pilotWhy it matters: A pipeline whose stages match the events is a pipeline the manager can read.Source: the assistant's own event log and the CRM mirror, read weekly
queue 13BA-FCST-F02Wave 4 · ForecastThe forecast category (commit, likely, possible) is proposed from the stage, the qualification score and the proposal status, with the reason.F2F2 · Forecast accuracyResult · read weeklyDeals closed in the month ÷ deals in commit and likely at the start of the monthMoves this number.Today: no data yetTarget: baseline, then plus 15 pointsWhy it matters: The number the company runs on, finally read from evidence.Source: the assistant's own event log and the CRM mirror, read weekly
Parallel track · Developer status sync
1 Features · 3 stories
What becomes usable. The two developers' daily exports are imported and matched, status changes are proposed to the broker, and the sync is measured weekly. It runs beside waves 3 and 4 because it depends on an access agreement, not on the waves.
What it does not cover. Developer APIs and the other developers.
queue 14BA-PROP-F03Parallel trackThe developer's answer to a proposal reaches the CRM within a day, from the developer's export, without the broker retyping it.P3P3 · Status in syncSensor · read weeklyProposals whose CRM status matches the developer's system ÷ open proposalsSupports this number.Today: no data yetTarget: 95%Why it matters: The forecast reads the status; a stale status is a wrong forecast.Source: the assistant's own event log and the CRM mirror, read weekly
Planning: owner and points
The meeting closes here. Everything marked in the cards is listed as it would be written to the tracker: story, owner, points, sprint, and what changes against the tracker's current values. The bar at the bottom keeps the load per person in view while you decide who takes the next story.
In the original, this chapter writes owner, points and sprint to Azure DevOps from the browser, with a token that lives only in the open tab. This public version exports the plan instead.
points per person in this sprint. The reference of 10 for a two-week sprint is one point per working day with ceremonies discounted; replace it with the team's measured velocity as soon as there are closed sprints to measure. When the sprint declares a capacity per person, this number applies only to people without one.
No User Story marked yet. Open a card in Waves of delivery or in a Sprint chapter and mark what enters this sprint.
Development queue
The number answers "what comes now". It replaces a schedule and an estimate at this level: points are set by the developer who pulls each User Story, in the planning above.
One chapter per Epic: the Epic card with its eleven sections, then each Feature with its fifteen. Cards open and close; inside the planning pop-up they open already expanded.
BA-LEAD Leads become qualified conversations
EpicBA-LEAD · Leads become qualified conversations
A lead from a property portal reaches the broker with context and a drafted first reply, instead of a bare name and phone number.
3 Features · 10 User Stories
1Why it exists
A brokerage receives hundreds of portal leads a month and most die in the first hour: the broker is at a visit, the reply comes late, and the buyer has already written to three other brokers. Without this Epic the assistant has nothing to work with: no queue, no context, no first reply.
2Problem
Portal leads arrive by email and in three portal back offices. Brokers copy them by hand into the CRM, reply from memory, and lose the ones that arrive during visits.
3Objective
Every lead is in the broker's queue within a minute, with the listing, the buyer's message and the questions the broker still has to ask, and the first reply goes out the same hour after the broker approves it.
4Success metrics
First reply within one hour, from 35% to 80% of leads (illustrative).
Leads with a qualification score before the first visit: 70%.
Portal leads lost to a late reply, read from the portal's own report: half of today's number.
5First-release scope
The queue with context (BA-LEAD-F01).
The drafted first reply, sent after approval (BA-LEAD-F02).
Qualification questions and a score (BA-LEAD-F03).
6Business rules
The assistant never contacts a buyer without the broker's approval.
A lead belongs to one broker; redistribution is the manager's decision, not the assistant's.
The portal of origin and its lead id stay on the record.
7Dependencies
Portal exports (email and CSV) in wave 1; portal APIs are a later enabler. BA-CRM-F01 for any write to the CRM.
8Risks and mitigation
Risk: a portal changes its email format and leads stop arriving. Mitigation: a daily count per portal with an alert when it drops to zero.
Risk: the drafted reply sounds generic. Mitigation: the broker edits before approving, and edits feed the next drafts.
Risk: duplicate leads across portals. Mitigation: match by phone and email before creating a record.
9Governance and operation
The sales manager owns the queue rules and the redistribution.
Weekly reading of first-reply time per broker in the manager's digest.
Autonomy: the assistant drafts; sending stays at tier 2 (approve each) in the first release.
10Technical details
Inbound: portal emails parsed into a lead record; CSV import as a fallback.
Listing data from the brokerage's catalogue, read only.
Reads and writes go through the assistant's single CRM write path; every write carries author, previous value, proposed value, written value, origin and approval.
11Estimate
11 User Stories, 34 points estimated by the developers (illustrative).
The Features of BA-LEAD
queue 1BA-LEAD-F01 · The lead queue with context Wave 1 · Leads and approvalMVP
The broker opens one queue where every portal lead shows the listing, the buyer's message and what is still unknown.
4 User Stories · 4 of them estimated · 14 points known
1Why it exists
Nothing in the program starts before the lead is in one place with its context. This Feature is the queue and the context; the reply and the qualification build on it.
2Problem and context
Leads arrive by email from three portals in three formats and are copied by hand, late, into the CRM.
3Objective
Every lead in one queue within a minute, with the listing facts and the open questions, and a visible timer.
4Business value
The first hour becomes visible and manageable; the first reply (F02) has something to say.
5Expected behavior
One queue per broker, ordered by arrival.
Listing facts from the catalogue, dated.
Open qualification questions per lead.
Timer and manager's count of waiting leads.
6Acceptance criteria
A portal lead is in the queue within one minute of the email.
Duplicates across portals are merged.
Listing facts carry the catalogue date.
A lead past 30 minutes is highlighted and counted.
7Scope and limits
In: three portals by email, CSV import, catalogue read.
Out: portal APIs, automatic redistribution.
8Business rules
A lead belongs to the listing's broker.
Nothing is guessed: a missing fact is a question.
9Data and sources
Portal emails (source of truth for the lead).
Catalogue (source of truth for listing facts).
CRM (destination, through BA-CRM-F01).
10Dependencies
As drawn: none
none
11Non-functional requirements
Preview opens in under two seconds on a phone.
Every write is logged with its origin.
12Evaluation criteria
Parser accuracy per portal on a 40-email golden set: 100% on required fields (illustrative).
Extraction of the four facts: no guessed value in the never-cases.
13Open items and decisions
Whether reception-typed leads enter through the same queue (decision by 2026-04-20).
14Traceability
Program brief sections 2 and 4.
Portal formats read on 2026-02-20.
15Estimate
4 stories, 14 points (illustrative).
queue 2BA-LEAD-F02 · The first reply, drafted and sent after approval Wave 1 · Leads and approvalMVP
The assistant drafts the first reply to a lead from the listing facts and the buyer's message; the broker edits, approves and it goes out.
3 User Stories · 3 of them estimated · 13 points known
1Why it exists
The queue shows the lead; this Feature answers it. It is the single largest time saving in the Epic and the first place the brokers will judge the assistant.
2Problem and context
Replies are written from memory, late, and repeat the portal form.
3Objective
A reviewed reply out within the hour for 80% of leads.
4Business value
The broker's ten minutes become one; the buyer gets a specific answer while still interested.
5Expected behavior
Draft from the message and the catalogue.
Edit, approve, send from the queue.
Edits measured and fed back.
6Acceptance criteria
Each question in the message is answered or marked to confirm.
One qualification question per draft.
Nothing sent without approval.
No fact absent from the catalogue.
7Scope and limits
In: first reply only.
Out: follow-ups, scheduling.
8Business rules
Tier 2 autonomy: approve each.
Never a price or condition that is not in the catalogue.
Golden set of 40 leads: 90% of drafts pass the rubric before the pilot; never-cases (invented fact, discount) at zero (illustrative).
13Open items and decisions
Whether a draft may propose a visit slot in the first reply (decision with BA-VISIT-F03).
14Traceability
Program brief section 3; tone guide 2026-03-02.
15Estimate
3 stories, 13 points (illustrative).
queue 8BA-LEAD-F03 · Qualification questions and a score Wave 2 · Visits
After the first reply, the assistant asks the remaining qualification questions in the conversation and keeps a score the broker can read.
3 User Stories · 0 of them estimated · 0 points known
1Why it exists
A first reply opens a conversation; this Feature turns the conversation into four facts and a score. Without it, qualification stays in the broker's head.
2Problem and context
Brokers visit with unqualified buyers and the manager cannot prioritize.
3Objective
The four facts known before the first visit for 70% of leads, with a score the broker can explain.
4Business value
Fewer wasted visits; the right listing for the buyer.
BA-VISIT Every visit has a prepared broker and a recorded outcome
EpicBA-VISIT · Every visit has a prepared broker and a recorded outcome
Before a visit the broker knows the unit, the price, the buyer's answers and what is still open; after it, the outcome is in the CRM without typing.
3 Features · 9 User Stories
1Why it exists
A visit is the most expensive moment of the sale and today it starts from memory and ends in a WhatsApp message that nobody records. Without this Epic the CRM shows visits that happened with no outcome, and the forecast reads a pipeline that does not exist.
2Problem
Brokers prepare visits from scattered PDFs and chat threads, and record outcomes hours later, if at all. The manager cannot tell a cold visit from a hot one.
3Objective
A one-page preparation before every visit and a recorded outcome within an hour after it, for 90% of visits.
4Success metrics
Visits with a recorded outcome within one hour: from 30% to 90% (illustrative).
Visits with a preparation sheet opened before the visit: 85%.
Second visits scheduled during the first visit: a measured baseline, then plus 20%.
5First-release scope
The preparation sheet (BA-VISIT-F01).
Scheduling with the buyer and the developer's sales stand (BA-VISIT-F03).
Outcome capture by voice or text (BA-VISIT-F02).
6Business rules
The outcome fields the assistant proposes are previewed and approved field by field (BA-CRM-F01).
A visit without a recorded outcome blocks the stage change in the forecast.
7Dependencies
BA-LEAD-F01 for the buyer's context; BA-CRM-F01 for the writes; the developer's visit calendar for BA-VISIT-F03.
8Risks and mitigation
Risk: voice capture misreads amounts. Mitigation: amounts are shown next to the source phrase and never written without approval.
Risk: developers' stands keep their own calendars. Mitigation: scheduling starts with the brokerage's own calendar and adds stands one by one.
9Governance and operation
The sales manager reads visits without outcome in the weekly digest.
Autonomy: tier 2 for all writes in the first release; tier 3 for the visit date once the eval set passes.
10Technical details
Calendar read and write through the brokerage's calendar provider.
Voice notes transcribed, then mapped to fields; the transcript is kept as evidence.
Reads and writes go through the assistant's single CRM write path; every write carries author, previous value, proposed value, written value, origin and approval.
Golden set of 30 voice notes: field accuracy 90%, never-cases (invented amount) zero (illustrative).
13Open items and decisions
Whether the transcript is stored for 30 or 90 days (legal decision).
14Traceability
Program brief section 6; forecast rules 2026-03-10.
15Estimate
3 stories, 12 points (illustrative).
BA-PROP Proposals are followed up on time
EpicBA-PROP · Proposals are followed up on time
A proposal never sits silent: the broker is reminded, the follow-up is drafted, and the developer's answer reaches the CRM.
3 Features · 8 User Stories
1Why it exists
Half of the proposals in the pipeline have no follow-up for more than a week. The buyer cools, the developer forgets, and the broker finds out when the unit is sold to someone else. Without this Epic the assistant stops at the visit.
2Problem
Proposals live in the developer's system, in email and in the broker's head. Deadlines pass without anyone noticing.
3Objective
Every open proposal has a next step with a date, a drafted follow-up when the date arrives, and a status that matches the developer's answer within a day.
4Success metrics
Proposals without a follow-up for seven days: from 48% to under 10% (illustrative).
Proposals with a status that matches the developer's system: 95%.
Counter-proposals inside the developer's discount rules: 100%.
5First-release scope
Follow-up reminders and drafts (BA-PROP-F01).
Counter-proposal preview with the developer's rules (BA-PROP-F02).
Proposal status synced from the developer's system (BA-PROP-F03, parallel track).
6Business rules
The assistant never sends a proposal or a counter-proposal; it drafts, the broker sends.
Discount limits come from the developer's table, never from the conversation.
7Dependencies
BA-CRM-F01 for writes; the developer's system export for BA-PROP-F03.
8Risks and mitigation
Risk: a developer's discount table is out of date. Mitigation: the table carries its date and the preview shows it.
Risk: status sync creates duplicates. Mitigation: match by proposal number and buyer document.
9Governance and operation
The commercial director owns the discount tables.
Weekly reading of silent proposals per broker.
10Technical details
Reminders from the proposal date and the next-step field.
Developer export as CSV in the first release; API later.
Reads and writes go through the assistant's single CRM write path; every write carries author, previous value, proposed value, written value, origin and approval.
Matching precision on a 50-line golden set: 100% (illustrative).
13Open items and decisions
Access agreement with the two developers (commercial director).
14Traceability
Export formats 2026-03-18; KPI P3.
15Estimate
3 stories, 11 points (illustrative).
BA-CRM The broker approves what the assistant writes
EpicBA-CRM · The broker approves what the assistant writes
Nothing reaches the CRM without the broker seeing it field by field, and everything that was written can be read back later.
3 Features · 7 User Stories
1Why it exists
An assistant that writes to the CRM on its own is an assistant the brokers switch off. Without this Epic every other Epic has no write path and no trust.
2Problem
Brokers do not trust automatic updates; managers cannot audit what changed; the CRM has fields nobody owns.
3Objective
A preview-and-approve step for every write, settings that let each broker widen the assistant's autonomy at their own pace, and a trail that explains every change.
4Success metrics
Writes approved without edits: a measured baseline, then 80% after two months (illustrative).
Writes reverted within a day: under 2%.
Brokers who switched a capability to always-allow after the first month: 50%.
5First-release scope
Field-by-field preview and approval (BA-CRM-F01).
Always-allow settings per capability (BA-CRM-F02).
Activity trail and daily digest (BA-CRM-F03).
6Business rules
One write path. Every write carries author, previous value, proposed value, written value, origin and approval.
Always-allow is per capability and per broker, never global.
Undo is available for 24 hours on any write.
7Dependencies
The CRM write API and its field list.
8Risks and mitigation
Risk: the preview adds friction and brokers skip it. Mitigation: one screen, one approve button, and always-allow once trust is earned.
Risk: the trail becomes noise. Mitigation: grouped per record and per day.
9Governance and operation
Autonomy tiers follow the eval results per capability, decided monthly by the product manager and the sales manager.
10Technical details
A write service with a contract table (object, field, allowed values).
Trail stored with the write, never reconstructed.
Digest by email, daily, per broker.
11Estimate
8 User Stories, 27 points (illustrative).
The Features of BA-CRM
queue 3BA-CRM-F01 · Field-by-field preview and approval Wave 1 · Leads and approvalMVP
Every write the assistant wants to make is shown as old value, new value and origin, and the broker approves field by field.
3 User Stories · 3 of them estimated · 11 points known
1Why it exists
No other Feature may write without this one. It is the contract between the assistant and the brokers.
2Problem and context
Automatic writes nobody trusts; no audit; no undo.
3Objective
Every write previewed, approved and reversible.
4Business value
Trust, measured as approvals without edits.
5Expected behavior
Single write path.
Preview with old, new, source.
Undo for 24 hours.
6Acceptance criteria
No write without approval.
Six attributes per write.
Undo respects later changes.
7Scope and limits
In: all assistant writes.
Out: human writes in the CRM itself.
8Business rules
One write path.
Approval per field.
9Data and sources
CRM API, write log.
10Dependencies
As drawn: none
none
11Non-functional requirements
Preview opens in under two seconds on a phone.
Every write is logged with its origin.
12Evaluation criteria
Share of writes approved without edits; reverted writes under 2%.
13Open items and decisions
Retention of the write log (legal).
14Traceability
Write contract, spec section 4.
15Estimate
3 stories, 11 points (illustrative).
queue 4BA-CRM-F03 · Activity trail and daily digest Wave 1 · Leads and approval
Everything the assistant did on a record can be read back, and each broker receives a daily digest of what was written in their name.
2 User Stories · 2 of them estimated · 6 points known
1Why it exists
Trust is read back, not declared. The trail and the digest are where the broker verifies the assistant every day.
2Problem and context
No audit; surprises discovered weeks later.
3Objective
Every write readable on the record and summarized daily.
4Business value
Disputes end in a minute; the manager reads the same facts.
5Expected behavior
Trail per record.
Daily digest per broker.
6Acceptance criteria
One line per write with the five facts.
Digest sent only when there is content.
7Scope and limits
In: assistant writes.
Out: direct CRM edits.
8Business rules
The trail is stored with the write, never reconstructed.
The broker switches each capability of the assistant to always-allow at their own pace, and switches it back with one tap.
2 User Stories · 0 of them estimated · 0 points known
1Why it exists
Trust grows unevenly across brokers and capabilities. A per-capability switch, with the evidence next to it, lets each broker widen autonomy at their pace.
2Problem and context
Approve-each forever, or automatic for all: both lose brokers.
3Objective
Half the brokers with one capability on always-allow after a month.
4Business value
Fewer approvals; autonomy that is earned and reversible.
Undo rate under always-allow compared with approve-each.
13Open items and decisions
Whether the manager sees each broker's switches (privacy decision).
14Traceability
Autonomy rules, spec section 5.
15Estimate
2 stories, 8 points (illustrative).
BA-FCST The forecast matches the evidence
EpicBA-FCST · The forecast matches the evidence
The stage and the forecast category of each deal follow what happened in visits and proposals, with the reason written next to them.
2 Features · 5 User Stories
1Why it exists
The manager's forecast is a weekly negotiation between what brokers hope and what the CRM shows. Without this Epic the data the other Epics create never reaches the number the company runs on.
2Problem
Stages are updated late and optimistically; forecast categories mean different things to different brokers.
3Objective
A stage suggestion with its reason after every visit and proposal event, and a forecast category derived from evidence, both approved by the broker.
4Success metrics
Deals whose stage matches the last recorded event: from 55% to 90% (illustrative).
Forecast accuracy at month end, measured against closings: a baseline, then plus 15 points.
5First-release scope
Stage suggestion with reason (BA-FCST-F01).
Forecast category from evidence (BA-FCST-F02).
6Business rules
The assistant suggests; the broker decides; the manager sees the reason.
A category change without an event is flagged, not blocked.
7Dependencies
BA-VISIT-F02 and BA-PROP-F03 for the events; BA-CRM-F01 for the writes.
8Risks and mitigation
Risk: brokers feel policed. Mitigation: the reason is shown to the broker first, and the manager sees categories, not brokers' edits.
9Governance and operation
The commercial director owns the category definitions, written in the glossary.
10Technical details
Rules first; a model only for the reason text.
Reads and writes go through the assistant's single CRM write path; every write carries author, previous value, proposed value, written value, origin and approval.
11Estimate
5 User Stories, 18 points (illustrative).
The Features of BA-FCST
queue 12BA-FCST-F01 · Stage suggestion with its reason Wave 4 · Forecast
After a visit outcome or a proposal event, the assistant proposes the deal's stage with the reason, for the broker's approval.
2 User Stories · 0 of them estimated · 0 points known
1Why it exists
The events created by the other Epics are worth nothing to the forecast until they move the stage. This Feature moves it, with the reason written.
The forecast category (commit, likely, possible) is proposed from the stage, the qualification score and the proposal status, with the reason.
3 User Stories · 0 of them estimated · 0 points known
1Why it exists
The category is the number the company runs on. Proposed from three visible inputs, it becomes a fact two people can discuss instead of a hope one person defends.
2Problem and context
Categories mean different things per broker; accuracy unknown.
Every story with its nine sections and its acceptance cases in the Case / Given / When / Then form. A story in a closed sprint keeps its card for the record.
BA-LEAD Leads become qualified conversations10 User Stories
queue 1BA-LEAD-F01 The lead queue with context4 stories
BA-LEAD-F01-US01 · Receive portal leads into one queue done · S3
A lead sent by a portal appears in the broker's queue within a minute, with the portal, the listing and the buyer's message.
As a broker, I want every portal lead in one queue with its listing and message, so that I answer from one place instead of three inboxes.
1Why it exists
Today a lead is an email the broker may read tonight. If the queue does not exist, nothing else in the program has a starting point.
2Context
Three portals send leads by email in three formats; the brokerage also receives walk-in leads typed by the reception.
3Type
Functional
4User Story
As a broker, I want every portal lead in one queue with its listing and message, so that I answer from one place instead of three inboxes.
5Expected behavior
The lead record shows portal, listing code, buyer name, phone, email and the message as written.
Arrival time and the time since arrival are visible on the row.
A lead for a listing the broker does not handle is routed to the listing's broker.
6Out of scope
Replying from the queue (BA-LEAD-F02).
Portal APIs; this story parses emails and imports CSV.
7Technical notes
Email parser per portal with a test fixture per format.
Duplicate check by phone and email across the last 30 days.
8Traceability
Program brief section 2; portal export formats, read on 2026-02-20.
Depends on
none
9Acceptance criteria
Case A portal lead lands in the queueGiven a portal sends a lead email for listing AR-2041When the email is receivedThen the lead is in the broker's queue within one minute with portal, listing and message.
Case A duplicate is mergedGiven the same phone number wrote through two portals in the same weekWhen the second lead arrivesThen the queue shows one lead with both portals listed, not two leads.
Case A lead for another broker's listingGiven the listing belongs to a different brokerWhen the lead arrivesThen it lands in that broker's queue and the first broker does not see it.
BA-LEAD-F01-US02 · Show what is still unknown about the buyer done · S3
Next to each lead the broker sees the questions nobody has answered yet: budget, financing, timing, must-haves.
As a broker, I want to see which qualification facts are missing, so that my first call covers them.
1Why it exists
A broker who calls without knowing what to ask repeats the portal form. The open questions turn the first call into qualification.
2Context
The portal form rarely carries budget or financing; the buyer's message sometimes does.
3Type
Functional
4User Story
As a broker, I want to see which qualification facts are missing, so that my first call covers them.
5Expected behavior
Four facts tracked: budget range, financing status, moving timeline, must-haves.
Facts found in the message are filled with the sentence they came from.
Missing facts are listed as questions in the broker's words.
6Out of scope
Asking the questions automatically (BA-LEAD-F03).
7Technical notes
Extraction from the message text with a confidence flag; low confidence shows as unknown, never as a guess.
8Traceability
Qualification checklist agreed with the sales manager on 2026-02-27.
Case A budget found in the messageGiven the buyer wrote 'up to 900 thousand'When the lead opensThen budget shows 'up to 900 thousand' with the phrase next to it.
Case A fact that is not thereGiven the message says nothing about financingWhen the lead opensThen financing is listed under 'still to ask', not filled with a guess.
BA-LEAD-F01-US03 · Attach the listing facts the buyer will ask about done · S3
The lead shows the listing's price, size, floor, parking and the developer's current conditions, from the catalogue.
As a broker, I want the listing facts next to the lead, so that my first reply is right without opening the catalogue.
1Why it exists
Brokers answer price and conditions from memory and get them wrong when a developer changes a campaign. The catalogue is the source; the lead should read it.
2Context
The brokerage keeps a catalogue with the developer's conditions, updated weekly by the back office.
3Type
Functional
4User Story
As a broker, I want the listing facts next to the lead, so that my first reply is right without opening the catalogue.
5Expected behavior
Price, area, floor, parking, delivery date and current campaign conditions shown with the catalogue's update date.
A listing with no catalogue entry shows 'not in the catalogue' and a link to request it.
Case The facts come from the catalogueGiven listing AR-2041 is in the catalogue with conditions dated last FridayWhen the lead opensThen price, area, floor, parking, delivery and conditions appear with that date.
Case A listing without an entryGiven listing AR-7788 is not in the catalogueWhen the lead opensThen the lead says 'not in the catalogue' and offers the request link; nothing is invented.
BA-LEAD-F01-US04 · Flag leads that are waiting too long S4
A lead with no reply after 30 minutes is highlighted, and the manager sees the count per broker.
As a sales manager, I want to see leads waiting past 30 minutes per broker, so that I redistribute before the hour is lost.
1Why it exists
The hour is lost in silence. A visible timer and a count per broker make the delay a shared fact instead of a private one.
2Context
Brokers are often at visits; the manager redistributes by hand today.
3Type
Functional
4User Story
As a sales manager, I want to see leads waiting past 30 minutes per broker, so that I redistribute before the hour is lost.
5Expected behavior
Rows turn amber at 30 minutes and red at 60.
The manager's view counts waiting leads per broker.
Redistribution is a manual action by the manager with a reason.
6Out of scope
Automatic redistribution.
7Technical notes
Timer from arrival time; the manager's view reads the same records.
Case A lead crosses 30 minutesGiven a lead arrived 31 minutes ago with no replyWhen the queue refreshesThen the row is amber and counts in the manager's view.
Case A manual redistributionGiven the manager moves the lead to another broker with a reasonWhen the move is savedThen the lead appears in the new queue, and the trail records who moved it and why.
queue 2BA-LEAD-F02 The first reply, drafted and sent after approval3 stories
BA-LEAD-F02-US01 · Draft the first reply from the lead and the listing done · S3
For each new lead the assistant drafts a reply that answers what the buyer asked, with the listing facts, and asks one qualification question.
As a broker, I want a drafted reply that answers the buyer and asks one question, so that I only review and send.
1Why it exists
The broker writes the same reply forty times a month from memory. A draft that already has the facts turns a ten-minute task into a one-minute review.
2Context
Replies go by WhatsApp or email depending on the portal; tone is the brokerage's, short and concrete.
3Type
Functional
4User Story
As a broker, I want a drafted reply that answers the buyer and asks one question, so that I only review and send.
5Expected behavior
The draft answers each question in the buyer's message with a catalogue fact or says the broker will confirm.
Exactly one qualification question from the open list.
The draft is stored until the broker approves or discards it.
6Out of scope
Sending without approval.
Replies to follow-up messages (later wave).
7Technical notes
Model call with the listing facts and the message as context; the draft shows which fact each sentence used.
8Traceability
Reply tone guide, sales manager, 2026-03-02.
Depends on
none
9Acceptance criteria
Case A draft answers the question askedGiven the buyer asked about parkingWhen the draft is generatedThen it states the parking from the catalogue and asks one open question.
Case A fact not in the catalogueGiven the buyer asked about the condominium fee and the catalogue has noneWhen the draft is generatedThen the draft says the broker will confirm the fee; it never states a number.
Case A never-case: no invented discountGiven the buyer asked for a discountWhen the draft is generatedThen the draft contains no discount or condition absent from the catalogue.
BA-LEAD-F02-US02 · Edit, approve and send the reply from the queue done · S3
The broker edits the draft in place, approves, and the reply is sent through the lead's channel from the broker's own identity.
As a broker, I want to approve and send from the queue, so that the reply leaves in one click.
1Why it exists
A draft that has to be copied into another app is a draft nobody uses.
2Context
WhatsApp through the brokerage's business account; email through the broker's mailbox.
3Type
Functional
4User Story
As a broker, I want to approve and send from the queue, so that the reply leaves in one click.
5Expected behavior
Approve sends; discard records the reason; edit keeps the original for comparison.
The sent reply is written to the lead's timeline with the time.
6Out of scope
Scheduling the send for later.
7Technical notes
Channel adapters for WhatsApp business and email; the send is logged as a write through the single write path.
Case Approve sends through the right channelGiven the lead came from a portal that provides a phone numberWhen the broker approvesThen the reply goes by WhatsApp from the brokerage account and appears on the timeline.
Case Discard records a reasonGiven the broker discards the draftWhen the discard is confirmedThen the reason is stored and the lead stays in the queue as unanswered.
BA-LEAD-F02-US03 · Learn from the broker's edits S4
Edits made before approval are kept and summarized so the next drafts for the same broker get closer to how they write.
As a product manager, I want the edits measured and fed back, so that drafts improve and I can prove it.
1Why it exists
If the draft never improves, the broker stops editing and starts rewriting, and the time saving is gone.
2Context
Edits are small and repeated: greeting, closing, how prices are written.
3Type
Evaluation
4User Story
As a product manager, I want the edits measured and fed back, so that drafts improve and I can prove it.
5Expected behavior
Edit distance per draft stored.
A weekly eval run on the golden set reports the share of drafts approved without edits.
Style notes per broker derived from repeated edits, shown to the broker and editable.
6Out of scope
Fine-tuning a model.
7Technical notes
Golden set of 40 leads with approved replies; rubric: answers the question, one question asked, tone, no invented fact.
Case The weekly number existsGiven a week of drafts has been approved or editedWhen the eval runsThen the report shows the share approved without edits and the edit distance median.
Case A style note is proposedGiven the broker changed the closing in five of five draftsWhen the week endsThen the style note 'closing: ...' is proposed to the broker, who can accept or delete it.
queue 8BA-LEAD-F03 Qualification questions and a score3 stories
BA-LEAD-F03-US01 · Ask the open questions one at a time
When the buyer replies, the assistant drafts the next message with the next open question, until the four facts are known.
As a broker, I want the next question drafted when the buyer answers, so that qualification happens in the conversation.
1Why it exists
Asking four questions at once reads like a form; one at a time reads like a broker.
2Context
The conversation runs on WhatsApp; the broker approves each message in the first release.
3Type
Functional
4User Story
As a broker, I want the next question drafted when the buyer answers, so that qualification happens in the conversation.
5Expected behavior
Next question chosen from the open list in a fixed order: timing, budget, financing, must-haves.
The buyer's answer is proposed as the fact, with the phrase, for approval.
No question is repeated.
6Out of scope
Automatic sending (tier 3) in this release.
7Technical notes
Conversation state per lead; each proposed fact is a write through BA-CRM-F01.
Case The next question follows the orderGiven timing is known and budget is notWhen the buyer repliesThen the draft asks the budget question only.
Case An answer becomes a proposed factGiven the buyer wrote 'we have the financing approved'When the message is readThen financing is proposed as 'approved' with the phrase, for the broker to approve.
BA-LEAD-F03-US02 · Keep a qualification score the broker can explain
Each lead shows a score from 0 to 4, one point per known fact that fits the listing, with the reason per point.
As a broker, I want a score I can explain to the manager, so that visit priority is not a gut feeling.
1Why it exists
A score nobody can explain is a score nobody trusts. Four facts, four points, each with its reason.
2Context
The sales manager wants to prioritize visits by score.
3Type
Functional
4User Story
As a broker, I want a score I can explain to the manager, so that visit priority is not a gut feeling.
5Expected behavior
Score = number of facts known and compatible with the listing.
Each point shows its reason; an incompatible fact shows why.
The score sorts the queue when the broker chooses.
Case A point with its reasonGiven budget 'up to 900 thousand' and the listing costs 850 thousandWhen the score is computedThen budget counts one point with the reason 'within budget'.
Case An incompatible factGiven the buyer needs delivery this year and the listing delivers in two yearsWhen the score is computedThen timing counts zero with the reason shown, and the lead is not hidden.
BA-LEAD-F03-US03 · Suggest a better-fitting listing when the facts do not match
When two or more facts do not fit the listing, the assistant proposes up to three listings from the catalogue that do.
As a broker, I want alternatives proposed when the fit is poor, so that I keep the buyer instead of the listing.
1Why it exists
A lead that does not fit the listing is not a lost lead; it is a lead for another listing. Today it is lost.
2Context
The catalogue has the facts needed to match budget, timing and must-haves.
3Type
Functional
4User Story
As a broker, I want alternatives proposed when the fit is poor, so that I keep the buyer instead of the listing.
5Expected behavior
Up to three alternatives with the matching facts shown.
The broker picks one or none; the pick is written as the lead's listing with the previous one kept.
No alternative is sent to the buyer without approval.
6Out of scope
Cross-brokerage listings.
7Technical notes
Catalogue query by budget band, delivery date and must-haves.
Case Alternatives are offeredGiven budget and timing do not fit the listingWhen the lead opensThen up to three listings appear with the facts that match, and the original listing stays.
Case No alternative existsGiven nothing in the catalogue fits the budgetWhen the lead opensThen the assistant says so; it does not stretch the budget.
BA-VISIT Every visit has a prepared broker and a recorded outcome9 User Stories
queue 5BA-VISIT-F01 The visit preparation sheet3 stories
BA-VISIT-F01-US01 · Build the sheet from the lead and the catalogue S4
The sheet assembles the unit facts, the campaign conditions, the buyer's four facts and the open questions, on one phone screen.
As a broker, I want one page with everything I need for the visit, so that I walk in prepared.
1Why it exists
The broker prepares from PDFs in a chat thread; one page beats five attachments.
2Context
Visits are confirmed the day before; the sheet is read in the car.
3Type
Functional
4User Story
As a broker, I want one page with everything I need for the visit, so that I walk in prepared.
5Expected behavior
Unit facts, conditions with date, buyer facts, open questions, last conversation.
Readable on a phone, offline once opened.
6Out of scope
Editing catalogue data.
7Technical notes
Server-rendered page cached on the device.
8Traceability
Program brief section 5.
Depends on
none
9Acceptance criteria
Case The sheet has the four blocksGiven a visit is scheduled for listing AR-2041 with lead 1180When the sheet opensThen it shows unit facts, conditions dated, the buyer's facts and the open questions.
Case Offline readingGiven the sheet was opened once with networkWhen the broker opens it in the car without networkThen the sheet is readable.
BA-VISIT-F01-US02 · Compare with two similar units
The sheet shows two comparable units from the catalogue with price per square meter, so the broker can answer 'is this expensive'.
As a broker, I want two comparables on the sheet, so that I answer the price objection with numbers.
1Why it exists
The first objection at a visit is the price; a comparison on the sheet answers it with facts.
2Context
Comparables by area band, neighborhood and delivery date.
3Type
Functional
4User Story
As a broker, I want two comparables on the sheet, so that I answer the price objection with numbers.
5Expected behavior
Two units from the same neighborhood and area band, price per square meter shown.
The comparables' dates shown; no comparable older than 60 days.
6Out of scope
Comparables outside the brokerage's catalogue.
7Technical notes
Catalogue query; price per square meter computed from price and private area.
Case Two comparables appearGiven the catalogue has three units in the bandWhen the sheet opensThen two appear with price per square meter and dates.
Case No comparable is recentGiven all candidates are older than 60 daysWhen the sheet opensThen the block says 'no recent comparable' instead of showing stale ones.
BA-VISIT-F01-US03 · Remind the broker of the sheet before the visit
Two hours before a visit the broker receives the sheet link; opening it is recorded for the KPI.
As a broker, I want the sheet sent before the visit, so that I do not have to look for it.
1Why it exists
A sheet that is not opened does not prepare anyone, and the KPI needs the opening to be a fact.
2Context
Reminders by WhatsApp to the broker, not the buyer.
3Type
Functional
4User Story
As a broker, I want the sheet sent before the visit, so that I do not have to look for it.
5Expected behavior
Reminder two hours before, with the link.
Opening is logged with time and device.
6Out of scope
Reminders to the buyer (BA-VISIT-F03).
7Technical notes
Scheduled job from the visit time; open event through the single write path as an activity.
Case The slot is writtenGiven the buyer replied 'Tuesday 11:00'When the broker approvesThen the calendar has the event, the CRM has the visit, and the buyer receives the confirmation.
Case The slot is no longer freeGiven another visit took Tuesday 11:00 meanwhileWhen the broker approvesThen the assistant says the slot is gone and offers the next two.
BA-VISIT-F03-US03 · Remind the buyer the day before
The buyer receives a reminder with the address and the broker's name the day before, after the broker's approval or automatically once the capability is on always-allow.
As a broker, I want the buyer reminded the day before, so that fewer visits are no-shows.
1Why it exists
No-shows are the silent cost of visits; a reminder cuts them.
2Context
Reminders are the first capability the brokers will want on always-allow.
3Type
Functional
4User Story
As a broker, I want the buyer reminded the day before, so that fewer visits are no-shows.
5Expected behavior
Reminder at 18:00 the day before with address and name.
Tier 2 by default; tier 3 when the broker switches always-allow (BA-CRM-F02).
6Out of scope
Reminders for the stand.
7Technical notes
Scheduled send; always-allow checked at send time.
Case Reminder under approvalGiven always-allow is offWhen 18:00 the day beforeThen the broker sees the reminder to approve; nothing is sent before.
Case Reminder on always-allowGiven the broker switched reminders to always-allowWhen 18:00 the day beforeThen the reminder is sent and logged with 'always-allow' as the approval.
queue 7BA-VISIT-F02 Visit outcome by voice or text3 stories
BA-VISIT-F02-US01 · Turn a voice note into proposed fields S4
The broker records a voice note after the visit; the assistant transcribes it and proposes interest level, objections, next step and date, each with the phrase it came from.
As a broker, I want to say what happened and see the fields proposed, so that the CRM is updated before I reach the next visit.
1Why it exists
The outcome is spoken in the car and typed never. Voice is the only channel that will be used within the hour.
2Context
Transcription in Portuguese; fields in the CRM's vocabulary.
3Type
Functional
4User Story
As a broker, I want to say what happened and see the fields proposed, so that the CRM is updated before I reach the next visit.
5Expected behavior
Transcript kept as evidence.
Four fields proposed, each with the source phrase.
Amounts and dates shown next to the phrase; unclear values proposed as unknown.
6Out of scope
Writing without approval.
7Technical notes
Speech to text, then field extraction; the preview is BA-CRM-F01's.
8Traceability
Program brief section 6; CRM field list.
Depends on
none
9Acceptance criteria
Case Fields with their phrasesGiven the broker said 'they liked it, worried about the fee, will decide by Friday'When the note is processedThen interest high, objection 'condominium fee', next step 'decision', date Friday, each with its phrase.
Case An unclear amountGiven the broker said 'maybe around eight something'When the note is processedThen no amount is proposed; the field says unknown with the phrase.
BA-VISIT-F02-US02 · Type the outcome when voice is not possible
The same four fields can be filled from a short typed message, with the same preview.
As a broker, I want to type the outcome when I cannot speak, so that nothing waits for the office.
1Why it exists
In a developer's stand the broker cannot record; typing must produce the same result.
2Context
Text through the assistant's chat.
3Type
Functional
4User Story
As a broker, I want to type the outcome when I cannot speak, so that nothing waits for the office.
5Expected behavior
Same extraction and preview as the voice path.
A message with no outcome content asks one question back.
Case Text produces the same fieldsGiven the broker typed 'liked it, fee objection, decides Friday'When the message is readThen the same four fields are proposed as from voice.
Case A message without outcomeGiven the broker typed 'visit done'When the message is readThen the assistant asks what the buyer said, and proposes nothing.
BA-VISIT-F02-US03 · Block the stage change without an outcome
A deal cannot move to the next stage while its last visit has no recorded outcome; the broker is told what is missing.
As a sales manager, I want stage changes blocked without an outcome, so that the pipeline reads what happened.
1Why it exists
Stages move on hope; the outcome is the evidence. The block is what makes the forecast read evidence.
2Context
Stage changes happen in the CRM and through the assistant.
3Type
Functional
4User Story
As a sales manager, I want stage changes blocked without an outcome, so that the pipeline reads what happened.
5Expected behavior
Block with the reason and a link to record the outcome.
Case The block explains itselfGiven the last visit has no outcomeWhen the broker moves the stageThen the move is refused with 'record the outcome of the visit on April 2' and a link.
Case The manager overridesGiven the manager moves the stage with a reasonWhen the move is savedThen the stage changes and the trail shows the override and the reason.
BA-PROP Proposals are followed up on time8 User Stories
queue 9BA-PROP-F01 Follow-up reminders and drafts3 stories
BA-PROP-F01-US01 · Set a next step and a date on every proposal
A proposal cannot be saved without a next step and a date; the assistant proposes both from the outcome of the visit.
As a broker, I want the next step and date proposed when I create the proposal, so that no proposal is born silent.
1Why it exists
A proposal without a next step is the definition of silence.
2Context
Proposals are created after a visit, from the outcome.
3Type
Functional
4User Story
As a broker, I want the next step and date proposed when I create the proposal, so that no proposal is born silent.
5Expected behavior
Next step from a fixed list: buyer decision, developer answer, document, counter-proposal.
Date proposed from the buyer's phrase or three working days by default.
Case The proposal gets a step and a dateGiven the visit outcome said 'decides Friday'When the proposal is createdThen next step 'buyer decision', date Friday, both in the preview.
Case No phrase to readGiven the outcome has no dateWhen the proposal is createdThen next step 'buyer decision', date in three working days, flagged as default.
BA-PROP-F01-US02 · Draft the follow-up when the date arrives
On the date, the broker receives a drafted message for the buyer or the developer, with the proposal's facts and the question to ask.
As a broker, I want the follow-up drafted on the date, so that I send instead of writing.
1Why it exists
The reminder alone is ignored; the drafted message is sent.
2Context
Buyer follow-ups by WhatsApp; developer follow-ups by email.
3Type
Functional
4User Story
As a broker, I want the follow-up drafted on the date, so that I send instead of writing.
5Expected behavior
Draft with unit, value, date of the proposal and the one question.
Approve sends; snooze moves the date with a reason.
6Out of scope
Automatic sending.
7Technical notes
Scheduled job; draft through the model with the proposal facts; send through the channel adapter.
Case A buyer follow-up is draftedGiven the next step is 'buyer decision' and the date is todayWhen the morning job runsThen the broker has a drafted message with the unit, the value and the question.
Case Snooze moves the dateGiven the broker snoozes for two days with a reasonWhen the snooze is savedThen the date moves, the reason is in the trail, and no message is sent.
BA-PROP-F01-US03 · Show the manager the silent proposals
The manager's view lists proposals past their date with the days of silence per broker.
As a sales manager, I want silent proposals per broker, so that Monday's review starts from facts.
1Why it exists
The number only moves when someone sees it weekly.
2Context
The manager reviews the pipeline on Mondays.
3Type
Functional
4User Story
As a sales manager, I want silent proposals per broker, so that Monday's review starts from facts.
Case A silent proposal is listedGiven a proposal's date was eight days ago with no activityWhen the manager opens the viewThen it appears with 8 days and the broker's name.
Case A proposal with activity is not silentGiven a follow-up was sent yesterdayWhen the manager opens the viewThen the proposal is not listed.
queue 10BA-PROP-F02 Counter-proposal preview with the developer's rules2 stories
BA-PROP-F02-US01 · Check a counter-proposal against the developer's table
The broker enters the buyer's offer; the assistant shows whether discount, down payment and installments fit the developer's table, rule by rule.
As a broker, I want the offer checked against the table before I send it, so that I do not promise what the developer refuses.
1Why it exists
Brokers learn the rules by being refused. The table exists; the check should read it.
2Context
Each developer has a table per project, dated, kept by the back office.
3Type
Functional
4User Story
As a broker, I want the offer checked against the table before I send it, so that I do not promise what the developer refuses.
5Expected behavior
Three checks: discount ceiling, minimum down payment, maximum installments.
Each check shows the rule and the table's date.
An offer outside the rules is not blocked; it is flagged with what would make it fit.
6Out of scope
Negotiating with the developer.
7Technical notes
Table lookup by project; the preview is read-only.
8Traceability
Commercial rules, 2026-03-10.
Depends on
none
9Acceptance criteria
Case A discount over the ceilingGiven the table allows 5% and the offer asks 8%When the check runsThen the discount line is flagged with 'ceiling 5%, table of March 3' and the rest pass.
Case A table that is out of dateGiven the project's table is older than 30 daysWhen the check runsThen the preview says the table may be stale and names the back office contact.
BA-PROP-F02-US02 · Draft the counter-proposal message from the checked offer
Once the offer fits or the broker accepts the flags, the assistant drafts the message to the developer with the offer and the buyer's facts.
As a broker, I want the counter-proposal drafted from the checked offer, so that I send a complete message in one go.
1Why it exists
The message to the developer is the same every time and still takes twenty minutes.
2Context
Developer messages go by email with a fixed structure.
3Type
Functional
4User Story
As a broker, I want the counter-proposal drafted from the checked offer, so that I send a complete message in one go.
5Expected behavior
Draft with unit, offer, payment plan, buyer qualification facts.
Flags, if accepted, are stated as requests, not hidden.
Sent after approval.
6Out of scope
Generating the proposal PDF.
7Technical notes
Template plus model for the free text; send through email adapter.
Case A complete draftGiven the offer passed the checksWhen the draft is generatedThen it carries unit, offer, plan and the four buyer facts.
Case A flag becomes a requestGiven the broker accepted the discount flagWhen the draft is generatedThen the discount is stated as a request to the developer, with the rule quoted.
queue 14BA-PROP-F03 Proposal status synced from the developer's system3 stories
BA-PROP-F03-US01 · Import the developer's proposal export daily
A daily import reads the developer's CSV export and matches each line to a proposal by number and buyer document.
The assistant imports the developer export daily and matches lines to proposals, so that status changes can be proposed to the broker.
1Why it exists
Developers answer in their own system; the broker learns by phone. The export is the only honest source.
2Context
Two developers provide a daily CSV; others are later.
3Type
Enabler. No persona: an Enabler builds what the other stories need.
4User Story
The assistant imports the developer export daily and matches lines to proposals, so that status changes can be proposed to the broker.
Case A line matchesGiven the export has proposal 5521 for buyer document ending 44When the import runsThen the line is linked to the proposal and nothing is written yet.
Case A line does not matchGiven the export has a proposal number the CRM does not knowWhen the import runsThen the line is in the unmatched report; no proposal is created.
BA-PROP-F03-US02 · Propose the status change to the broker
When the developer's status differs from the CRM, the broker sees a proposed change with the developer's value and date, for approval.
As a broker, I want status changes proposed with the developer's value, so that I approve what I can explain to the buyer.
1Why it exists
A status written without the broker seeing it is the kind of write that breaks trust.
2Context
Statuses: under analysis, accepted, refused, counter.
3Type
Functional
4User Story
As a broker, I want status changes proposed with the developer's value, so that I approve what I can explain to the buyer.
5Expected behavior
Proposed change in the preview with old value, new value and the export's date.
Approve writes; refuse records a reason and keeps the line for the back office.
6Out of scope
Automatic writes (tier 3) in this release.
7Technical notes
Preview through BA-CRM-F01; refuse feeds the unmatched report.
Case A change is proposedGiven the export says 'accepted' and the CRM says 'under analysis'When the import runsThen the broker sees the proposed change with the date and approves or refuses.
Case No differenceGiven the export and the CRM agreeWhen the import runsThen nothing is proposed.
BA-PROP-F03-US03 · Measure the sync and its failures
A weekly report shows the share of proposals in sync, the unmatched lines and the time from export to CRM.
As a product manager, I want the sync measured weekly, so that drift is caught before the forecast reads it.
1Why it exists
A sync nobody measures drifts in a month.
2Context
Report in the manager's digest.
3Type
Evaluation
4User Story
As a product manager, I want the sync measured weekly, so that drift is caught before the forecast reads it.
Case The number is in the digestGiven a week of imports ranWhen the digest is builtThen it shows in-sync share, unmatched lines and median delay.
BA-CRM The broker approves what the assistant writes7 User Stories
queue 3BA-CRM-F01 Field-by-field preview and approval3 stories
BA-CRM-F01-US01 · Create the single write path to the CRM done · S3
All CRM writes from the assistant go through one service that records author, previous value, proposed value, written value, origin and approval.
The assistant writes to the CRM only through one path that records every write, so that the trail and the undo exist from day one.
1Why it exists
Two write paths diverge on the first correction. One path is what makes the trail and the undo possible.
2Context
The CRM exposes a REST API with field-level writes.
3Type
Enabler. No persona: an Enabler builds what the other stories need.
4User Story
The assistant writes to the CRM only through one path that records every write, so that the trail and the undo exist from day one.
5Expected behavior
One service; no other code calls the CRM write API.
Every write stored with the six attributes.
A write without an approval reference is refused.
6Out of scope
Reads.
7Technical notes
Service with a contract table (object, field, allowed values); refusal is an error, not a silent skip.
8Traceability
Write contract, spec section 4.
Depends on
none
9Acceptance criteria
Case A write without approval is refusedGiven a caller sends a write with no approval referenceWhen the service receives itThen the write is refused and logged as refused.
Case A write stores six attributesGiven a broker approved a stage changeWhen the write is madeThen the record carries author, previous, proposed, written value, origin and approval.
BA-CRM-F01-US02 · Show the preview with old and new values done · S3
Before a write, the broker sees each field with its old value, the proposed value and the phrase or source it came from, and approves or edits per field.
As a broker, I want each field shown with old, new and source, so that I approve what I understand.
1Why it exists
Approval of a block is approval of nothing; the broker has to see each field.
2Context
Preview in the assistant's chat and in the web app.
3Type
Functional
4User Story
As a broker, I want each field shown with old, new and source, so that I approve what I understand.
5Expected behavior
Old value, new value, source per field.
Approve all, approve one, edit one, discard with reason.
Edited values are written as edited, with the original kept.
6Out of scope
Previews for other brokers' records.
7Technical notes
Rendered from the proposed writes; edits create new proposed values with origin 'broker'.
Case Each field is visibleGiven three fields are proposedWhen the preview opensThen each shows old, new and source, with its own approve.
Case An edit is recorded as an editGiven the broker changes the proposed dateWhen the broker approvesThen the written value is the edited one and the trail shows both.
BA-CRM-F01-US03 · Undo any write for 24 hours S4
The broker can undo any write made through the assistant within 24 hours; the previous value is restored and the undo is recorded.
As a broker, I want to undo a write within a day, so that approving is not a risk.
1Why it exists
An undo the broker trusts is what lets them approve faster.
2Context
Undo from the trail or the preview confirmation.
3Type
Functional
4User Story
As a broker, I want to undo a write within a day, so that approving is not a risk.
5Expected behavior
Undo restores the previous value through the same write path.
Undo recorded with its reason.
A field changed meanwhile by someone else is not overwritten; the broker is told.
6Out of scope
Undo after 24 hours (back office request).
7Technical notes
Compare current value with the written value before restoring.
Case Undo restores the valueGiven a stage was written ten minutes agoWhen the broker undoesThen the previous stage is restored and the trail shows the undo.
Case Someone else changed the fieldGiven the manager changed the stage after the writeWhen the broker undoesThen nothing is overwritten and the broker sees who changed it.
queue 4BA-CRM-F03 Activity trail and daily digest2 stories
BA-CRM-F03-US01 · Show the trail on the record done · S3
On any lead, visit or proposal, a trail lists what the assistant proposed, what the broker approved or edited, and when, in plain sentences.
As a broker, I want to read what the assistant did on a record, so that I can explain it to the buyer and the manager.
1Why it exists
A write someone cannot read back is a write someone will dispute.
2Context
Trail in the CRM record and in the app.
3Type
Functional
4User Story
As a broker, I want to read what the assistant did on a record, so that I can explain it to the buyer and the manager.
5Expected behavior
One line per write: field, old, new, who approved, when.
Grouped per day.
Links to the source phrase when it exists.
6Out of scope
Trails for human writes made directly in the CRM.
7Technical notes
Rendered from the write log.
8Traceability
Write contract, spec section 4.
Depends on
none
9Acceptance criteria
Case A write reads as a sentenceGiven the stage changed from visit to proposal on TuesdayWhen the trail opensThen it reads 'stage: visit to proposal, approved by you, Tuesday 16:10, from the visit outcome'.
BA-CRM-F03-US02 · Send the daily digest S4
At 18:30 each broker receives an email with what was written in their name that day, what is waiting for approval and what is silent.
As a broker, I want a daily digest of what was written and what waits, so that I end the day knowing.
1Why it exists
The digest is the daily contract: nothing happened that the broker did not see by evening.
2Context
Email; the manager's digest is a separate story.
3Type
Functional
4User Story
As a broker, I want a daily digest of what was written and what waits, so that I end the day knowing.
5Expected behavior
Three blocks: written today, waiting for approval, silent items.
As a broker, I want to switch a capability to always-allow when I trust it, so that I stop approving what I never edit.
5Expected behavior
Per capability: approvals, edits, undos in the last 30 days next to the switch.
A capability with an undo in the last 7 days cannot be switched on; the reason is shown.
Switching is recorded in the trail.
6Out of scope
Global switches; manager overrides.
7Technical notes
Settings stored per broker; checked at send or write time.
8Traceability
Autonomy rules, spec section 5.
Depends on
none
9Acceptance criteria
Case The evidence is next to the switchGiven reminders were approved 20 times with no editWhen settings openThen the switch shows 20 approvals, 0 edits, 0 undos and can be turned on.
Case A recent undo blocks the switchGiven an outcome write was undone three days agoWhen the broker tries to switch outcomes to always-allowThen the switch stays off with 'an undo in the last 7 days'.
BA-CRM-F02-US02 · Pause always-allow with one tap, everywhere
From any message or write made under always-allow, the broker can pause the capability for a day or switch it back to approve-each.
As a broker, I want to pause always-allow from where I see the result, so that switching on is safe.
1Why it exists
Autonomy without a brake is autonomy nobody switches on.
2Context
Pause from the chat, the app and the digest.
3Type
Functional
4User Story
As a broker, I want to pause always-allow from where I see the result, so that switching on is safe.
5Expected behavior
Pause for 24 hours or switch back, from the message itself.
Case Pause from the messageGiven a reminder went out under always-allowWhen the broker taps pauseThen the capability is paused for 24 hours and the trail records it.
BA-FCST The forecast matches the evidence5 User Stories
queue 12BA-FCST-F01 Stage suggestion with its reason2 stories
BA-FCST-F01-US01 · Propose the stage from the last event
A rule table maps events to stages: first reply, visit held, proposal made, developer answer. After each event the stage is proposed with the rule as the reason.
As a broker, I want the stage proposed from what happened, with the rule shown, so that I approve a fact.
1Why it exists
Stages move on hope today; the rule table moves them on events.
2Context
Five stages agreed with the commercial director.
3Type
Functional
4User Story
As a broker, I want the stage proposed from what happened, with the rule shown, so that I approve a fact.
5Expected behavior
Rule table with event, stage and reason text.
Proposal through the preview, with the event linked.
No stage goes backwards without the broker's explicit choice.
6Out of scope
Automatic stage writes.
7Technical notes
Rules; the preview is BA-CRM-F01's.
8Traceability
Forecast rules 2026-03-10.
Depends on
none
9Acceptance criteria
Case A visit held proposes the stageGiven a visit outcome was recordedWhen the write is approvedThen the stage 'visited' is proposed with 'visit held on April 2' as the reason.
Case No backwards moveGiven the proposal was refused by the developerWhen the event is recordedThen the assistant proposes 'counter or close' and never 'lead'.
BA-FCST-F01-US02 · Flag a stage changed without an event
A stage changed by hand with no event behind it is flagged to the manager with the broker's reason, not blocked.
As a sales manager, I want stages changed without an event listed with the reason, so that I review exceptions, not everything.
1Why it exists
Flagging keeps the broker's freedom and gives the manager the exception list.
2Context
Manual stage changes happen in the CRM.
3Type
Functional
4User Story
As a sales manager, I want stages changed without an event listed with the reason, so that I review exceptions, not everything.
5Expected behavior
Flag with broker, deal, old and new stage, reason.
Case A manual change is flaggedGiven the broker moved a deal to 'proposal' with no proposal recordedWhen the weekly check runsThen the change is listed with the reason the broker typed, or 'no reason'.
queue 13BA-FCST-F02 Forecast category from evidence3 stories
BA-FCST-F02-US01 · Propose the category with its three inputs
The category is proposed from stage, score and proposal status, and the preview shows the three inputs and the rule.
As a broker, I want the category proposed with its inputs, so that the manager and I argue about facts.
1Why it exists
A category with its inputs visible is a category two people can discuss.
2Context
Three categories, defined by the commercial director.
3Type
Functional
4User Story
As a broker, I want the category proposed with its inputs, so that the manager and I argue about facts.
5Expected behavior
Rule table: stage × score × status to category.
Preview with the three inputs.
The broker can keep their own category with a reason, recorded.
6Out of scope
Weighted probabilities.
7Technical notes
Rules; preview through BA-CRM-F01.
8Traceability
Forecast rules 2026-03-10.
Depends on
none
9Acceptance criteria
Case A category from three inputsGiven stage 'proposal', score 4, status 'under analysis'When the proposal runsThen category 'likely' is proposed with the three inputs shown.
Case The broker disagreesGiven the broker keeps 'commit' with a reasonWhen the choice is savedThen the category is 'commit', the reason is in the trail, and the manager sees the disagreement.
BA-FCST-F02-US02 · Show the manager the forecast with its reasons
The manager's forecast view lists deals by category with the reason and the disagreements, and the month-end accuracy once closings are known.
As a sales manager, I want the forecast by category with reasons and the accuracy at month end, so that the meeting reads evidence.
1Why it exists
The weekly forecast meeting is where this program is judged.
2Context
Monday review; month-end closing data from the developers.
3Type
Functional
4User Story
As a sales manager, I want the forecast by category with reasons and the accuracy at month end, so that the meeting reads evidence.
5Expected behavior
Deals by category with reason and disagreement flag.
Month-end accuracy per category, computed from closings.
Case A rule is scoredGiven February closings are inWhen the monthly eval runsThen each rule shows deals, closings and accuracy, and the ones under 60% twice are flagged.
Improvements and bugs
Items that came from the pilot. A bug card describes what was seen and what was expected, and asks for the origin of the data to be verified; it never asserts the cause.
improvement asked by a broker or the manager · bug seen in the pilot
IMP01 · Show the time since arrival in minutes under one hour, hours after done · S3
improvement · Feature BA-LEAD-F01 · 1 points
The queue showed '0 h' for a lead that arrived 40 minutes ago; brokers read it as fresh.
IMP02 · Keep the draft's original when the broker edits S4
improvement · Feature BA-LEAD-F02 · 2 points
Brokers asked to see what the assistant wrote before their edit, to decide whether to keep editing.
BUG01 · A lead with two phone numbers was imported twice not scheduled
bug · Feature BA-LEAD-F01 · 2 points
Seen on 2026-04-02 on a portal lead with a landline and a mobile number. Both records show the same message. Origin of the second number to be verified with the portal.
BUG02 · The preview showed the old value of a field changed by the broker a minute before S4
bug · Feature BA-CRM-F01 · 3 points
Seen on 2026-04-08. The preview read the record before the broker's own edit was saved. Expected: the preview reads the current value. The source of the read to be verified.
Brokers' wishlist
What brokers and the manager asked for, with its status. A wish is not a backlog item until it has a why, a scope and an estimate.
Faster answers
Let the assistant answer the fee and parking questions without me when the catalogue has them.evaluating
a broker, Monday review
Depends on always-allow for first replies, which stays off until the eval set passes.
Propose a visit slot in the first reply.planned
a broker, pilot feedback
Open item in BA-LEAD-F02; decision with BA-VISIT-F03.
Less typing
Record the visit outcome from the stand's tablet, not only from my phone.new
two brokers, pilot feedback
Needs the stand devices; no estimate.
A weekly digest for managers with silent proposals and exceptions.in the backlog
the sales manager
Fed by BA-PROP-F01-US03 and BA-FCST-F01-US02; the digest itself is a later Feature.
Sources
Program brief, sections 2 to 7. The problem, the queue, the reply, the visit, the proposal and the digest, agreed with the sales manager on 2026-02-27.
Portal export formats, read on 2026-02-20. The three email formats and the CSV fallback.
Developer export formats, 2026-03-18. The two developers' daily CSV.
Write contract, spec section 4. The single write path, the six attributes, the undo.
Eval plan, spec section 3. Golden sets, rubrics and thresholds per probabilistic behavior.
Glossary
Term
Meaning
Where
Always-allow
A per-broker, per-capability setting that lets the assistant act without approving each action.
BA-CRM-F02, BA-VISIT-F03
Catalogue
The brokerage's list of units with price, conditions and stand hours, kept by the back office and dated.
BA-LEAD-F01, BA-VISIT-F01
Category
Commit, likely or possible: how sure the company is that a deal closes this month.
BA-FCST-F02
Developer
The company that builds and sells the launch; it sets discount and payment rules and answers proposals.
BA-PROP
Enabler
A story that builds something the other stories need and that no broker sees directly. It has no persona.
BA-CRM-F01-US01, BA-PROP-F03-US01
Golden set
A fixed set of real, anonymized inputs with the expected result, used to score a probabilistic behavior.
Evaluation sections
Lead
A buyer who wrote about a listing through a portal or walked in.
BA-LEAD
Never-case
A behavior with zero tolerance, scored separately: an invented price, a write without approval.
Evaluation sections
Points
Fibonacci story points (1, 2, 3, 5, 8, 13) set by the developer who will build the story; 0 means not estimated.
Planning
Preview
The screen where a proposed write shows old value, new value and source, per field, before the broker approves.
BA-CRM-F01
Stage
Where a deal is: lead, visited, proposal, counter or close, closed.
BA-FCST-F01
Stand
The developer's sales office at the launch, with its own opening hours.
BA-VISIT-F03
Trail
The list of what the assistant proposed and the broker approved on a record, stored with each write.
BA-CRM-F03
Wave
A delivery group that ends with something a broker uses in production; the order dependencies may not cross.
Waves of delivery
Write path
The single service through which every write to the CRM passes, recording six attributes.
BA-CRM-F01-US01
How this backlog loads into the tracker
The tracker is the system of record and this document is the review. Loading happens after the review, in this order: the Epic, then its Features in queue order, then each Feature's stories, so every parent exists before its children and the Story Points field is filled from the plan exported above. Load one item first, check how it renders on the board, then the batch. In the original, this chapter writes owner, points and sprint to Azure DevOps from the browser, with a token that lives only in the open tab. This public version exports the plan instead.
Creation order · 58 items
BA-LEAD
BA-LEAD-F01
BA-LEAD-F01-US01
BA-LEAD-F01-US02
BA-LEAD-F01-US03
BA-LEAD-F01-US04
BA-LEAD-F02
BA-LEAD-F02-US01
BA-LEAD-F02-US02
BA-LEAD-F02-US03
BA-LEAD-F03
BA-LEAD-F03-US01
BA-LEAD-F03-US02
BA-LEAD-F03-US03
BA-VISIT
BA-VISIT-F01
BA-VISIT-F01-US01
BA-VISIT-F01-US02
BA-VISIT-F01-US03
BA-VISIT-F03
BA-VISIT-F03-US01
BA-VISIT-F03-US02
BA-VISIT-F03-US03
BA-VISIT-F02
BA-VISIT-F02-US01
BA-VISIT-F02-US02
BA-VISIT-F02-US03
BA-PROP
BA-PROP-F01
BA-PROP-F01-US01
BA-PROP-F01-US02
BA-PROP-F01-US03
BA-PROP-F02
BA-PROP-F02-US01
BA-PROP-F02-US02
BA-PROP-F03
BA-PROP-F03-US01
BA-PROP-F03-US02
BA-PROP-F03-US03
BA-CRM
BA-CRM-F01
BA-CRM-F01-US01
BA-CRM-F01-US02
BA-CRM-F01-US03
BA-CRM-F03
BA-CRM-F03-US01
BA-CRM-F03-US02
BA-CRM-F02
BA-CRM-F02-US01
BA-CRM-F02-US02
BA-FCST
BA-FCST-F01
BA-FCST-F01-US01
BA-FCST-F01-US02
BA-FCST-F02
BA-FCST-F02-US01
BA-FCST-F02-US02
BA-FCST-F02-US03
Fictional program for a fictional brokerage. Generated from tools/backlog_document/acme_realty_backlog.json by build.py; do not edit the HTML by hand. Part of the Backlog Writing System.