How I run a project: Agile, Kanban and sprints in Jira and Confluence

In short

A governance programme is a set of projects, and projects need a rhythm that business people can follow. I use the same simple frame everywhere: one Jira project and one Confluence space per mission, short two-week sprints for the projects, a board that shows the flow for the requests that never stop, and a monthly decision point with the project review board (PRB). This page shows that frame on a demonstration project, with the screens and the material to reuse it.

One place for the work

Every deliverable is a ticket in Jira; every document lives in Confluence, linked to its ticket.

Short cycles

Two-week sprints with a goal, a review and a retrospective: progress is visible every fortnight.

Flow for the run

Requests, data quality incidents and access requests go through a Kanban board with limited work in progress.

Decisions on a calendar

The PRB meets monthly, sees one page of progress, KPIs and risks, and decides.

Reusable by the client

The structure is generic: the client team can run it alone after the mission.

Scrum, Kanban or both

I choose the method from the nature of the work, not from a belief. In a data governance programme both are useful, often side by side.

	Scrum (sprints)	Kanban (flow)
Best for	Projects with a goal and deliverables: a catalogue, a quality rule library, a policy, a roadmap.	Work that arrives all the time: data requests, quality incidents, access requests, small changes.
Rhythm	Two-week sprints, a fixed scope per sprint.	Continuous flow, work pulled when there is capacity.
Control	Sprint goal and review of what was delivered.	Limit on work in progress and time spent in each column.
What is reported	Goal, delivered, blocked, next (one page per sprint).	Throughput, waiting time, blocked items.
In my missions	Phase 4: the use cases are delivered in sprints.	After the handover: the client team runs the requests on a board.

The demonstration project

To show how this works, I keep a complete demonstration project in Jira and Confluence. It is a template: it is never executed, it has no dates, and it is duplicated and adapted for each mission. It follows my four-phase approach.

6epics: 4 phases and 2 streams

51stories: activities and deliverables

15sub-tasks: questions and checks

4sprints, one per phase

16Confluence pages

How the work is broken down

Epic = a phase or a stream→Story = an activity of the RACI or a deliverable→Sub-task = an interview question, a dimension, a check

How the sprints follow the phases

Sprint 1 · Get to know→Sprint 2 · Gaps and roadmap→Sprint 3 · Programme set-up→Sprint 4 · Delivery

Each sprint has the goal of its phase and holds the stories of its epic. The two streams, training and coaching and governance documents, stay in the backlog: they run along the whole mission and feed every sprint. In a real mission the sprint length and dates are set with the client; a phase may take several two-week sprints.

About the screens. The Jira project and the Confluence space are private: the pictures below are screenshots of the demonstration project. The same structure is yours to download further down this page.

Jira: backlog, epics and sprints

The backlog shows the plan at a glance: each sprint carries its goal and its stories, each story belongs to an epic (the purple tag), and each story can be broken into sub-tasks, for example one per interview theme in sprint 1.

Jira backlog of the demonstration project: Sprint 1 Get to know with its goal, its stories and the sub-tasks of the interview story — **Sprint 1, Get to know.** The sprint goal comes from the phase. Stories are the activities of the RACI and the deliverables D1.1 to D1.4; the interview story is split into six sub-tasks, one per theme.

Jira backlog of the demonstration project: Sprint 2 Gaps and roadmap with the assessment stories and deliverables D2.1 to D2.5 — **Sprint 2, Gaps and roadmap.** Four assessment stories carry the eight dimensions as sub-tasks, then the use cases, the roadmap and its approval, and the deliverables D2.1 to D2.5.

Workflow

To Do→In Progress→In Review→Blocked→Done

The same five statuses serve the Scrum board and the Kanban board. Blocked is a status of its own so that it shows on the board and in the sprint report; a story is Done only when its deliverable is reviewed and published in Confluence.

Confluence: the memory of the project

The Confluence space is the written side of the project: what was agreed, what was decided, and the documents that the client keeps. The programme page is the entry point, with the mission charter, the phases, the roles and the first ten days. The space is connected to the Jira project, so the pages can be opened from the Docs tab of the board.

Structure of the space

Data Governance Programme: mission charter, phases, roles, first 10 days.
One page per phase (1 to 4): goal, participants, key questions as tasks to tick, deliverables, RACI, exit criterion.
Two stream pages: training and coaching; governance documents.
Reference document checklist: the 23 documents checked in phase 1.
Decision log: every PRB decision, with date and owner.
Templates: use case card, sprint report, PRB minutes, documentation inventory, gap and risk register, lessons learned.

How Jira and Confluence work together

A story in Jira points to its page in Confluence; the page lists the questions and the deliverables.
The sprint report is a Confluence page written from the sprint: goal, delivered, blocked, next.
The monthly PRB report summarises the sprint reports and asks for decisions, which go to the decision log.
The client keeps both tools: nothing depends on me or on a tool of mine.

Confluence space of the demonstration project: the programme page with the mission charter and the page tree on the left — **The programme page.** The page tree on the left is the structure above; the mission charter has placeholders to fill in for each client.

Confluence page of phase 1 with the goal, the participants and the key questions as checkboxes — **A phase page.** Goal, participants and the key questions as tasks to tick during the interviews.

Ceremonies and reporting

Ceremony	When	Output
Sprint planning	Start of sprint, 1–2 h	Sprint goal and scope
Daily stand-up	15 min (Scrum) or board review (Kanban)	Blockers
Sprint review	End of sprint, 1 h	Demo and acceptance
Retrospective	End of sprint, 45 min	Improvement actions
PRB	Monthly, 1 h	Progress, KPIs, decisions

Reporting stays light: one page at the start and at the end of each sprint (goal, delivered, blocked, next) and one page per month for the PRB (progress, KPIs, risks, decisions needed). Change requests are handled with the PRB, which re-prioritises the backlog.

Download the project kit

The kit contains what you see above: the Jira import file (6 epics, 51 stories, 15 sub-tasks), the 16 Confluence pages as ready-to-publish files, a small script that creates the pages in your Confluence space, and a README with the steps.

Create the Jira project (Scrum or Kanban, company-managed) and import jira-import-data-governance.csv. The README gives the column mapping that keeps the hierarchy.
Create the Confluence pages with create_confluence_pages.py (Python 3, no dependency), or paste the page files by hand.
Plan the sprints and adapt names, dates and scope to your context.

Download the project kit (ZIP, 25 KB) Download the guide (PDF) Contact me

Licence: CC BY-NC 4.0. Free to use, share and adapt for non-commercial purposes, with attribution to Olivier Bouchez. For commercial use, please get in touch.

Let’s talk about your context

Every organisation has its own rhythm. I adapt the frame to the size of the team, the tools already in place and the level of agile practice, and I leave you with a way of working that you can run on your own.

Contact me My four-phase approach