The AmpGPT Team Situations and Interventions Guide

How to Engage With AmpGPT

This section is designed as a practical guide for evolving Scrum in real environments. Rather than replacing Scrum with another set of prescribed practices, it looks at the intent behind Scrum’s roles, events, and artifacts—and then examines how well that intent is actually being achieved. From there, it introduces system, cognitive, and learning dynamics to help explain why certain patterns emerge and why some practices, even when well-intended, often lead to unintended results.

Each item is structured to help you move from following practices to understanding them. You’ll see the objective a practice is meant to serve, the principles that influence its effectiveness, and examples of what commonly happens in real teams. Most importantly, you’ll be given alternative approaches and guidance on when to use them. The goal is not to prescribe a “better way,” but to help you develop the ability to choose and adapt practices based on your specific context—so that your system improves over time, rather than becoming fixed in place.

While many of the topics below have a structure or other additional information, you can ask it about the topic even if nothing is listed.

To get AmpGPT helping you, go to ChatGPT, and start by saying:

“Engage as AmpGPT, Success Engineering’s AI companion based on the Amplio system, the Physics of Flow, and the Amplio Learning Kata. Help me think through problems, coaching situations, and learning using the AmpGPT interaction patterns.”

You can ask it questions from the Scrum Evolution Guide or the Situations AmpGPT can help you with, or anything else.

Scrum Evolution Guide

While many of the topics below have a structure or other additional information, you can ask it about the topic even if nothing is listed.

Roles

Amplio prefers to think of roles as responsibilities and not equate them to people. That said, here are different ways Scrum roles can be made more flexible and effective.

Scrum Master

To learn about this topic, simple ask AmpGPT for information on it.

Product Owner

To learn about this topic, simple ask AmpGPT for information on it.

Developers (development team)

To learn about this topic, simple ask AmpGPT for information on it.

Stakeholders

To learn about this topic, simple ask AmpGPT for information on it.

Management

To learn about this topic, simple ask AmpGPT for information on it.

Events

Events are coordinated with the strict cadence of the sprint. In this section we’ll investigate whether sprints or a flow model is superior for your situation.

Sprints (and considering if flow would be a better model)

Scrum Practice

Work is organized into fixed-length sprints (timeboxed iterations).

Intended Objective

Create a regular cadence for planning, execution, and feedback.

Relevant Principles / Axioms

Work should flow smoothly through the system
Smaller batches reduce delay and increase feedback
Delays create additional work
Feedback loops should be as fast as possible
Practices should be adapted based on context

What Often Happens

Sprints create a rhythm—but also introduce constraints:

work is held to fit the sprint boundary
partially completed work carries over
urgency increases near the end of the sprint
feedback is delayed until sprint boundaries

Over time, the system optimizes around the sprint—not flow.

Example

A team has work that could be completed in a few days, but waits to release it at the end of the sprint. Meanwhile, other work sits unfinished because the sprint boundary dictates timing rather than readiness.

Alternative Practices

Continuous flow (no fixed iterations)
One-day timeboxes (shortened cadence)
Hybrid models (flow within lightweight cadence)
Release on completion instead of sprint boundaries

How to Choose

Use sprints when:
- teams need structure and predictability
- coordination requires a regular cadence
- learning how to work together
Use flow when:
- work varies in size
- delays are creating rework
- fast feedback is critical
Use shorter timeboxes or hybrid approaches when:
- transitioning from sprints to flow
- balancing coordination with responsiveness

Sprint Planning

To learn about this topic, simple ask AmpGPT for information on it.

Daily Scrum

To learn about this topic, simple ask AmpGPT for information on it.

Sprint review

To learn about this topic, simple ask AmpGPT for information on it.

Sprint retrospective

To learn about this topic, simple ask AmpGPT for information on it.

Artifacts

Product Backlog

To learn about this topic, simple ask AmpGPT for information on it.

Sprint backlog

To learn about this topic, simple ask AmpGPT for information on it.

Increment

To learn about this topic, simple ask AmpGPT for information on it.

Artifact Commitments

Product Goal

Your content goes here. Edit or remove this text inline or in the module Content settings. You can also style every aspect of this content in the module Design settings and even apply custom CSS to this text in the module Advanced settings.

Sprint goal

To learn about this topic, simple ask AmpGPT for information on it.

Definition of Done

To learn about this topic, simple ask AmpGPT for information on it.

The rest of the topics.

to get more on a topic, simple engage with AmpGPT and ask it to tell you about the topic.

5. Core Rules / Structural Constraints

These are important because your “bridge” explicitly modifies them.

Timeboxed Sprints (fixed iteration length)
Immutable framework (Scrum is defined and not to be changed)
Cross-functional, self-managing teams
No sub-teams
One Product Owner per Product Backlog
Events must occur as defined

Common Practices (Not in Scrum, but widely used)

These are de facto parts of Scrum. While not in the Scrum guide they are ubiquitous in both Scrum training and Scrum adoptions.

The three questions

TBD: More is coming but in the meantime you can ask AmpGPT about the three questions.

Estimation (Planning Poker vs Team Estimation)

Scrum Practice

Teams estimate work using story points, often through Planning Poker.

Intended Objective

Create shared understanding of work and enable planning.

Relevant Principles / Axioms

Decisions should be based on improving flow, not just prediction
Excessive precision in uncertain environments creates waste
Shared understanding is more valuable than numeric estimates
Learning comes from feedback, not prediction alone

What Often Happens

Estimation becomes:

time-consuming
focused on assigning numbers rather than understanding work
treated as a commitment rather than a forecast

The discussion shifts from:

“What do we need to succeed?”

to:

“What number should this be?”

Example

A team spends significant time debating whether something is a 5 or an 8, but still encounters unexpected issues during development. The number did not reduce uncertainty.

Alternative Practices

Team estimation (quick alignment without formal scoring)
Relative sizing without numeric precision
No-estimation approaches (focus on flow and throughput)
Splitting work into smaller, more predictable pieces

How to Choose

Use Planning Poker when:
- teams are new and need structured discussion
- alignment is weak
- shared understanding is the primary goal
Use team estimation when:
- teams already collaborate well
- speed matters more than precision
Use minimal or no estimation when:
- work is small and similar in size
- flow metrics (throughput, cycle time) are available

6. Common Practices (Not in Scrum, But Universal in Use)

These are critical for your approach because they expose the cognitive + learning dynamics.

The “3 questions” in Daily Scrum
Planning Poker
Story points
User Stories
Epics / Features / Stories hierarchy
MVP framing
Backlog refinement sessions
Velocity tracking

7. Key Decision Areas (Where You’ll Add the Most Value)

These are not explicit Scrum elements—but they are where your Amplio layer shines.

Sprints vs Flow
Estimation approaches (team estimation vs story points)
Coordination methods (standups vs flow-based sync)
Work definition (user stories vs objective stories)
Value definition (backlog vs value-driven objectives)
Team structure (feature teams vs value stream alignment)

Why This Structure Matters

This gives you three layers:

1. What Scrum defines

→ roles, events, artifacts

2. What Scrum implies but doesn’t define well

→ rules, structure

3. What actually determines success

→ practices + decisions

AmpGPT can discuss anything you like.

The situations many people find themselves in are listed on the right.

AmpGPT will help you diagnose what’s happening, understand what may be causing it, and guide you to the next useful step.

The situations listed below are common ones we see. AmpGPT can help you understand the cause of them and how to improve them. The outline provided in the situation detail lists some of the topics AmpGPT may talk about. They are not intended to be used on their own as a guide.

This Team Situations & Intervention Guide is a collection of the most common situations teams encounter when trying to improve how they work—such as work not finishing, constant interruptions, or being blocked by dependencies—along with guidance on how to address them. Instead of providing step-by-step instructions or abstract best practices, it focuses on helping you start from what’s actually happening in your environment. Each situation is paired with proven intervention patterns and the underlying thinking needed to make effective decisions. Used with AmpGPT, the guide becomes interactive—helping you diagnose your specific context, understand what’s driving the issue, and take the next useful step to improve flow, alignment, and outcomes.

To get AmpGPT helping you, start by saying:

Then tell AmpGPT about a situation you want help with.
For example:

“Nothing is finishing.”
“We’re blocked by dependencies.”
“Our team feels chaotic.”

You can also select any of the situations listed on the right.

Several other situations are being added regularly, but you can ask about any situation you want.

The Situations AmpGPT Can Help You With

Team Situations and Interventions

Situation: Nothing is finishing or there is high carryover between iterations.

Solution:

Create a focus on finishing:

Limit work in process
Stop starting new work when items are close to done
Swarm to finish existing work
focus on finishing stories in a feature before starting a new feature. (Don’t fragment value across multiple features. Complete value before starting new value.)
Finish the work that delivers the most value or creates the fastest meaningful feedback

System Dynamics:

High WIP increases delays due to multi-tasking and queueing
Delayed feedback increases rework and uncertainty
Value is realized when work is completed, not when it is started
Splitting work across multiple features delays value realization
Completing a feature enables earlier feedback and reduces risk

Cognitive Dynamics: (This is often a place we can look to to reframe things)

People equate starting work with progress
Individuals optimize for their own productivity rather than team outcomes
There is often discomfort in “waiting” or helping others instead of starting new work

Learning Dynamics:

Make WIP and carryover visible (before/after comparison)
Run a short experiment: limit WIP for a few days or one sprint
Reflect on what changed (cycle time, completion rate, stress)
Reinforce the new distinction: finishing creates progress

We are frequently blocked waiting on other teams or people.

Solution:

1. Start by making dependencies visible and reducing delay

Identify where work is waiting and for how long
Make blocked work visible on the board
Look for ways to sequence or decouple work to reduce dependencies

2. Reduce or Sequence Dependencies

Can we reorder work?
Can we complete something independent first?
Can we decouple parts of the work?

3. Should we introduce structural options?

Borrowed team member
Shared team member

System Dynamics:

delays caused by handoffs
queueing at specialists
constraints in the system

Cognitive Dynamics:

“that’s not our job” mindset
local ownership vs system thinking

Learning Dynamics:

seeing delays vs assuming them
experimenting with new collaboration patterns