2026 Guidewire Delivery Improvements

October 2026

Chris Shu, Manager, PMO

Done in 2026: PMO and TPM built the Guidewire delivery workflow end to end, from epic selection through release. Every stage has a gate and status is tracked live.
Two gaps left: improve intake quality and process, and add sprint reporting to learn from prior sprint issues in order to continually improve the process.
Request intake: a standard intake form so requests come in complete. Scope and impact are defined before elaboration, which reduces requirement changes and change requests. Target: end of November 2026.
Sprint report: bugs, change requests, and sprint issues reported after every sprint. Retros use the data to fix recurring problems.

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, left to right, what it was like before, the improvements, and how they help. 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

Gap

Selected stage

Before

Improvements

How it helps

Remaining work

Two gaps remain: request intake before the workflow, and sprint reporting after it.

Before the workflow: request intake

In Development · Target: end of November 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.
Create a detailed catalog of all applications in the Bamboo ecosystem, so the tool can assess impact across every application during intake.
Impact is assessed before elaboration begins, which helps establish the true criticality of the ticket.
Assign a Product Owner to each major application, with authority to make final decisions on changes to it and full accountability as defined and agreed upon by the Product Owner.

Key impact

Complete requirements at intake. Every request arrives with the same details, decisions, and scope, so elaboration starts from a full picture.
No application missed. Each request is checked against the catalog of all Bamboo applications, so every affected system is identified at intake.
Downstream impact found early. Effects on connected systems and teams are identified before elaboration, not during testing or after release.
True scope and priority. Effort and criticality reflect the full impact, so prioritization and sprint planning are based on the real size of the change.
Fewer changes later. Fewer requirement changes after Product Owner approval and fewer change requests during the sprint.
Clear ownership. A named Product Owner for each application makes the final decision and is accountable for it.

Target

Target delivery: end of November 2026.

After the workflow: sprint report

In Development

Today

There is no reporting on sprint results after release.
Retros rely on what people remember, not on data from the sprint.

Issue: The same problems can repeat from sprint to sprint without being seen.

What is being built

A report on each completed sprint, reviewed in the retro.
Number of change requests raised after Product Owner approval.
Number of bugs found during functional testing.
Regression and QA testing results.
Causes of deployment delay, if any.

Key impact

The teams learn from prior sprint performance and apply it to the next sprint.
Comparing sprints shows recurring problem areas.
Testing issues are identified and addressed.
Specific issues can be traced back to their source for coaching.

Changes by stage

Selection to elaboration

Stage	What changed in 2026	Status
PrioritizationBefore N-44	All Guidewire work is ranked on one list. The list is 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 44 days before the sprint 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 work. Dependencies across the Bamboo ecosystem are documented and tracked in Jira. Sequencing dependencies are identified and the work is aligned to them.	Defined, waiting
PO requirementsN-44 to N-30	Each business unit has a named Product Owner and a backup. Product Owners have 14 days to complete the requirement in Jira. The team tracks the due dates before aligning epics to the sprint.	Defined, waiting
BA elaborationN-30 to N-1	Elaboration starts at N-30, giving 30 days before the development sprint. The elaboration sprint turns each requirement into stories with acceptance criteria. Dev and QA leads answer system-impact questions during elaboration. Elaboration and approvals consider impact across the Bamboo ecosystem, to minimize requirement changes and later change requests. Sequencing issues are identified for large epics. 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. Challenge: After Product Owner approval, any addition to scope requires formal approval through a Change Request form and review group.	In action

Development

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 testingN to N+10	Regular PMO and TPM meetings are held for prioritization and release management. 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. Build and functional testing are currently estimated to complete by N+10. Retros are held at the end of the sprint. Releases are on time with minimal disruption, and challenges are addressed as they come up. Next: Run bug triage proactively on a defined schedule. Plan early business demos with the business and Product Owners for complex epics. Start a cross-initiative forum to manage release dependencies such as D2C, regression, and environment syncing. Formalize the process for change requests introduced during the release, including delivery accommodations for last-minute requests. Enforce code freeze (Dev Complete) with strict guidelines.	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. Regression and UAT run against a stable build. Change requests after code freeze require formal approval. Next: Automated regression is expected by the end of October 2026.	In action

Test and release

Stage	What changed in 2026	Status
Regression and UATN+11 to N+27	An early business demo follows functional testing for complex epics, where possible. It helps the Product Owner confirm the functionality meets expectations. Regression runs against the release candidate. The Product Owner has ample time to review test cases before approval. UAT runs once per release, not per epic. UAT status is tracked by epic as part of the release. 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 criteria published before the meeting. Stakeholders are aligned on open items from the release and the next steps for each, ahead of the decision. QA provides a written readiness statement. The decision and any conditions are recorded.	In action
DeployN+28	One production release per sprint. The PMO owns the rollback decision. All epics in the release are closed in Jira together.	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 each completed sprint, reviewed in the retro. It covers change requests raised after Product Owner approval, bugs found during functional testing, regression and QA testing results, and causes of any deployment delay. The teams learn from prior sprint performance and apply it to the next sprint. Comparing sprints shows recurring problem areas. Testing issues are identified and addressed. Specific issues can be traced back to their source for coaching.	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