Feature breakdown · built with CraftHQ

Review & recordsFiles

Export package & index

Whole-team time at this build's pace

Estimated ~20 h

2 people incl. the product owner, requirements to merge

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

One encrypted package of the approved work, downloaded only through the authenticated portal and scoped to the owning organisation.

Size: ~25 FP · Proxy estimate; an in-house count, not independently checked. Parts 10+6+5+4 = 25. Range 16 to 28. · How we counted 25 FP

How long a feature this size usually takes

Whole-team time — this build vs a typical team

~25 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

~20 h13 to 23 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

~170 to 235 habout 4.5–6 person-weeksmedian ~198 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

Once work is approved, its outputs should be assembled into one package that matches what was signed off, encrypted, and downloaded only through the authenticated portal.

Questions

One design decision was recorded before building.

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

A hand-over can drift from what was actually approved, or be opened by the wrong organisation. The package is built from the approved work and downloaded only from the authenticated portal, scoped to the owner.

Who uses it

Staff generate the package; customers download it from their own authenticated portal. A download is scoped to the customer's own organisation.

User story

As a staff member, I want the approved outputs assembled into one package so that I have exactly what I need to hand over.

Examples

Example 1

Work is approved. The outputs are assembled into one AES-256-encrypted package and an index is kept. The customer downloads it from their authenticated portal; the package password is shown to them for their own package, not emailed.

Example 2

An output changes after it was approved. The approval is voided and the item re-enters review (see Two-step review), so the hand-over cannot carry an edited-after-approval output.

Dependencies & risks

Depends on

The approved outputs, a package store, and the authenticated portal download.

Risk & mitigation

A package could be opened by the wrong organisation, or carry an output changed after approval. Reduced by scoping the download to the owning organisation (another organisation gets a not-found), by voiding an approval when an output changes so it must be re-approved before it can be packaged, and by encrypting the package, which is downloaded only through the authenticated portal.

How it works

Simplified diagrams of the parts involved, the steps of one request, and where it runs.

Architecture

People

Staff memberassembles the package

Customerdownloads the package

Your app

App serverruns assembly and serves downloads

Assembly stepbuilds the approved package

Retention storeencrypted, access-scoped

Audit loggeneration and download

1assemble
2build the approved package
3store and index
4request the download
5fetch after an access check
6record the outcome

Simplified.

Sequence

Staff membergenerates the package

Customerdownloads

App serveraccepts the request

Background workerassembles and archives

Package store + archivewrite and index

1generate the package
2hand off assembly
3assemble the approved outputs into the encrypted package
4store the encrypted package, snapshot and index
5request the download
6the package, after an access check (password shown in the portal)

Simplified.

Infrastructure

Client (untrusted)

Web appruns in the browser

Your app

App serverauthenticates, pins the tenant

Background workerpackaging and archiving

Databaseper-tenant isolation, archive index

File storageencrypted packages and snapshots

1generate or download (authenticate + tenant check)
2hand off assembly and archiving
3store the encrypted package and snapshot
4write the archive index and audit

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.

@review @records
Feature: Export package and index
  As a staff member
  I want the approved outputs assembled into one package
  So that I have exactly what I need to hand over

  The approved outputs are assembled into one encrypted package, downloaded only through the authenticated portal and scoped to the owning organisation. If an output changes after approval, the approval is voided and the item re-enters review before it can be packaged.

  Background:
    Given a set of outputs has been approved

  Rule: The package is built from the approved revision

    Scenario: The package is assembled from the approved outputs
      Given the approved outputs are unchanged
      When the package is assembled
      Then it is built from the approved revision

    Scenario: A change after approval cannot be packaged
      Given an output is changed after it was approved
      When a package is requested
      Then the item is not packaged; the approval is voided and it re-enters review

  Rule: The package is encrypted and the download is scoped

    Scenario: The package is an encrypted archive
      Given a package has been assembled
      When a wrong password is used, or the container is tampered with
      Then the encrypted package cannot be read

    Scenario: The password is shown in the authenticated portal
      Given a customer opens their package in the authenticated portal
      When the portal shows the package
      Then the password is shown to them in the portal and revealed to authorised staff with an audit row, never emailed

    Scenario: A download by another organisation is refused
      Given a package belongs to one organisation
      When a user from another organisation requests it
      Then the request returns not-found, so the package's existence is not disclosed

  Rule: Identity inputs are snapshotted at generation

    Scenario: A snapshot and an index are kept
      Given a package has been assembled
      When it is stored
      Then the identity inputs are snapshotted at generation, so a later rename does not change the issued package
      And an index of the completed items is kept in the package

  @edge-cases
  Scenario Outline: What assembly does with the approved outputs
    Given the approved outputs are "<state>"
    When the package is assembled
    Then the result is "<result>"

    Examples:
      | state                    | result                                      |
      | unchanged since approval | assembled from the approved revision        |
      | changed after approval   | not packaged; the approval is voided, re-review |
      | not yet approved         | refused, nothing to assemble                |

Questions

Questions raised in planning, each with the decision taken.

Can the package carry an output that changed after it was approved?

If the package were built from the latest state, a hand-over could differ from what the customer actually approved.

ANo. An approval is pinned to the approved revision; a change after approval voids the approval, so the item must be re-approved before it can be packaged. · recommended

BRe-assemble from the latest state, which may differ from the approval.

Decided: No drift: a change after approval voids the approval and the item re-enters review before it can be packaged (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 package and archive store this feature owns
Data the feature owns
10
Assemble the approved outputs into one package
User input
6
Generate and download the password-protected package
Output or report
5
The archive index of completed items
Lookup
4
Total
25

25 function points (range 16–28). 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

Assembly step

Collects the approved outputs and builds the package.

Record snapshot

Snapshots the identity inputs when the package is generated, so a later rename or identifier edit does not change an already-issued package.

Package encryption

The package is an AES-256-encrypted archive; a wrong password cannot read it and a tampered container is refused. The password is shown through the authenticated portal to the signed-in customer and revealed to authorised staff with an audit row; it is not emailed.

Portal download and retention

Downloads are served from the authenticated portal, scoped to the owning organisation; another organisation's request returns not-found. The package is kept in encrypted object storage.

Data touched

Package storewrite

The assembled, encrypted package and its snapshot of the identity inputs at generation.

Archive indexwrite

An index of completed items and where each package is retained.

Audit logappend

Package generation, password reveals and download events.

Security decisions

An output changed after approval cannot be packaged: the approval is voided and the item re-enters review before it can be handed over.
The package is an AES-256-encrypted archive; a wrong password cannot read it and a tampered container is refused.
The download is scoped to the owning organisation; another organisation's request returns not-found, so a package's existence is not disclosed.
The package is downloaded from the authenticated portal; the password is shown in the portal and revealed to authorised staff with an audit row, never emailed.
Identity inputs are snapshotted at generation, so a later rename does not change an already-issued package.
Password reveals are recorded in the audit log (who, which package, never the value).

Subtasks

An assembly step with a determinism test pinning its output in CI.
A snapshot of the identity inputs at generation.
AES-256 package encryption with the password revealed through the authenticated portal.
An authenticated, organisation-scoped portal download; retention in encrypted storage.

How each scenario is verified

The encrypted package protects its contents
A cipher test confirms the plaintext is absent from the container, a wrong password cannot read it, and a tampered container is refused.
A package reveal is organisation-scoped
A test confirms a package reveal is shown only within the owning organisation, another organisation cannot reveal it (not-found), and a later rename does not change an already-issued package.
A download by another organisation is refused
The output-package integration test confirms a cross-organisation request returns not-found.
An output changed after approval cannot be packaged
Covered by the review feature's version-void tests: a change after approval voids the approval and re-enters review.

Risk tier

Core A person approves every merge. This is a Core-tier change, so it also carries the fullest set of automated tests; a regression here affects the whole product, not one page.

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

Get a baseline report Scope a 3-month pilot