Don’t forget refinement where you describe your plan to add the “height: 80pt” rule (literally what the client wants), and then poker planning where you say it will be 1 point and the lead dev says 3 points and the other dev asks what is a point anyway leading to a time consuming discussion, and then the task gets scheduled for not next sprint but the sprint after, and then you do it and push your code, make a pull request, then during code review it is suggested you use tailwind instead but your project isn’t using tailwind because it’s some legacy PHP monster started by a junior who was just learning PHP, so now there’s a POC to consider using tailwind meanwhile the lead dev (who has a background in QA) designs a reusable “height engine” which uses rabbitmq to alert all worker nodes (there’s only one) about any changes to the height rules in mongodb. The height engine doesn’t include units so you have to hardcode if the client is expecting rem or pt. The product owner asks you in sprint review why this ended up taking a week when you said 1 point initially and the team agreed on 3. A team decision is made that all future CSS rule changes require a POC prior to implementation.

Oh, they did. But the guy doing actual work with the button was on the meetings about scrollbar

Those meetings come after you make the change where they tell you they actually expected the button would get smaller.