Uncle Bob C. Martin: Clean Agile, Back to Basics 

As Uncle Bob says, agile is about producing data so you know how fast you're going. If you stop producing meaningful data you stop doing agile. So given that your requirements changed, so too must your estimates. Whatever the ripple effect is, re-estimating and even trashing and creating new stories ensures you continue to produce meaningful data necessary to continue to predict your completion date. If a foundational or re-specing happens frequently then that would be something to remedy for sure. Honestly this happens to all of us though, but we try to mitigate it best we can. I don't have any tips other than to confer with stakeholders frequently (i.e. the exploration is always happening from new learnings).

I don't recommend doing things this way, I would suggest looking into #NoEstimates. But to answer your question as best I can the way Bob would: You should be re-estimating the story points for features regularly, as well as changing the features themselves regularly as you get more data: removing ones that aren't relevant anymore, adding new ones that will be needed, splitting features apart, re-estimating because your architecture changed, etc. You can re-estimate completed features as well: if you called something a 5 but then once you started it you realized it was really a 2, then you should go back into the spreadsheet and adjust it to a 2. You typically do this after the first few iterations by choosing "yardstick features" and comparing future features against them. "This seems like the work involved will be very similar to that feature we did in March, and that was a 3, so let's call this a 3." If you aren't re-estimating and changing your feature backlog in response to what's happening during genuine iterations, then your backlog is just a roundabout way of doing water-scrum-fall. All that being said, again, look into #NoEstimates. Contrary to what Bob said, #NoEstimates is a absolutely an agile way of working. Indeed it is much more agile than the version Bob is proposing here, and it is also better aligned to data. Estimates as Bob describes here are not data, they are proven by research to be total bullshit, whatever nice personal feelings of confirmation-bias Bob has about them. You can start moving towards #NoEstimates by changing your range of available story points to "1" and "too fucking big, split it up", and the research shows that the numbers you'll get that way in terms of burndown will be more accurate than any other pointing (Fibonacci, T-shirts, etc).

These are boomers who grew up in the "glory" days of waterfall. Fuck them. Follow Uncle Bob, he's one of us.

If he's pushing it then he has a good reason. And he always says that TDD is a discipline, so not something you only use when You think the code is complicated. Because you don't write the tests only for yourself, but for the whole team and posterity. What if the originally simple class gets more complicated over time and there are no tests to cover for changes? What if the originally simple stuff is not that simple as you thought? And what if you and the whole team knows that the tests are covering only some (few) parts of the app? Then if they pass, it doesn't mean much, does it? Since your code might be broken elsewhere. Yes, some people can write clean, working code without tests, but once they leave and somebody younger replaces them, they will go through hell doing changes on that system.

I would recommend checking out one of the cleancoders case studies if you want to see what he's talking about in TDD in practice. London vs Chicago is probably the best to see 2 approaches of the discipline for the same project. Sandro Mancuso from codurance says in the first video that "there's what i teach and what i do". The principles are to give you the foundation, but experience informs your approach, without sacrificing the core idea of having a robust set of tests at the end. There is a lot of wiggle room to adjust your goals of good vs fast vs cheap vs done.

@Liviu SANDULACHE I asked him on the matter. He said that startups for example (epitome of rapid change) are the best place to adopt Clean Architecture. That includes testing!

There is a really fun talk from Kevlin Henney (I think it's called the error of our ways) where he shows the problem with leftpad (some js library that broke the internet). I'd suggest having a look at it and maybe consider that it's not size that matters. Perhaps how your code is used matters more!

If all we had to build was simple "str8" to the point components, none of us would have jobs.