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 practiceIn Development Being built now

Gap

Selection to elaboration

Development

Test and release

Selected stage

Before

Improvements made

Remaining work: Request Intake Process

Request intake

In Development · 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 being built

Intake form with pre-populated suggestions based on the type of enhancement request, such as product change, UI change, form update, or rating.
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. Focused grooming sessions define scope, identify dependencies, set high-level estimates, and plan the enhancements. Dependencies across the full ecosystem are documented and tracked in Jira. Sequencing dependencies are identified and aligned.	Defined, waiting
PO requirementsN-44 to N-30	Product Owners have 14 days to complete the requirement in Jira. The team tracks the due dates before aligning to the sprint. 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. Requirement elaboration and approvals consider the impact across the full ecosystem, to minimize requirement changes and future change requests. Challenge: After Product Owner approval, any addition to scope requires formal approval through a Change Request form and review group.	In action

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.	In action
Build and functional QAN to N+10	QA writes test cases while development is under way. Status in Jira updates as each task closes. Bug triage is handled during the sprint as needed. Mid-sprint demos are shown to the business and Product Owners after QA. Retros are held at the end of the sprint. Regular PMO and TPM meetings are scheduled for prioritization and release management. Releases are on time with minimal disruption, and challenges are addressed as they come up. Current estimate is N+10 to complete build and functional testing. Enforce code freeze (Dev Complete) with strict guidelines. Bug triage must be handled proactively on a defined schedule. Start a cross-initiative forum to discuss and manage release dependencies such as D2C, regression, and environment syncing. Establish a process to manage change requests introduced during the release, including last-minute requests. Delivery accommodations must be considered to incorporate last-minute change requests. Plan early business demos with the business and Product Owners for complex enhancements.	In action
Code freeze (Dev Complete)N+10	Code freeze is defined as Dev Complete: all development for the release is finished. It 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. UAT statuses are tracked by epic as part of the release. 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. Stakeholders are aligned on open items from the release and the next steps for each, ahead of the decision.	In action
DeployN+28	One production release per sprint. The PMO owns the rollback decision.	In action
Verify and closeN+28 to N+29	Post-deployment activities are defined and listed before the release. QA verification in production, business confirmation, and PMO acceptance continue as before.	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.	In Development

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.