Here is what we do, and it may or may not work in your circumstances.
Depending on the size of a project we break it down into one or more features. A feature is a piece of functionality that can be shipped in isolation without dependency on other features that may be worked on or that may be planned for the future.
For each feature we break down the steps into what we call "stories". There is a lot to say about stories so for simplicity reasons let me define them as a piece of functionality that is required to deliver the feature. However a single story often cannot be shipped in isolation. Some stories may be "technical stories" which are not even visible to the end user, e.g. "Refactor/extend the upgrade process".
Once we have all stories for each feature we then estimate the stories. We use story points but you can use other metrics, e.g. NUTS (nebulous units of time), brownie points, gummy bears, or - if you must - hours of effort.
To track progress we then limit the work-in-progress (WIP). We don't want a team member to work on a dozen things in parallel. Instead we want them to focus on as few as possible and complete them faster. We track progress by counting the stories that are complete and the stories that are not yet complete. "Complete" needs to be defined. We mean by this that no further work is required by anybody in our team other than shipping the software. Also we focus on as few features at a time as possible. We believe it is better to have 3 features complete and shipped rather than having 10 features half-way complete.
As mentioned at the beginning of my answer: You may have other factors that are at work in your circumstances so a different approach may work better. However, for us this approach has allowed us to plan and track our progress in such a way that we have shipped more than 95% or our about 300 releases in the last three years on time. We have received very positive feedback from our customers on this.