These are my notes on why software teams keep missing deadlines, keep losing track of what their own product does, and keep ending up with a hundred features and almost no test cases. I wrote them for myself first, after watching the same failure repeat sprint after sprint and realising it was never a people problem.
The one idea holding all of it together: don’t just build features, plan them, define them, test them, document them, and make them maintainable.
Everything starts at Why We Miss Deadlines. That note defines the problem, traces it to five root causes, and says what to do about it in what order. The rest of these notes are the detail behind it, and I deliberately kept them separate so the main note stays readable and each idea can be understood on its own.
If you want the short path
Read Why We Miss Deadlines, then Feedback and Scope Control, then Work Breakdown Hierarchy. Those three cover most of the damage. If the vocabulary itself is the blocker, the one page cheat sheet is Glossary, and if you just want to start today, Adoption Plan is the week by week version.
If you want the full path
Work is cut up properly in Work Breakdown Hierarchy, which explains the difference between an Epic, a Feature, a User Story and a Task, and gives rules for deciding which is which. The craft of writing the Story sentence itself, plus how to split a Story that is too big, is in Writing User Stories. What the Story should do, written before anyone codes, is Acceptance Criteria. When you want to stop writing these from scratch every time, Templates has copy paste blocks for every work item type.
Work enters a sprint only after passing Definition of Ready, and leaves it only after passing Definition of Done. Those are the two gates that our process is usually missing entirely.
Sizing is in Estimation and Story Points, which explains what a point actually measures, why the Fibonacci scale exists, and how to run Planning Poker so it produces understanding rather than just numbers. Turning those points into a realistic plan is Velocity and Capacity. The rhythm that holds the whole thing together, refinement, planning, the Sprint Goal, review, retro, is in Sprint Planning and Refinement.
The most important operational note is Feedback and Scope Control, because absorbing feedback into work already in progress is the single biggest reason sprints overflow.
On the quality side, Test Case Strategy is about why features end up with no test cases and how to make that structurally impossible, Feature Inventory and Ownership is about why nobody remembers the corner cases of a feature built eight months ago, and SLI SLO and Error Budget is about measuring whether the product is actually healthy in production instead of guessing.
Building with AI covers what changes when most of the code is generated, which is the part none of the classic books were written for. Azure DevOps Setup is the practical mapping of all of this onto the tool: work item types, fields, tags, queries, test plans and dashboards.
Where this comes from
The backbone is the Scrum Guide 2020, Microsoft’s current Azure DevOps documentation on backlogs, capacity, velocity and test plans, the Agile Alliance practice definitions for INVEST and Definition of Ready, Mike Cohn’s User Stories Applied and Agile Estimating and Planning, Kenneth Rubin’s Essential Scrum, Google’s Site Reliability Workbook for SLIs, SLOs and error budgets, Matt Wynne’s Example Mapping, Gojko Adzic’s Specification by Example, and the DORA / Accelerate research on delivery performance.
Where a note says “my rule” or “the rule I want to live by”, that is my own opinion formed from watching this go wrong, not a quote from any of the above.