To answer your question, yes: it is possible to provide relative estimates without tracking time. Estimates should provide context into the amount of effort that goes into a work item, not the amount of time it'll take to perform the work. Remember, these estimates are effort forecasts, not commitments. The team should use the acceptance criteria and goal for each piece of work to estimate the amount of effort will go into the work. This can be done a number of ways, but most teams use a point system or T-shirt sizing method to provide relative context across various items.
Estimating based on effort has two main artifacts:
First, it allows a development team and its product owner to make longer term forecasts about how much can be delivered by a certain date. It allows teams to answers questions regarding how much can be expected to be delivered by a certain date and at what point in time will the product see 'x' amount of work completed.
Second, it aides product owners in prioritizing work. Priorities should be set based on the expected benefits and opportunity costs of the estimated work items relative to one another. If there is a quick, value add win that has a low estimated effort, that may take precedence over a piece of high-effort work that does not provide as much value. Knowing relative-sizing is critical in prioritizing value before development work even begins.
That said, in the event you want to begin using time as a means to provide transparency, I recommend reading the Kanban Guide for Scrum Teams to glean some ideas. This guide will show you reasons to use things like cycle times, work item age, throughput, SLEs, and WIP limits to provide hyperfocus into how to inspect and adapt your development practices as you move through a project. I've found these metrics also help with the estimating portion of our work as it provides empirical context into past estimates.