All features

Feature breakdown · built with CraftHQ

CustomersData entry

Customer onboarding

Whole-team time at this build's pace

Estimated ~25 h

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.

Size: ~31 FP · Proxy estimate; an in-house count, not independently checked. Parts 10+4+4+4+4+5 = 31; the shared customer store is counted here, not in Organisation profile. Range 20 to 35. · How we counted 31 FP

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)

Whole-team time at this build's pace2 people incl. the product owner, requirements to merge
~25 h16 to 28 h

Estimate at this build's pace, not a measurement of this feature

A typical team, whole lifecycleRequirements to release · middle half of 512 comparable projects (Java, Agile), ISBSG 2023
~211 to 291 habout 5.5–7.5 person-weeksmedian ~245 h
grey band = a typical team, middle halfhatched = our whole-team estimate

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

The questions are answered.
The acceptance criteria are testable.
The size is estimated.
The scope is checked for splitting.
The product owner has signed off.

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

Every acceptance criterion is checked; where a scenario has a dedicated test it is cited, and where it was verified by review that is stated.
The three checks are green.
A person approved the merge.

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

People
Admincreates the customer
Your app
Create formwith optional pre-fill
Document readerpre-fills the form
Customer recorddetails, owner, reviewer
Registersearch, filter, export
Audit logrecords an export
Upload admission and scan gateadmits an upload (type, size, content) before the in-house reader
  • 1enter details
  • 2optional pre-fill
  • 3save the record
  • 4list and search
  • 5record an export
  • 6admit the upload
  • 7admitted file read in-house
Simplified.

Sequence

Browserthe admin
App servercreate and register
Databasecustomer records
  • 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
Simplified.

Infrastructure

Client (untrusted)
Web appthe create form and register
Your app
App servercreate, search, export; authenticates, pins the tenant
Databaseper-tenant isolation
File storageuploaded documents for pre-fill
  • 1create and search
  • 2read and write customer records
  • 3read an uploaded document
Simplified.

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 @onboarding
Feature: Customer onboarding
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
Every piece of work starts from a clean customer record with the right people attached.
Background:
Given an admin is signed in
And the list of active staff members is available for assignment
Rule: A customer record starts with a distinct owner and reviewer
Scenario: Create a customer and assign an owner and a reviewer
Given an admin opens the create-customer form
When they enter the customer details and choose an owner and a reviewer
Then the customer is created with that owner and reviewer
And the team can start work against the record
Scenario Outline: An invalid assignment is refused on the server
Given an admin is creating or editing a customer
When the assignment has "<fault>"
Then the server refuses the change with the real reason
Examples:
| 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 admission
Scenario: Pre-fill from an uploaded document
Given an admin uploads a document while creating a customer
And the document has passed upload admission (type, size and content checks)
When the in-house document reader reads it
Then the form is pre-filled from it
And the admin can correct any field before saving
Scenario: An unreadable document does not pre-fill
Given an admin uploads a document that is refused at admission or cannot be read
When the create form loads
Then no pre-fill is applied and the admin is told to enter the details by hand
Rule: Only an admin changes the owner or reviewer
Scenario: A non-admin cannot change the assignment
Given a staff member who is not an admin opens a customer record
When they try to change the owner or reviewer
Then the change is refused on the server, not only hidden in the screen
Rule: Staff see only the customers they own
Scenario: A staff member cannot see another staff member's customers
Given a staff member who owns some customers
When they open the register
Then they see only the customers they own, scoped by tenant and role
Rule: The register is searchable and an export is scoped like the screen
Scenario: Search and filter the register
Given many customers exist
When an admin searches and filters the register
Then only the matching customers are listed
Scenario: An export runs the same authorised query as the screen
Given a filter is applied to the register
When an admin exports the list
Then the export runs the same authorised, tenant-scoped query as the screen
And it contains the same records as the filtered view
Rule: Two admins editing one record do not overwrite each other
Scenario: A concurrent edit is detected
Given two admins open the same customer record
When one saves and then the other saves over a stale copy
Then 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.

AYes. Read an uploaded document to pre-fill the form, with every value shown for the admin to check and correct. · recommended
BNo. Enter every field by hand.
Decided: Pre-fill from an uploaded document, admin corrects before saving (option A).

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.

AAdmin only. Staff work against their records but do not reassign. · recommended
BAny staff member can reassign a customer.
Decided: Admin only (option A).

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 owns
    Data the feature owns
    10
  • Create a customer
    User input
    4
  • Assign an owner and a reviewer
    User input
    4
  • Edit the customer
    User input
    4
  • Search and list customers
    Lookup
    4
  • Export the customer list
    Output or report
    5
  • Total
    31
31 function points (range 20–35). IFPUG-style count: each user action, lookup, output and stored data set, weighted by complexity. Technical plumbing is excluded, and a data store is counted once in the feature that owns it.

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-only
    A 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 customers
    The 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-only
    A 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 refused
    The customer-record test confirms a concurrent edit is detected and the stale save is refused.
  • A non-admin cannot change the assignment
    Covered 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.

Measured from your own git history
Every pull request tested before review
A person approves every merge