Planning poker is an estimation technique in which team members simultaneously reveal their estimates for a story, then discuss discrepancies before converging on a number. The standard explanation for why it works is that simultaneous reveal prevents anchoring — no one’s estimate influences others before they have formed their own. This is true and not the main reason the technique is valuable. The main reason planning poker works is that it makes disagreement visible.

The phrase prompt engineering acquired a skeptical connotation early — something between a joke about talking to chatbots and a transitional skill that would be obsoleted as models improved. Neither characterization was accurate, and teams that dismissed it on those grounds have paid a real productivity cost. Prompting a code generation model effectively is a software discipline because it shares the fundamental characteristics of all software work: it requires precise specification of desired behavior, systematic handling of edge cases, and iterative refinement based on observed output.

When agile teams moved to remote work, the common concern was whether the ceremonies would survive the transition. Would sprint planning work over video? Could retrospectives produce candor without physical presence? Would the daily standup maintain its discipline when the team was distributed across time zones? These concerns were largely misplaced. The ceremonies adapted. Video-based sprint planning, while less fluid than in-person, functions well enough with the right tools and facilitation.

For most of software’s history, vague requirements were expensive but survivable. A developer who received an underspecified ticket could ask a question, make a reasonable inference, or build a small prototype and get feedback. The cost of ambiguity was absorbed in back-and-forth, rework, and the gradual clarification that happened naturally when humans were iterating together. AI-assisted development has changed the economics of ambiguity in a way that most teams have not fully reckoned with.

The retrospective is the most important ceremony in the sprint cycle and the one most commonly reduced to ritual. Teams go through the motions — what went well, what didn’t, what to improve — produce a list of action items, and proceed to the next sprint having changed nothing. The list sits in a document somewhere. The problems repeat. This failure mode is so common that many experienced practitioners have concluded retrospectives do not work.

The large story is one of the most reliable predictors of sprint failure. A story that spans more than half a sprint occupies the team’s attention, resists review, and tends to arrive at the sprint boundary in a state of near-done that creates exactly the kind of work-in-progress debt that sprints are designed to prevent. Teams know this. They continue to carry large stories because splitting them well is genuinely difficult and the techniques for doing it are not intuitive.

Technical debt in most agile teams exists in two places: in the codebase, where it slows down every sprint without appearing in any sprint report, and in informal conversations between developers, where it is acknowledged but never prioritized. This arrangement persists because engineers are reluctant to burden the product owner with implementation concerns, and product owners are reluctant to prioritize work that has no visible user-facing outcome. The debt accumulates. The sprints slow down.

Technical debt was always a metaphor with a compounding interest rate. Decisions made quickly to ship a feature cost more to address the longer they remained in the codebase. Teams that managed debt well built systems that stayed malleable. Teams that ignored it built systems that eventually could not be changed without risk of collapse. AI-assisted development has not eliminated this dynamic. It has accelerated the principal. The speed at which code can be generated means that architectural decisions — or the absence of them — propagate through a codebase faster than ever before.

Test-driven development was always more useful as a design discipline than a testing strategy. Writing the test first forced clarity about what the code was supposed to do before any implementation decisions were made. The red-green-refactor loop was valuable because it built understanding incrementally. AI-assisted development has resurfaced this distinction in an unexpected way. When code can be generated quickly from a specification, the temptation is to generate the implementation first and the tests afterward — or to generate both simultaneously and treat passing tests as evidence of correctness.

The #NoEstimates movement emerged from a simple observation: software estimation is expensive, frequently inaccurate, and the act of producing an estimate often shapes behavior in ways that undermine the purpose of the estimate. Teams that spend significant time debating whether a story is a three or a five are investing real effort in a number that will be wrong and then used to evaluate their performance. The question the movement raises is whether that investment produces enough value to justify the cost.