Hi, I tried to read it all, but when I had arrived to DoD I had to stop because it induces to bad practices, at least in the Agile realm.

The points that I found against Agile practices as defined by some of the Agile Manifesto creators are:

"* Unit tests must be written, and 80% of coverage must be accomplished.

* The code must be reviewed by at least two developers.

* Acceptance tests must be conducted by a tester."

The coverage cannot be a target to be mandated. Testing for testing is useless and leads to rigid tests that increases the amount of technical debt. It simply does not work. I explain it here: Confirmed: Code Coverage Is a Useless Management Metric. There I quote Martin Fowler.

You cannot trust code reviews. Often, when deadlines are tight, or the company cultural pushes to deliver as estimates mandate, developers feel that they are failing if they get picky on reviews. What means is that most of the reviews become just cosmetic changes. And of course, if pull requests are large, then the joke LGTM becomes a reality. Some numbers and statistics are here: Why Do Not Trust Pull Requests

Unit tests/Acceptance tests: seems that developers only test with unit tests, but not Agile unit tests, rather QA unit tests, in which the developer tests functions not functionalities. So, basically, there are Agile tests and QA tests. The typical pyramid of testing are QA tests, which were invented during waterfall development. But Agile only have "unit tests", but those unit tests are not about implementation details (like code, integration or e2e) rather defining unit as a behavior unit (yes, BDD was created to teach how to TDD properly, because people make this mistake). I got it explained here: QA-Unit Tests vs. Agile-Unit Tests

More about this last point, it looks like delivery is gated by a tester. No, it shouldn't. Ok, assume that acceptance tests must be conducted by a tester might be automatic, yet, that is not compatible with Continuous Delivery, probably the most successful —with lots of data in hand— flavor of Agile. In CD the developer commit must go from the repository to production in the shortest period possible without manual approval gates.

I do not know, this kind of DoD looks like the typical old current of thought that “only developers can fail when creating a product, but other roles are omniscient and infallible”. With experience, I have learned that it is far more important to have the right feature than having the feature right, or in other words: Useless Features Are The Biggest Bugs.

So, what I believe that it is the overall problem, that might be the article should have been: "How to Estimate a 'Big' User Story Accurately: You don't. You shouldn't make Big User Stories, that is a big expensive risk, try a different approach." And that is probably because Asking for Estimates is a Telltale Sign of Ineffective Software Development Practices