Feature breakdown · built with CraftHQ
Customer onboarding
Whole-team time at this build's pace
2 people incl. the product owner, requirements to merge
Estimate at this build's pace, not a measurement of this feature
Every piece of work starts from a clean customer record with the right owner and reviewer attached.
How long a feature this size usually takes
Whole-team time — this build vs a typical team
~31 FP · FP × 6.8 to 9.4 h (ISBSG 2023)
Estimate at this build's pace, not a measurement of this feature
Both figures are whole-team time over the whole lifecycle, so they compare like for like. Ours is this build's pace — about 0.8 hours per function point across the whole build (two people, including the product owner, with requirements and review time). The industry range is an ISBSG project-level figure applied to one feature, so it is indicative.
Workflow
How it moved through the workflow
Select a stage. The build shipped, so every stage is complete; a person approved the merge.
Request
Work needs to start from a clean customer record with the right owner and reviewer, and creating one should not mean re-keying the basics by hand.
Questions
Two decisions went to the business before building: whether to pre-fill a new record from an uploaded document, and who may change the owner and reviewer.
Approved
The product owner signs off the breakdown by moving the story into the approved state, and the build runs against that reference.
Definition of ready
Building
CraftHQ's build agents write the code and the tests together, run as a loop; a failing check halts the work until it passes.
Checks
Three checks run on every pull request: one on the product owner's machine as CraftHQ builds, one on the engineer's machine before review, and a code-quality scan in CI. Merging is gated by the CI check passing and a person's approval, enforced by branch protection.
Review
An engineer reviews the pull request and merges it.
Merged
The pull request is merged to main after a person approves it. Nothing merges without that approval.
Definition of done
Breakdown
The feature breakdown
Business first, then the engineering view. Tab through it.
Overview
The gap it closes
Work cannot start until there is a clean customer record with the right people attached, and re-keying the basics by hand is slow and error-prone.
Who uses it
Admins create customers and set the owner and reviewer. Staff work against the customers they own.
User story
As an admin, I want to create a customer and assign an owner and a reviewer so that the team can start work against the right owner.
Examples
Example 1
An admin opens the create form, enters the customer's details, picks an owner and a reviewer, and the record is ready for work.
Example 2
An admin uploads a document to start a record. The form is pre-filled from it, the admin corrects a field that was read wrong, and then saves.
Dependencies & risks
Depends on
The staff list for the owner and reviewer choices, and a document reader for the optional pre-fill.
Risk & mitigation
A pre-fill could read a field wrong. Reduced by showing every pre-filled value for the admin to check and correct before saving.
How it works
Simplified diagrams of the parts involved, the steps of one request, and where it runs.
Architecture
- 1enter details
- 2optional pre-fill
- 3save the record
- 4list and search
- 5record an export
- 6admit the upload
- 7admitted file read in-house
Sequence
- 1upload a document to pre-fill
- 2the form pre-filled for review
- 3save with owner and reviewer
- 4store the customer record
- 5the record is ready for work
Infrastructure
- 1create and search
- 2read and write customer records
- 3read an uploaded document
Acceptance criteria
Each scenario is written as a Gherkin spec. The Engineering tab shows the test that covers each one, or notes where it was verified by review.
@customers @onboardingFeature: Customer onboardingAs an adminI want to create a customer and assign an owner and a reviewerSo that the team can start work against the right ownerEvery piece of work starts from a clean customer record with the right people attached.Background:Given an admin is signed inAnd the list of active staff members is available for assignmentRule: A customer record starts with a distinct owner and reviewerScenario: Create a customer and assign an owner and a reviewerGiven an admin opens the create-customer formWhen they enter the customer details and choose an owner and a reviewerThen the customer is created with that owner and reviewerAnd the team can start work against the recordScenario Outline: An invalid assignment is refused on the serverGiven an admin is creating or editing a customerWhen the assignment has "<fault>"Then the server refuses the change with the real reasonExamples:| fault || the same person as owner and reviewer || an owner who is inactive || a name that duplicates an existing customer |Rule: A new record can be pre-filled from an uploaded document that passes admissionScenario: Pre-fill from an uploaded documentGiven an admin uploads a document while creating a customerAnd the document has passed upload admission (type, size and content checks)When the in-house document reader reads itThen the form is pre-filled from itAnd the admin can correct any field before savingScenario: An unreadable document does not pre-fillGiven an admin uploads a document that is refused at admission or cannot be readWhen the create form loadsThen no pre-fill is applied and the admin is told to enter the details by handRule: Only an admin changes the owner or reviewerScenario: A non-admin cannot change the assignmentGiven a staff member who is not an admin opens a customer recordWhen they try to change the owner or reviewerThen the change is refused on the server, not only hidden in the screenRule: Staff see only the customers they ownScenario: A staff member cannot see another staff member's customersGiven a staff member who owns some customersWhen they open the registerThen they see only the customers they own, scoped by tenant and roleRule: The register is searchable and an export is scoped like the screenScenario: Search and filter the registerGiven many customers existWhen an admin searches and filters the registerThen only the matching customers are listedScenario: An export runs the same authorised query as the screenGiven a filter is applied to the registerWhen an admin exports the listThen the export runs the same authorised, tenant-scoped query as the screenAnd it contains the same records as the filtered viewRule: Two admins editing one record do not overwrite each otherScenario: A concurrent edit is detectedGiven two admins open the same customer recordWhen one saves and then the other saves over a stale copyThen the second save is refused and the admin is shown the newer version
Questions
Questions raised in planning, each with the decision taken.
Should a new record be pre-filled from an uploaded document?
Pre-filling saves re-keying, but a reader can misread a field, so the admin must be able to correct it.
Who may change the owner and reviewer on a customer?
The assignment decides who may act on a record, so it needs a single, clear owner of the decision.
How we sized it
A function point measures what the software does — its inputs, outputs, lookups and the data it stores — regardless of language or how many lines it took. Each counted item is weighted by complexity: a user input counts 3–6 points, an output or report 4–7, a lookup 3–6, data the feature owns 7–10, and data read from elsewhere 5–7.
- The customer store this feature ownsData the feature owns10
- Create a customerUser input4
- Assign an owner and a reviewerUser input4
- Edit the customerUser input4
- Search and list customersLookup4
- Export the customer listOutput or report5
- Total31
Components touched
Customer record
Stores the customer details, the owner and the reviewer.
Create form with pre-fill
Reads an uploaded document in-house to pre-fill the form, after the file passes upload admission (type, size and content checks) (see File upload). Every value is shown for the admin to confirm.
Searchable register
A list with a server-side search and filters.
Export
Takes the list out as a file, matching the filter applied on screen.
Concurrency guard
Detects a concurrent edit of the same record and refuses a save over a stale copy.
Data touched
Customer recordwrite
Created and edited here, with its owner and reviewer.
Staff listread
Read to offer the owner and reviewer choices.
Audit logappend
Records sensitive actions such as an export.
Security decisions
- Only an admin changes the owner or reviewer.
- The pre-fill never saves on its own; the admin checks and confirms every value.
- The export runs the same authorised, tenant-scoped query as the screen; filter parity keeps the file equal to what is shown, but it is authorisation, not the filter, that limits what a user can take out.
- An uploaded pre-fill document passes upload admission and the upload checks (see File upload) before the in-house reader reads it.
- A staff member sees only the customers they own; the register and its export are scoped by tenant and role.
Subtasks
- The customer record with owner and reviewer.
- The create form with the optional document pre-fill.
- The searchable, filterable register.
- The export with filter parity.
How each scenario is verified
- Create and assignment are admin-onlyA customer-record integration test confirms a non-admin may read but not create, edit or map, a failed create rolls back with no partial state, and name uniqueness is case-insensitive per tenant and concurrency-safe.
- A staff member sees only their own customersThe same integration test confirms a mapped staff member sees only the customers mapped to them.
- An export matches the on-screen filter and is admin-onlyA filter-parity integration test confirms the export equals the filtered list; the register export is restricted to administrators.
- A concurrent edit over a stale copy is refusedThe customer-record test confirms a concurrent edit is detected and the stale save is refused.
- A non-admin cannot change the assignmentCovered through the customer-record authorization tests rather than a dedicated assignment test.
Risk tier
Logic A person approves every merge. This is a Logic-tier change; it carries automated tests for its rules.
Start here
Want this on your backlog?
Get a free baseline report on one repository, or scope a 3-month pilot measured against what your team’s work costs today.