A.F.S.T or your Average Feature Shipment Time in Software is more than just coding and testing and then git pushing on your remote branch.
It is all those things around it that make the idea of daily CI/CD difficult.
Splitting effectively is a bigger task than we give credit for, and it's not always done by very senior people, sometimes not engineers at all, and that's bad if you want to accurately estimate the odds.
What are the odds?
Real-world variables (Personal / family issues / Health issues or stress-related, those are as common as it gets, therefore it goes #1)
Department latency (Assume you need a minor thing from another department but you're not the centre of their universe, bizarre I know, but just stay with me until the end of this)
Technical issues (It can happen and it can waste maybe even a full day, that's the basis on which ALOT of tech like Docker & other online IDE platforms with readymade environment variables are based)
Vague product scopes / Logical fallacies (Self-explanatory while also the base of the real agile process and why we use it in most but not in all cases)
Operational Corporate Red Tape (The devil himself, it should be #1 but it hides in the shadows, maybe disguised as Scrum/SaFe/Kanban or your idea of mixing kanban with scrum.)
Introduction latency (It starts from a new tool to languages to new people in a team, everything new will need an adjustment/integration period, your manager doesn't think so, and that's why it might cost the team down the line.)
Unknown factors (It would be proper to add 5% of your time just in case, or your 8-hour workweek won't stay 8 hours for long)
I'm certain that many people claim to know how to conduct their business effectively but those odds above are no small thing, accidents, by definition miss intent, for when they happen they're not intentional by the one that is taking part or have complete ownership of the accidents, think of it like when your phone falls and breaks down and you have all those information in it, there is not a single chance that you expected for it to happen, and yet it was out of your power, and it happened, that's how most estimations work when you are unaware of multiple odds, that's why experience matters a lot, the definition of APM (Actions per minute) is essentially the same thing, the second time you take the test your results will be elevated by more than 35% in comparison to the first time because now you'd be more experienced on the process, Software estimation is also like that.
What APM lacks is the human factor of trying to play nice and overpromise, for that reason be a pessimist and humble yourself when it comes to your skills, let alone the team skills that you know nothing about or even worse, you think that you know.
So how do you calculate the A.F.S.T, some of the techniques are mentioned in my previous article about Chaos Estimation but the truth is, whatever works for you is good for the world, as long as it works, calculating those odds though is the thing that will make everything glue together, no matter of what your model looks like or how complicated your new project might be.