{"id":24341,"date":"2026-10-06T14:05:28","date_gmt":"2026-10-06T08:35:28","guid":{"rendered":"https:\/\/www.nimblework.com\/knowledge-base\/nimble\/?post_type=article&p=24341"},"modified":"2026-10-07T10:59:02","modified_gmt":"2026-10-07T05:29:02","slug":"pi-planning-example-member-health-platform","status":"publish","type":"article","link":"https:\/\/www.nimblework.com\/knowledge-base\/nimble\/article\/pi-planning-example-member-health-platform\/","title":{"rendered":"PI Planning Example: Member Health Platform"},"content":{"rendered":"
\n

Skip Ahead to:<\/p>\n

<\/div>\n\n\n\n\n\n\n\n
1<\/span>Overview<\/a><\/td>\n<\/tr>\n
2<\/span>Splitting the Program into Child Projects<\/a><\/td>\n<\/tr>\n
3<\/span>Dividing the Increment into Releases<\/a><\/td>\n<\/tr>\n
4<\/span>Tracing One Epic Across Teams<\/a><\/td>\n<\/tr>\n
5<\/span>What to Check Before You Commit<\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Overview<\/h2>\n

This article walks through one program end to end, so the ideas in How to Run PI Planning in NimbleWork<\/a> have something concrete behind them.<\/p>\n

Member Health Platform 2.0<\/strong> is a health plan\u2019s member-facing platform being rebuilt over one increment: claims, benefits and coverage, and the guidance members get along the way. Its shape:<\/p>\n

\n\n\n\n\n\n\n\n\n\n
<\/th>\nIn This Program<\/th>\n<\/tr>\n<\/thead>\n
Program project<\/td>\nMember Health Platform 2.0<\/td>\n<\/tr>\n
Child projects<\/td>\nSix, split by capability<\/td>\n<\/tr>\n
Releases<\/td>\nFour, running October to February<\/td>\n<\/tr>\n
Epics<\/td>\nSix, each spanning more than one project<\/td>\n<\/tr>\n
Planned cards<\/td>\n71 across the four releases<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
\n

i<\/span>About This Example<\/p>\n

\n

The program below is an illustrative scenario, not a live system. The shape it describes \u2014 a capability split, a front-loaded increment, epics that cross team boundaries \u2014 is what matters, and it transfers to any program of a similar size.<\/p>\n<\/div>\n<\/div>\n

Splitting the Program into Child Projects<\/h2>\n

The six child projects are split by capability<\/strong>, not by feature.<\/p>\n

\"Member<\/a><\/div>\n

That choice has a direct consequence. Something a member would name \u2014 checking what a claim cost them, say \u2014 is never owned by one project. It needs the mobile client, the web portal, the claims service and the benefits platform, so it lands as work in four places at once.<\/p>\n

\n

i<\/span>Why This Shape Needs Program-Level Planning<\/p>\n

\n

Splitting by capability keeps each team\u2019s code and ownership clean, but it guarantees that every member-facing outcome crosses team boundaries. That is precisely the problem the program-level boards exist to solve.<\/p>\n

Had the split been by feature instead, each team would own an outcome end to end and need far less coordination \u2014 but teams would overlap in the same code.<\/p>\n<\/div>\n<\/div>\n

In regulated work the cost of missing a dependency is higher than a slipped date. A change to how a claim is calculated has to reach the mobile client, the web portal and the member notification together, or members see different numbers in different places. Planning across the program is what makes that visible before the work starts.<\/p>\n

The program itself is also a planning row, and it carries work that belongs to no single team \u2014 shared concerns such as the member search index and the eligibility rules engine. See How to Set Up a Program Project<\/a> for how the hierarchy is created.<\/p>\n

Dividing the Increment into Releases<\/h2>\n

The increment is divided into four releases. Read the names in order and the shape of the plan is visible: foundations first, refinement last.<\/p>\n

\"Four<\/a><\/div>\n
\n\n\n\n\n\n\n\n\n
Release<\/th>\nDates<\/th>\nPlanned<\/th>\n<\/tr>\n<\/thead>\n
Release 2.0 \u2014 Core Member Access & Claims<\/td>\nOctober to late November<\/td>\n27 cards<\/td>\n<\/tr>\n
Release 2.1 \u2014 Benefits & Coverage Experience<\/td>\nLate November to mid January<\/td>\n25 cards<\/td>\n<\/tr>\n
Release 2.2 \u2014 Personalised Care Guidance<\/td>\nMid January to mid February<\/td>\n12 cards<\/td>\n<\/tr>\n
Release 2.3 \u2014 Performance & Launch Readiness<\/td>\nMid to late February<\/td>\n7 cards<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Two things stand out in those numbers.<\/p>\n

The Work Is Front-Loaded<\/p>\n

Release 2.0 and 2.1 carry 52 of the 71 cards between them \u2014 roughly three quarters of the increment. That is deliberate in a plan like this: the early releases build what the later ones depend on. You cannot guide a member through coverage that has not been built yet.<\/p>\n

The Releases Get Shorter<\/p>\n

The first release runs eight weeks, the last runs under two. Later releases are smaller and tighter because they refine rather than build, and because a shorter final window leaves room to absorb slippage from earlier ones.<\/p>\n

Each release is created on the program and then shared with the teams that will build against it. See Release Planning at the Program Level<\/a>.<\/p>\n

Tracing One Epic Across Teams<\/h2>\n

Six epics carry the increment. EP-01 Member Claims Experience<\/strong> shows what the capability split does to a single goal.<\/p>\n

\"EP-01<\/a><\/div>\n

One epic, and its work sits in three different projects: a claim status notification service in Care Notifications<\/strong>, a cost share defect in Member Mobile App<\/strong>, and a submission flow story in Claims Services and APIs<\/strong>.<\/p>\n

No single team can report on this epic. Ask any one of them and you get a third of the answer. That is why the status screen groups by parent card as well as by release \u2014 see How to Monitor Program Progress<\/a>.<\/p>\n

The other five epics are the same story: EP-02 Benefits Discovery, EP-03 Coverage and Care Journey, EP-04 Payments and Reimbursements, EP-05 Personalised Care Guidance and EP-06 Platform Performance each span several of the six projects.<\/p>\n

What to Check Before You Commit<\/h2>\n

Before a program like this leaves the planning event, it is worth running the same few checks. Each one takes a minute on the screens you already have open.<\/p>\n

\n

1<\/span>Is any release carrying more than the teams can deliver?<\/strong> Compare Planned against Capacity on each release header. If capacity still reads zero, it has not been entered \u2014 worth fixing before anyone treats the plan as agreed.<\/p>\n<\/div>\n

\n

2<\/span>Is work sitting in a release but not in a sprint?<\/strong> On the Releases & Sprints tab those cards collect under a group named –None–<\/strong>. They are committed to a date but not scheduled to anyone\u2019s iteration.<\/p>\n<\/div>\n

\n

3<\/span>Is an epic spread so thin that nobody owns it?<\/strong> Expand each epic on the Parent-Child tab. If its children sit in four projects and no one row carries the majority, decide who is accountable for the outcome before the increment starts.<\/p>\n<\/div>\n

\n

4<\/span>Does every contributing project actually have the release?<\/strong> A project that was never shared a release shows Add release to this project<\/strong> in that cell instead of a card area. Its work cannot be planned until you share it.<\/p>\n<\/div>\n

\n

5<\/span>Do the child projects run the same template?<\/strong> Mixed templates mean card types do not line up, which makes both the board and any transfer between teams harder to read.<\/p>\n<\/div>\n

\n

!<\/span>Capacity Is the One Most Often Skipped<\/p>\n

\n

Until capacity is entered on a release, the planned bar has nothing to plot against and the board cannot tell you whether that release is over-committed. It is the quickest check to run and the easiest to forget.<\/p>\n<\/div>\n<\/div>\n

Once the increment is under way, the same program is tracked on the status screen, by goal or by delivery window. Sprint-level planning continues per release \u2014 see Sprint Planning at the Program Level<\/a>.<\/p>\n

\n