Selected work · Case studyProduct delivery progress & traceability dashboard
Role
AI Business Analyst · BI solution designer
Context
Agentic AI platform team
Sector
Agentic AI assistant platform
Stage
Active management dashboard
~2 days
to the first usable reporting solution
Documented build time
3 systems
planning, analysis and delivery connected
Solution design
Daily
active operational use
Current usage
~1 month
live use and ongoing
Operational adoption
01 · Executive summary
Three systems, one traceable answer: what did we plan, analyse, ticket and complete?
Project leadership needed a clear, fact-based way to show delivery progress, but the information was split across three systems. A governed Google Sheets model held the longer-term product hierarchy and traceability fields, Confluence held near-term story analysis, and Jira held only work that had already entered delivery. Standard Jira reporting could not show the full planned scope or distinguish between planned, documented, ticketed and completed work.
I designed a master planning and traceability model in Google Sheets, automated Confluence and Jira extraction with Google Apps Script, retrieved the Jira issue-history dataset directly through the Jira API and built a two-page Data Studio — formerly Looker Studio dashboard. The solution linked planned stories to their Confluence pages and Jira tickets, showed how far planned release scope had progressed through analysis and delivery, enabled drill-down by function, and plotted historical created-versus-closed trends from Jira historical activity data.
The first usable solution was built in approximately two working days. It connected planning, analysis and delivery data in an automatically refreshed reporting model, and has been in active daily use for approximately one month by the Product Owner, Project Manager and management stakeholders.
02 · Business problem
Jira could only answer part of the question
The Product Owner and Project Manager lacked a deterministic view of progress. The management question was simple — what did we plan, how much has been analysed, how much has reached Jira, and how much is complete? — but no single system could answer it.
Split across three systems
The plan lived in Sheets, near-term analysis in Confluence, and delivery in Jira — with no place that joined them.
Jira shows only tickets
It could report work that already existed, but not planned work that had not yet been created as a ticket.
No scope distinction
Planned scope, analysed scope and delivery scope could not be told apart in standard reporting.
Confluence = next 1–2 sprints
Only stories planned for the immediate sprints were documented there; the rest was not yet analysed.
The full plan was unstructured
The complete future plan existed only in an informal way, invisible to any reporting tool.
A view, not ticket detail
Stakeholders needed a management-level lifecycle view rather than raw ticket-by-ticket detail.
03 · BPMN 2.0 · Business process
From a planned function to a stakeholder-ready progress view
A single pool with three lanes — the Product Owner / BA, the delivery team, and the reporting automation. A manual planning-and-delivery path turns functions into Confluence pages and Jira stories; a separate hourly timer drives extraction, calculated matching, human-validated linkage and a refreshed Data Studio view.
Swipe or scroll to explore the diagram →
04 · Solution architecture summary
A governed plan, automated refresh, human-validated links
The reporting stack pairs a manually governed planning model with automatically refreshed operational data. Google Apps Script pulls Jira and Confluence hourly; calculated columns propose likely matches; and every final linkage is validated by hand to avoid incorrect joins caused by naming differences. The dashboard is a reconciled reporting layer across authoritative source systems — Sheets, Confluence and Jira each remain the owner of their own data.
Consolidated tables provide a stable reporting model behind a two-page Data Studio dashboard — current scope and delivery on one page, historical created-versus-closed trends on the other (built on the Jira issue-history dataset retrieved through the Jira API), each filterable by release, component and function.
Reporting model
- 01
Plan sheet: Module → Function → Story hierarchy
- 02
Apps Script hourly Jira + Confluence extraction
- 03
Calculated match suggestions
- 04
BA-validated final linkage
- 05
Consolidated tables + Jira history dataset (API)
05 · Solution architecture
How the pieces fit together
Four stages — data sources, integration & modelling, analytics, and presentation — sitting on a governed operating model of hourly refresh, manual plan updates and BA-owned validation.
Swipe or scroll to explore the diagram →
06 · AI components
No runtime AI — deterministic by design
There is no runtime AI in this solution. AI coding assistance helped author the Google Apps Script and formulas at build time, but every dashboard calculation is deterministic, the planning model is maintained by human judgement, and calculated match suggestions are validated by hand.
Swipe or scroll to explore the diagram →
07 · Technology and implementation stack
The build
Source systems
Google Sheets
planned product hierarchy and traceability fields
Confluence
analysed user-story documentation
Jira
delivery stories, subtasks, status and historical activity
Integration and automation
Google Apps Script
Jira and Confluence API extraction
Scheduled trigger
hourly automated refresh
Calculated matching
proposed cross-system links
Human validation
final linkages confirmed by the BA
BI and data modelling
Data Studio
reporting data model and calculated fields
KPI logic
planned, analysed, ticketed and completed states
Interactive filters
release, component and function
Trend analysis
Jira historical activity and created-versus-closed data
Operating model
BA-owned planning model
maintained alongside delivery
Existing operational data
no duplication of source-of-truth data
No separate reporting data-entry process
aggregates what teams already maintain
PO and PM stakeholder reporting
primary consumers of the view
08 · Results
From fragmented delivery data to a stakeholder-ready view
In approximately two working days, the first usable solution connected planned product scope, Confluence analysis and Jira delivery into one traceable progress view.
The dashboard has now been used daily for approximately one month by the Product Owner, Project Manager and management stakeholders. It gives them a clear view of how far the project has progressed, which work has reached each delivery stage and how much remains.
Because it aggregates information already maintained in the existing source systems, it introduced no separate reporting-data entry process or additional ongoing maintenance workflow. Its immediate organisational value was clearer progress communication, increased stakeholder confidence and stronger support for sponsorship conversations.
Daily operational use
Used daily for approximately one month and still active in the project's management workflow.
Evidence · Operational adoptionProgress and remaining-work visibility
Leadership can see what has been planned, analysed, ticketed and completed — and how much work remains.
Evidence · Implemented capabilityStakeholder-ready communication
The Product Owner and Project Manager use the view to explain project status to management and stakeholders.
Evidence · Stakeholder useConfidence and sponsorship support
The shared view increased confidence in the project and supported conversations about continued sponsorship.
Evidence · Stakeholder-reported outcomeLightweight implementation
A useful cross-system reporting solution was created without a large BI platform project or a separate data-maintenance process.
Evidence · Documented implementation effortBuilt into existing work
The dashboard aggregates information already maintained in Google Sheets, Confluence and Jira. The team does not need to update another reporting system solely to keep the view current.
Evidence · Operating-model designCurrent evidence
Success is currently evidenced through active daily use, stakeholder adoption, clearer progress communication and the absence of a separate reporting-maintenance process. The solution has been used for approximately one month and remains active.
Ongoing measurement
Future evaluation will track reporting-preparation effort, traceability coverage, stakeholder-use frequency and the time required to answer management questions about progress and remaining work.
Implementation dependency
Accuracy depends on consistent identifiers and timely updates in the source systems.
09 · Lessons learned
What I would carry into the next build
KPI selection is harder than dashboard construction
The technical build was straightforward; the real work was deciding which signals actually answered the management question.
Small solutions can have high leverage
A structured sheet and a simple dashboard solved a real visibility problem without a large platform investment.
Planned work must exist outside Jira
Jira cannot report work that has not yet been created as a ticket — true progress needs the plan to live somewhere structured.
Human-validated linking beats fully automatic matching
Calculated suggestions reduced effort, while manual confirmation prevented incorrect joins caused by naming differences.
Visual clarity can replace long status explanations
Management needed a simple lifecycle view far more than additional ticket detail.
A reporting model needs an owner
BA-owned maintenance and data validation keep the model trustworthy as the plan and delivery keep moving.
The Neurocroft method
The same six moves we apply to any organisational friction
Notice
Leadership could feel delivery progress but couldn't show it with confidence.
Understand
Mapped how plan, analysis and delivery lived in Sheets, Confluence and Jira.
Simplify
Reduced the question to four states — planned, analysed, ticketed, complete.
Connect
Linked plan → Confluence → Jira into one traceability model.
Amplify
Automated hourly extraction from Jira and Confluence, with the Jira issue-history dataset retrieved through the Jira API — no manual pull.
Evolve
In active daily use by the Product Owner, Project Manager and management stakeholders.
Related services
Where this pattern fits in how we help
Primary service
Data & Decision Intelligence
Connecting fragmented information sources so leadership can see scope, progress and traceability across the systems the work actually lives in.
Read the serviceTalk it throughDelivery progress you can feel but can't show?
Start with a short fit call. 20–30 minutes. You describe the reporting gap; we tell you honestly what a deterministic view would take to build.
Get in touch