2026 Guidewire Delivery Improvements

October 2026

Chris Shu, Manager, PMO

In 2026 the PMO and TPM teams defined the Guidewire delivery workflow from epic selection through release, with a gate at each handoff and live status reporting. The largest remaining gap is before elaboration: how requests come in and how requirements are written.

Delivery workflow

Timing is relative to N = 0, the first day of the development sprint. Select a stage. The panel under the stages changes to show the improvements made for that stage. The rest of the page stays the same.

In action Already running in sprintsDefined, waiting Agreed, not yet in practicePlanned Still to be built

Gap

Selection to elaboration

Development

Test and release

Selected stage

Before

Improvements made

Remaining work: Request Intake Process

Request intake

Improvement planned · Target: end of Nov 2026

Today

Product Owners submit requests through the intake form as a free-form description.
There is no standard format for the details and decisions needed to give a request full context and a complete scope.

Issue: Jira tickets are inconsistent in detail, decisions, key impact areas, and scope.

What is planned

Add a dynamic ticket builder to the intake form. It uses AI to identify gaps in the request and suggest key impact areas to consider.
The form refers to the Guidewire application guides and Bamboo customizations to help assess the true scope of the change.
Impact is assessed before elaboration begins, which helps establish the true criticality of the ticket.
Create a detailed catalog of all applications in the Bamboo ecosystem, so the tool can assess impact across every application during intake.
Assign a Product Owner to each major application, with authority to make final decisions on changes to it.

Target

Target delivery: end of November 2026.

Changes by stage

Selection to elaboration

Stage	What changed in 2026	Status
PrioritizationBefore N-44	All Guidewire work is ranked on one list and reviewed with the business every month. Priorities are reviewed with the Product Owners to determine the scope for the next sprint. Each epic must have a named Product Owner before it can be selected.	In action
Epic selectionN-44	The PMO selects epics for each sprint 44 days ahead and notifies the Product Owners. Jira creates the BA, Dev, and QA tasks automatically.	Defined, waiting
PO requirementsN-44 to N-30	Product Owners have 14 days to complete the requirement in Jira. Each business unit has a named Product Owner and a backup. Elaboration now starts at N-30, giving 30 days before the development sprint. Before, requirements work started at N = 0.	Defined, waiting
BA elaborationN-30 to N-1	A 30-day elaboration sprint turns each requirement into stories with acceptance criteria. For complex epics, the Product Owner and BA give input to QA test design at N‑7. The BA walks the Product Owner through each story and the updated requirements, so they are fully understood before approval. Identify sequencing issues for large epics. Challenge: After Product Owner approval, any addition to scope requires formal approval through a Change Request form and review group.	Defined, waiting

Development and functional testing

Stage	What changed in 2026	Status
Dev sprint startN = 0	Work enters the sprint only if the Product Owner has approved the requirements. Anything else waits for the next sprint.	Defined, waiting
Build and functional QAN to N+10	QA writes test cases while development is under way. Status in Jira updates as each task closes. Code freeze date is fully enforced. Establish a change request approval process for last-minute change requests. Delivery accommodations must be considered to incorporate last-minute change requests.	Defined, waiting
Code freezeN+10	Code freeze is fixed at N+10, ten days into every sprint, so regression and UAT run against a stable build. Automated regression is expected by the end of October. Change requests after code freeze must follow a formal approval process.	In action

Testing, demo, release

Stage	What changed in 2026	Status
Regression and UATN+11 to N+27	Early business demo after functional testing is complete, for selected epics where possible. It helps the Product Owner break down the epic and confirm the functionality meets expectations. UAT runs once per release, not per epic. Give the Product Owner ample time to review test cases before approval. The Product Owner must approve the finished work before it is queued for release.	Defined, waiting
Go / No-GoN+27	The release decision is made against published criteria, with a written QA readiness statement.	In action
DeployN+28	One production release per sprint. The PMO owns the rollback decision.	In action
Verify and closeN+28 to N+29	QA verifies the release in production. The business confirms the result.	In action
Sprint reportAfter N+29	A report on the prior sprint covers regression and QA testing results, change requests raised after Product Owner approval, bugs found during functional testing, and causes of any deployment delay.	Defined, waiting

Reporting

Tool	What changed in 2026	Status
Maintenance trackerAll stages	Live view of all maintenance work by sprint and release, updated from Jira every hour.	In use
Executive release viewReleases	One page showing each release as complete, on track, at risk, or off track.	In use
Production defect boardDefects	One ranked list of open production defects.	In use
Agent issue intakeProduction issues	Agents report system issues through one form. Managers triage from one queue.	In use
2027 capacity planPlanning	2027 work laid out by track and sized by team.	In progress

Decisions needed

Approve the AI ticket builder

Approve building the AI ticket builder for the intake form, including the catalog of Bamboo applications it relies on.

Requirements final before elaboration

Epics without complete requirements at N-30 wait for the next sprint.