Yes and No. Scrum estimating is done with 2 independent metrics: Velocity and Task Hourly Estimate. Obviously adding something to the Spring is going to hide t

Yes and No. Scrum estimating is done with 2 independent metrics: Velocity and Task Hourly Estimate. Obviously adding something to the Spring is going to hide the fact that you fucked up at Spring Planning. However, as the author said, very few people actually care about task estimate. ( and often team don't even care about breaking stories into task at all, using story == task ) And in any case, unless you are using postits and manual tracking, any tool will just track the estimate alright for you, the information is there if you want to process it. Velocity is supposed to change from sprint to sprint, getting better as you are better at assigning story point. You can lose SP when you fuck up a story, you can gain extra when you put additional stuff from the backlog. Velocity once more or less stable is supposed to give an idea of a release date. However considering that you don't break down big stories and epic into smaller stories until you are about ready to implement them, the uncertainty on the release date is more like 6 months vs 2 years vs 10 years. Management make a big deal of it but really that's how you budget most of the time anyway: I need "3 FTE for 6 months or 3 FTE for the year, to be reevaluated at budget cycle per budget cycle". Most of OP problem actually started really when Scrum Master became a job. I remember something like 10 years ago being all exited how Jira could make very precise report of velocity and estimate and my very experimented coach looked at me as if she had seen the Demon. Scrum is about keeping a supertanker on track in a tempest and those amazing reports gives the illusion of a nimble sport car racing on a track.