Modern XP: The Feedback Loop

Plans are worthless. Planning is everything. XP understood this before the rest of the industry caught up.

This is the fourth and final technical post on XP’s reinforcing practice loops. The previous posts covered the code quality loop, the knowledge sharing loop, and the delivery loop. This post covers the practices that determine whether everything you build is worth building.

The planning game and customer collaboration are XP’s answer to a question that plagues every software team: how do you build the right thing? Not how do you build it fast, or build it well, or build it reliably. How do you know you’re building what users need?

The planning game: what it actually is

The planning game is a structured conversation between business people and developers about what to build next. Business decides what’s valuable. Developers estimate what’s feasible. Together, they choose the work for the next iteration.

This sounds obvious. It’s not how most teams work.

Most teams have adopted a distorted version. A product owner writes stories in Jira. Developers estimate them with story points during a “refinement” meeting. The stories are prioritized by business value (in theory) and pulled into a sprint. The team executes the sprint. Two weeks later, they demo the results.

The distortions are subtle but consequential:

Estimation has replaced conversation. The focus of planning meetings has shifted from “what should we build and why” to “how many points is this.” Teams spend more time debating whether a story is a 5 or an 8 than discussing whether it’s the right thing to build at all.

Stories are written in isolation. The product owner writes stories alone, often weeks before the team sees them. By the time developers encounter a story, the decisions have been made. The “planning” is just estimation and scheduling.

Feedback is delayed. The demo at the end of the sprint is the first time stakeholders see working software. If the direction is wrong, two weeks of work needs correction. If the demo is skipped (and it often is), feedback is delayed further.

How the planning game works

In XP, the planning game operates on two levels: release planning and iteration planning.

Release planning determines the scope of the next release. The customer (or product owner) presents the stories they want. Developers estimate the effort. The customer prioritizes based on business value and cost. The team commits to a set of stories that fit within the release timeframe. This plan is revisited regularly as the team learns more.

Iteration planning (typically weekly in XP, not biweekly) selects the work for the next iteration. The customer picks the highest-priority stories from the release plan. Developers break them into tasks and commit to what they can complete. The iteration is short enough that course corrections are cheap.

The key difference from modern sprint planning: the customer is in the room, making trade-off decisions in real time. “This story is too expensive? What if we simplified it to just handle the common case?” That conversation happens during planning, not in a Slack thread three days later.

Estimation that serves a purpose

XP uses estimation to inform trade-off decisions, not to measure developer productivity or predict delivery dates with false precision.

When a developer says “this story is about three ideal days of work,” the customer can compare that cost against the business value and decide whether it’s worth doing now, later, or at all. That’s the purpose of the estimate: a rough input to a business decision.

Story points were introduced to abstract away the connection to time, which was intended to reduce pressure on developers. In practice, many organizations convert story points back to time (one point equals one day), use velocity to predict delivery dates, and hold teams accountable to those predictions. This defeats the purpose. The estimate becomes a commitment, the commitment becomes a deadline, and the deadline becomes pressure to cut corners.

XP’s approach is simpler: estimate in whatever unit makes sense, use estimates to make scope decisions, and adjust the plan when reality diverges from the estimate. The plan is a hypothesis, not a contract.

Customer collaboration: closer than you think

XP’s original formulation called for a “customer on-site”: a real business representative who sits with the team, answers questions in real time, makes priority decisions, and provides feedback on working software throughout the iteration.

This was radical in 1999 and it’s still rare today. Most teams interact with their customer (or product owner) in scheduled meetings. Questions that arise during development sit in a queue until the next standup, the next refinement, or the next time someone remembers to ask.

The cost of this delay is invisible but real. A developer encounters an ambiguity in a story. They make an assumption and keep working. Two days later, the assumption turns out to be wrong. The work is partially redone. This happens multiple times per sprint on most teams. Nobody tracks it because it’s “just how development works.”

What close collaboration looks like today

The customer doesn’t need to sit at a desk next to the team. They need to be accessible and engaged.

Available for questions within minutes, not days. When a developer hits an ambiguity, the customer answers it before the developer has time to build on a wrong assumption. This doesn’t mean constant interruption. It means a dedicated Slack channel or a standing “office hours” block where the customer is responsive.

Reviewing working software continuously, not at sprint boundaries. When a story is done (or partially done), the customer sees it that day. Not in two weeks at a demo. Feedback is immediate. Course corrections are small.

Making trade-off decisions in real time. “This edge case will take two more days to handle. Is it worth it?” The customer answers this during development, not after a formal change request process.

Participating in planning as a collaborator, not a requester. The customer doesn’t throw stories over a wall. They sit in planning, hear the cost of their requests, and make informed decisions about scope, priority, and trade-offs.

The connection to modern product thinking

The Lean Startup movement, design thinking, continuous discovery, and jobs-to-be-done frameworks all arrived after XP. They all emphasize the same core idea: build small things, get feedback fast, and adjust.

XP had this in 1999. The planning game is iterative scoping. Customer collaboration is continuous discovery. Small releases (from the delivery loop) are the mechanism for getting real feedback from real users.

The product community rediscovered what XP already practiced: you can’t plan your way to a good product. You iterate your way there. The feedback loop is not optional.

The reinforcing loop

The planning game and customer collaboration depend on each other.

Planning game without customer collaboration: The team plans iterations, but the customer is absent between planning sessions. Questions go unanswered. Assumptions accumulate. By the end of the iteration, the delivered software doesn’t match what the customer expected because the customer wasn’t there to steer.

Customer collaboration without the planning game: The customer is available and engaged, but there’s no structured process for deciding what to build. Priorities shift daily. The team reacts to the loudest request. Work starts but doesn’t finish. The customer’s availability becomes a source of chaos instead of clarity.

Together, the planning game provides structure (what are we building this iteration and why) and customer collaboration provides responsiveness (is this what you meant? should we adjust?). Structure without responsiveness is rigid. Responsiveness without structure is chaotic.

How the feedback loop connects to everything else

This loop depends on every other loop in the series.

The code quality loop (TDD, refactoring, simple design) makes it possible to respond to feedback. When the customer says “actually, we need it to work differently,” the team can change direction because the code is well-tested, well-structured, and simple enough to modify.

The knowledge sharing loop (pair programming, collective ownership) means any developer can work on any part of the system. When priorities shift during an iteration, work can be reassigned without waiting for the one person who “owns” that module.

The delivery loop (CI, small releases) means feedback is based on real software in production, not demos of development builds. Users interact with the actual product. Problems are discovered in context. Feedback is grounded in reality.

Without these supporting loops, the feedback loop is aspirational. You can plan and collaborate, but if the code can’t change, the team can’t flex, and the software doesn’t ship, the feedback has nowhere to go.

Getting started

Put the customer in the room. If your product owner attends only sprint planning and demo, that’s not enough. Create a channel or ritual where developers can get answers to questions within hours, not days.

Shorten iteration length. If you’re on two-week sprints, try one week. Shorter iterations mean faster feedback and smaller course corrections.

Stop treating estimates as commitments. Use estimates to make scope decisions during planning. When reality diverges from the estimate, adjust the scope, not the deadline. If velocity is being used to pressure teams, that’s a process problem, not an estimation problem.

Review working software continuously. Don’t wait for the demo. When a story is done, show it to the customer. Get feedback while the context is fresh and the cost of change is low.

Track assumption-driven rework. When work is redone because an assumption was wrong, note it. This makes the cost of slow feedback visible. Most teams are surprised by how much rework stems from questions that could have been answered in five minutes.

The feedback loop completes the system. Code quality makes change safe. Knowledge sharing makes the team flexible. Delivery gets software to users. Feedback ensures you’re building the right thing.

The next and final post in this series makes the business case for XP as a complete system, written for the leaders who fund and prioritize the work.