Why this matters: everything in these notes is useless if it is announced as a new process on a Monday and abandoned by Thursday. Change one thing at a time, in an order where each step makes the next one possible. The reasoning behind the order is in Why We Miss Deadlines.
Rules for the rollout itself
One change at a time. A team can absorb roughly one new habit per two weeks. Introduce six at once and you get six half followed rituals and a team that concludes “process does not work here”, which then blocks the next attempt for a year.
Lead with the evidence, not the theory. Nobody wants a lecture on Scrum. Everybody is interested in “70% of our carry over last quarter was scope added mid sprint”. Get the number first.
Make the first change one that helps the developers immediately. Acceptance criteria are perfect for this, because the first time a demo does not turn into an argument, the team understands why they bothered.
Expect the resistance to come from outside the team. Developers rarely object to clearer requirements. The friction comes when somebody is told for the first time that their request is a new backlog item rather than an addition to today’s work.
Week 1: Get the evidence
Do not change any process yet. Open the board and answer four questions for the last three sprints:
- How many items carried over, and how many points?
- For each one, which cause was it? Use the six categories in Templates.
- How much work was added after each sprint started?
- How many Stories entered a sprint with an empty acceptance criteria field?
This takes about an hour. Present it as a plain table with no conclusions attached. The table does the arguing for you, because it moves the conversation from “the team is slow” to “here is what actually happened”, and those lead to completely different fixes.
If your board does not have enough history to answer these, that is itself the finding, and week 1 becomes “start tagging added-mid-sprint”, per Azure DevOps Setup.
Week 2: Acceptance criteria, and nothing else
Pick the next five Stories. Each one gets written Acceptance Criteria before anyone codes. Use the template. Spend twenty minutes per Story with a developer and a tester in the room.
Do not introduce points, poker, Definition of Ready, Definition of Done or anything else this week. Just this.
What success looks like: at the demo, somebody asks for something and the answer is “that is in the out of scope line, let us add it to the backlog”, and the conversation simply ends. That moment is what sells the rest of the change.
Week 3: Start classifying feedback
Now add one rule: every piece of feedback gets named out loud before it gets acted on. Print the triage card from Templates and keep it visible.
This is the week that actually fixes delivery, and it is the week with the most friction, because for the first time somebody says “that is new scope, it goes to the backlog”.
How to survive that conversation: never refuse the work, refuse doing it invisibly. The sentences that help are in Feedback and Scope Control. Keep the promise on the other side too, which means backlog items that people care about actually get scheduled. If the backlog is a graveyard, this whole approach collapses, because people will go back to bypassing it.
Week 4: Fix the decomposition
Take the current board and re cut it using Work Breakdown Hierarchy. Most items that look like tasks will turn out to be Features hiding four or five Stories.
Then take the single biggest item in the backlog and split it properly using the patterns in Writing User Stories. Do it together, on a whiteboard, as a workshop. Seeing one monster become six testable Stories teaches the skill better than any explanation.
This is usually the week the team realises why estimates never worked.
Month 2: Add the gates and start measuring
Write the two definitions. A first Definition of Ready and a first Definition of Done, seven items each, decided by the team in one session, not handed down. Put them on the board columns.
Start estimating Stories. Use Planning Poker on the next batch, and pick your reference Stories from work you have already finished, per Estimation and Story Points. Expect the first two sprints of numbers to be inconsistent. That is fine, calibration takes time.
Introduce the Sprint Goal. One sentence per sprint, written before selecting items, as described in Sprint Planning and Refinement.
Start the refinement session. One hour a week, working two sprints ahead. This is the habit most likely to be dropped when things get busy, and the one that costs the most when it is.
Do not use velocity to plan yet. Three sprints of data minimum, then start with Velocity and Capacity.
Month 3: Close the quality gap
Add test cases to Done. Once criteria are being written consistently, this is a small step, because the test cases nearly write themselves. Details in Test Case Strategy.
Start the one per sprint rule. Every sprint, one existing feature gets its behaviour written down and its critical path automated. Pick by risk, using your own bug history as the map.
Start the feature one pagers. Same feature, same sprint, using the template. Writing the behaviour and writing the test cases are nearly the same activity, so doing both together costs very little extra.
If you run something customers depend on, define two service level indicators and measure them for a month before setting any target, per SLI SLO and Error Budget.
Month 4 onward: keep it alive
By now the mechanics exist. The risk shifts from “we are not doing it” to “we are doing it as a ritual”.
Things that keep it real:
- One retro improvement per sprint, with an owner and a check next time. One that happens beats eight that get listed.
- Review the Definition of Done quarterly and strengthen it deliberately as the team matures. Never weaken it because a deadline is close.
- Watch the four numbers from Glossary on a dashboard. If they stop moving, ask why.
- Re examine the process when the team changes size. What works at five people needs adjustment at fifteen.
What to tell management
They do not care about Scrum. They care about predictability, and the honest pitch is:
“We are not going to get faster by trying harder. We are going to get predictable by defining work before we build it, and by making it visible every time scope is added after a sprint starts. Predictable means we can tell you a date and mean it. In exchange, we need one thing: when a new request arrives mid sprint, something else moves out. That trade will be explicit and it will be yours to decide.”
That last sentence is the deal. It gives them the control they actually want, which is choosing what matters most, and it removes the thing that is destroying delivery, which is choosing everything at once.
And a number to offer them, since they will want one: after three or four sprints, you should be able to quote a delivery range with the assumptions attached, using the forecasting arithmetic in Velocity and Capacity. That is what “reliable dates” actually looks like. Not one date, and not a promise, but a range you can defend and that turns out to be right.
What failure looks like, so you can catch it early
- Acceptance criteria are being written, but by one person alone, after the Story is already in development. Then they describe the code, not the requirement.
- Definition of Done exists on a wiki page and nobody has read it since the day it was written.
- Stories are being pointed, but the points get adjusted afterwards so velocity looks stable.
- Refinement is cancelled whenever the sprint is busy, which is always.
- Feedback is classified out loud, and then absorbed into the current Story anyway.
- Velocity has appeared in a management report as a performance measure. This one is fatal to the whole system, and it is worth pushing back on hard, for the reasons in Velocity and Capacity.
Any of these means the mechanics are being performed without the intent. That is worth naming in a retro, because a process that everybody quietly disbelieves is more corrosive than having no process at all.