Opening & Connection
Welcome to the NOIDA 2026 Workshop facilitated by fluent. Together we'll build shared understanding of the DVA operating model and leave with clear commitments to improve.
"New outcomes do not come from tools. They come from the decisions we choose to make — and the discipline to act on them."
Align individuals and teams with shared knowledge of the evolving DVA operating model.
Throughout today: gather your thinking to answer "What will we focus on changing in the next 90 days?"
- We understand how our operating model design impacts business outcomes — and how to improve the model.
- We feel ownership for improving the model and how we deliver value — not just what we deliver.
- We leave with clear commitments to improve.
The conditions required for this workshop to be valuable. Check each as you commit to it.
- Teams will speak first
- I will use data, examples, or recent experiences to support my view
- I will interpret questions and challenges as a commitment to better outcomes
- I will focus on improving the system — not evaluating individuals
- I will minimize multitasking because my contribution matters
- If something feels unrealistic or unclear — I will say it early
Making decisions based on evidence gained through experience — not prediction alone.
Autonomy without empiricism becomes opinion.
Autonomy with empiricism becomes accountability.
Habits we see in high-performing product organizations:
For each pattern, use the stars to indicate: how well does your team do this today? Then consider: which would have the biggest impact if you improved?
Feature Development Lifecycle
The FDL describes the end-to-end journey a feature takes from idea to delivery. Understanding the whole system helps us improve how value flows.
In the spirit of continuous improvement, discuss at your table and capture your team's answers below:
The lifecycle spans Discovery and Delivery across five phases, each with clear activities and a graduation criteria:
- Problem to Solve is documented in issue type of Initiative in Jira
- Intake board of Initiatives is regularly maintained
- Impact is documented (# of users affected, Time Criticality, Risk Reduction, or revenue opportunity)
- Initial requirements (mini-PRD) created
- Review with the Director of Premiere Product — a Go/No Go decision needs to be made to move to Discovery
- Business Goal and Measure Criteria Defined
- Identify Dependencies
- Product Requirement Document
- Architecture feasibility review
- Low confidence estimate (t-shirt size)
- Determine Release Tier
- Go/No Go decision is made by the Director of Premiere Product and the Director of Premiere Engineering, or their designated delegate, to move to Planning
- Break down initiative into Epics
- For epics planned for the next quarter, Stories with Story Points are created
- Design Spec
- Coordinate with Dependencies
- Engineering Plan + Wiki (Tracking/Reporting system)
- Architecture Review + Solution Design
- Go/No Go decision is made by the Director of Premiere Product and the Director of Premiere Engineering, or their designated delegate, to move to Implementation
- Teams Demo Progress
- Regular status updates in Roadmap check-ins
- Roadmap is updated as Target dates are established
- Cross-Functional Leads confirms Definition of Done has been met and feature is promoted from kInternal to kPublicBeta/kRelease
- Teams Demo Progress
- Regular status updates in Roadmap check-ins
- Roadmap is updated as Target dates are established
- Cross-Functional Leads confirms Definition of Done has been met and feature is promoted from kInternal to kPublicBeta/kRelease
Each table maps the lifecycle using colored dots: ● Red = Friction ● Green = Flow
- Where does work enter today?
- Where do delays happen?
- Where do handoffs occur?
- Where do others intervene?
Walk and review other teams' maps. Capture debrief notes:
Work Breakdown
We cannot forecast and plan for what we cannot understand. Breaking work down is the foundation of predictability.
Large batches increase variability and slow everything down. Small batches go through the system faster, with lower variability. The most important batch is the transport batch.
Large batch size increases variability.
High utilization increases variability.
Severe slippage is the most likely result when batches are too large.
Small batches go through the system faster, with lower variability.
- Contain background info with a description of the problem to solve and benefit to the customer
- Be valuable to the user
- Have acceptance criteria so it's clear when done
- Contain success measures for adoption rate
- Include a release plan
- Be a categorization tool (e.g., "UI Changes" or "Tech Debt")
- Take longer than 1 quarter (3 months) to complete
- Be written in super technical language — it should be clear to an executive
What matters: shared understanding of Who, What, and Why? and How will we know to stop investing?
Product Backlog
All of the work the team needs to do. Constantly refined and reprioritized based on stakeholder feedback. Items may be added, split, reordered, or removed at any time.
Sprint Backlog
All of the work the team needs to do in the sprint. Pulled from the top of the Product Backlog during Sprint Planning based on capacity and goal.
At your table:
- Identify a real Initiative your team is working on
- Break it into 3 or more Epics
- Break 1 Epic into Stories using the INVEST criteria
Which stories or epics are still too big? How would you split them?
Which are unclear? What information is missing?
What is missing for readiness — what needs to happen before this enters a sprint?
Readiness, Refinement & Estimating
Making upcoming work clear, small, and sized so it's ready for sprint planning. This is the engine of predictable delivery.
At the sprint/story level: clear enough to commit.
A story is ready when the team has enough shared understanding to begin work confidently.
At the sprint/story level: valuable and releasable.
Done means the increment meets quality standards and could be released to users.
Goal: 60 minutes of refinement should result in 2 weeks of work ready for sprint planning.
Participants: EM, PM, Engineers, and Designers. Hold refinement 1–2 times per sprint, 60 min total. Product Manager leads, preparing work in advance.
- Review the top of the Product Backlog — PM and Design provide context on epics and issues. Engineers ask clarifying questions. Capture uncertainties and follow-ups.
- Refine & Detail Issues — Break down large items. Adjust acceptance criteria. Identify dependencies and blockers.
- Estimate Backlog Items — Use Planning Poker to Story Point issues.
- PM identifies which issues are for discussion in advance
- Designer has demoed relevant work to align the team on changes
- Avoid bringing an empty Jira ticket — business value should be clear
- Initial Acceptance Criteria is defined before the meeting
- Any supporting documentation is attached
- The Product Backlog is prioritized
Absolute Estimates (time-based) are fragile. Estimating in hours or days requires precision you don't have early in discovery.
Relative Sizing (story points) compares work to other work. Like judging building heights — we don't need exact feet to say one is twice as tall.
- Story Points measure relative effort, not time
- Consider complexity, amount of work, and risk (including unknowns)
- Use the Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100
- If a story scores 13+, it's probably too big — split it
- Use Planning Poker to surface differing assumptions and build shared understanding
Experience the difference between large and small batches with coins. Your facilitator will run this activity. Capture your results:
Forecasting
Forecasting is not a promise — it's a probability statement grounded in actual team data. Like a GPS: it gives you an ETA, adjusts when conditions change, and re-routes if needed.
"When will we get to Disney?" — You can answer this confidently once you know the route, your current speed, and traffic conditions. Forecasting software delivery works the same way.
- Understand the Team's Velocity — How many story points does the team complete per sprint on average?
- Slot Sized Stories into Sprints — Based on priority, load sprints at or below available capacity.
- Identify Epic Completion Dates — An epic is done when all its stories are done. Find the sprint in which the last story completes.
- Sprint 1: April 1 – 14
- Sprint 2: April 15 – 28
- Sprint 3: April 29 – May 12
- Sprint 4: May 13 – May 26
- Sprint 5: May 27 – June 9
Focus on the habit and capability patterns, not just the event or ritual. Our ability to forecast delivery improves as the system improves.
- Transparency of progress and impediments
- Evidence over opinion
- Small feedback loop
- Ownership of the system
- Continuous adaptation
- In time, our ability to forecast delivery improves with the system
Does your team have enough story point history to forecast accurately? What's missing?
What causes your team's velocity to vary sprint to sprint? How might you stabilize it?
How do you currently communicate forecast changes to stakeholders? What would be better?
Day 1 Reflection
Before we close Day One, take a few minutes to consolidate your thinking and identify what's already surfacing for your 90-day commitment.
- I understand the FDL and where our work typically enters and exits each stage
- I can articulate the difference between an Initiative, Epic, and Story
- I understand what makes a story "ready" vs. "done"
- I can explain how velocity and story points connect to forecasting
- I identified at least one friction point in our current lifecycle
- Quarterly Planning — Simulation + full process walkthrough
- Working Agreements — CLEAR framework + team drafts
- Integration — Closing activity: "What changes in 90 days?"
Quarterly Planning
A cadence-based event that aligns teams and stakeholders to a shared mission and vision — and produces committed delivery forecasts for the quarter.
- Business context
- Solution Vision and Roadmap
- Ready and Prioritized Epic Backlog
- Team Capacity
- Committed Epics
- Organization Planning Board with critical delivery dates, dependencies, and milestones
- Establishes collaborative conversations among all involved in achieving business outcomes
- Builds the social network the organization depends upon to be highly effective
- Aligns development activities to business goals with context, vision, and objectives
- Identifies dependencies and fosters organizational collaboration
- Provides just the right amount of guidance to enable fast decision-making
- Matches demand to capacity and eliminates excess work in process
- Early identification and resolution of risks
Example: Discovery 30% | Defects 20% | Feature Delivery 50%
Dependencies slow flow, increase coordination cost, and create schedule risk. Unmanaged dependencies erode predictability — our key business outcome. Visibility turns "surprises" into manageable risks.
- Slow value flow
- Increase coordination cost
- Create schedule risk
- Erode predictability
- Identify early — map teams, systems, vendors needed
- Visualize — use dependency boards
- Sequence intentionally
- Negotiate ownership — leads vs. supports
- ROAM them before committing to the plan
Make threats to the plan visible, decide what to do about them, and assign clear ownership — before sprinting.
What was difficult about the capacity estimation exercise? What data were you missing?
What surprised you when you sequenced stories into sprints?
Which dependencies surfaced that you hadn't anticipated? How would you ROAM them?
Working Agreements
Effective teams operate on explicit, agreed-upon norms. The CLEAR framework helps you build agreements that stick.
Agreements move teams from implicit, individual assumptions to explicit, shared accountability. They reduce conflict and create psychological safety to raise problems early.
Implicit + Concrete (Intuitive Quadrant)
Give specific examples to draw clarity →
Implicit + Abstract (Foggy Quadrant)
Define actions & behaviors, give examples →
Explicit + Concrete (CLEAR Quadrant ★)
Enjoy and renegotiate as needed.
Explicit + Abstract (Confusing Quadrant)
Define actions & behaviors ↑
Use the space below to draft your team's working agreement. Make each statement concrete, specific, and actionable. Aim for 5–8 agreements.
Integration & Close
This is what the two days have been building toward. Each team will answer: "What will change in the next 90 days?"
"New outcomes do not come from tools. They come from the decisions we choose to make — and the discipline to act on them."
Write one idea per sticky note (use the fields below for digital capture):
At each table: share ideas, cluster similar themes, and force-select ONLY 3 commitments — one from each category:
For each of your 3 commitments, complete a canvas below:
Commitment #1
Commitment #2
Commitment #3
Each team posts their 3 commitments. Everyone walks the room. Read other teams' commitments — look for alignment opportunities and cross-team dependencies.
What support will you provide to enable these commitments?
What obstacles will you commit to removing?
What policy might need to change?
Take a few minutes to reflect on the two days. These insights help Fluent continuously improve future sessions.
Thank You!
Getting better every day.