Feature breakdown · built with CraftHQ
Dashboards by role
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
Each role lands on a dashboard built for its own work, rather than one shared home for everyone.
How long a feature this size usually takes
Whole-team time — this build vs a typical team
~11 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.
The pull request time covers one change to this feature; the estimate covers building the whole feature.
Workflow
How it moved through the workflow
Select a stage. The build shipped, so every stage is complete; a person approved the merge.
Request
Give each role a dashboard built for its own work, rather than one shared home, and show the customer their open items first.
Questions
One decision went to the business before building: one shared dashboard for everyone, or one dashboard per role.
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
One shared home serves no one well: each role has different work, and a single landing page buries what matters to each of them.
Who uses it
Every user, with each role seeing its own dashboard; customers see a dashboard that shows their open items first.
User story
As a user, I want a dashboard tailored to my role so that I see my own work and status first.
Examples
Example 1
An administrator and a reviewer sign in and each land on a different home, built for the work their role does.
Example 2
A customer has several open items. Their dashboard shows their open items, rather than a flat list.
Dependencies & risks
Depends on
A set of per-role dashboard views, and an aggregate read that computes the figures in one transaction with a short cache.
Risk & mitigation
Several role variants could drift or load slowly. Reduced by computing each dashboard from one read with aggregate queries and a short cache.
How it works
Simplified diagrams of the parts involved, the steps of one request, and where it runs.
Architecture
- 1lands on their role's home
- 2requests the summary
- 3aggregate queries in one read
Sequence
- 1open the dashboard
- 2check the cached summary
- 3one read with aggregate queries (on a cache miss)
- 4the role's figures
- 5the dashboard, their open items
Infrastructure
- 1dashboard request
- 2read or refresh the cache
- 3aggregate read
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.
@platform @uiFeature: Dashboards by roleAs a userI want a dashboard tailored to my roleSo that I see my own work and status firstEach role lands on a dashboard built for its own work, rather than one shared home for everyone.Background:Given a user has a roleRule: Each role lands on its own dashboardScenario: A role lands on its own dashboardGiven an administrator signs inWhen they reach their homeThen they see the administrator dashboard with the cards for that roleRule: The dashboard summary is served from a short-lived, per-tenant, per-user, per-role cacheScenario: The cache key keeps one tenant, user or role from reading another's figuresGiven a dashboard summary is cachedWhen another tenant, user or role requests a dashboardThen they are never served that cached summary, because the key includes the tenant, the user, the role and the scopeRule: The aggregate read runs under the authorised, tenant-scoped queryScenario: A dashboard cannot aggregate another tenant's dataGiven an administrator of another tenant opens a dashboardWhen the summary is aggregatedThen it aggregates zero, because the read runs under row-level security and the authorised scope@edge-casesScenario Outline: Each role sees a home for its own workGiven a user with the "<role>" role signs inWhen they land on their dashboardThen they see "<home>"Examples:| role | home || administrator | an administrator home for their work || staff | a staff home for their work || reviewer | a review home for their work || customer | a home for their work |
Questions
Questions raised in planning, each with the decision taken.
Should there be one dashboard for everyone, or one per role?
One shared dashboard is simpler to build but buries each role's work. One per role puts each person's work first.
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 firm-wide aggregate dashboard: derived counts across the whole book with a combined-status summaryOutput or report7
- The signed-in customer's own dashboard, their own records onlyLookup4
- Total11
Not counted here
- The per-role layouts are one presentation of the same read, counted once (the same query under a role filter is one function)
- The short-lived performance cache and the aggregate-query pass: plumbing, not a user function
Components touched
Per-role dashboard views
A different home per role, each built for the work that role does.
Aggregate read
The figures come from one read transaction with aggregate queries and a short-lived cache (30 seconds) keyed by the tenant, the user, the role and the scope, rather than many separate calls.
Data touched
Records summaryread
Aggregate figures read in one transaction, scoped to the current organisation and role.
Short cachewrite
A short-lived (30-second) cache of the computed summary, keyed by the tenant, the user, the role, the scope selection and the year, so one tenant, user or role never reads another's cached figures.
Security decisions
- Each dashboard reads only the current tenant's data, narrowed by role; the tenant boundary is enforced in the database (row-level security on every table, pinned per transaction) — see Multi-tenant data isolation.
- A short-lived cache (30 seconds) keyed by the tenant, the user, the role and the scope, so a cached result cannot be served across tenants, users or roles.
- The aggregate read runs on the server under the authorised, tenant-scoped query, so the client cannot widen what it sees; a cross-tenant test confirms an administrator of another tenant aggregates zero.
Subtasks
- Per-role dashboard views.
- A customer hero that shows their open items.
- An aggregate read in one transaction with a short cache.
How each scenario is verified
- The cache holds for its window and evicts at capacityA cache unit test checks a value is served within the 30-second window and dropped after, that re-setting refreshes the window, and that the oldest entry is evicted at capacity.
- The same aggregate is served from cache, keyed per userAn equivalence test confirms a second read within the window is served from cache and that a different user, scope or year is its own entry.
- A role lands on its own dashboardVerified by review of the per-role dashboard screens.
- A cross-tenant aggregate returns nothingA cross-tenant test confirms an administrator of another tenant aggregates zero and a mapped staff member aggregates only their own customers.
Risk tier
Logic A person approves every merge. This is a Logic-tier change; it carries automated tests for its rules.
Activity
Pull-request window for the per-role reshape.
- Pull request opened: a dashboard for each role
- Merged to main after a person approved
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.