It’s the little things.
Those are the hardest to say “NO” to – a little UI change here, or an additional spec to add in a data import function.
I had my first-hand experiences recently. First was me asking the senior product manager about making one or two UI changes with the release, even though the tickets had been locked in after our prioritisation meeting. She was experienced enough to say “NO” and explain why.
The second was with the devs, who suggested some small additions as well. It was a struggle for me, but eventually I said “NO”. If you let a small one in, what’s to say you won’t let another, and another one in? 100 percent of the time is easier than 98 percent of the time (hugely recommended reading by Clayton Christensen). Keep the scope for each sprint as fixed as possible, unless it’s a super-important change or prevents double-work – everything else goes to the next sprint. Otherwise, you give scope creep a foot through the door, and your sprints become marathons instead.