It's a smell when I see tasks created and associated with a PBI before Sprint Planning. I run into it constantly, usually from well-meaning teams who think they're getting a head start. They're not. They're manufacturing waste, and a particularly stubborn kind of it.
Here's the reasoning. In Scrum, Task work items represent the plan for developing the forecasted PBIs in the Sprint Backlog and achieving the Sprint Goal. Tasks decompose the plan for the current Sprint. That's their whole job. All the tasks for a PBI, together with that PBI, form part of the Sprint Backlog. So a task that exists before the PBI has even been forecast into a Sprint is a plan for work the team hasn't decided to do yet.
Why early tasks are waste
Maybe the Scrum Team already knows what the plan will be. But what if it changes? Conditions shift, the team learns something during refinement or in the prior Sprint, the PBI itself gets split or reordered. When that happens, every task you created early has to be revisited, reworked, or thrown away. The time spent creating and managing those tasks was wasted.
The worse problem is human, not mechanical. Once Developers have written down a plan, some of them get attached to it. Stubborn Developers may want to stick to their archaic plan even when conditions have changed, simply because the plan already exists in the tool and feels like progress. You've created false precision: a detailed-looking Sprint plan for a Sprint that hasn't started, anchoring people to decisions they should be making fresh, together, at Sprint Planning.
Tasks also pull attention to the "how" during a phase that should be about the "what" and the "why." A PBI on its journey to ready needs a clear title, value, acceptance criteria, and a size. It does not need a task breakdown. That breakdown is precisely the conversation Sprint Planning exists to have, with the whole team present and the Sprint Goal in view.
Surfacing the smell
You don't have to police this by hand. Create a shared query for new or approved PBIs that already have tasks. Those are the items where someone jumped the gun. Surface it on a dashboard, glance at it before Sprint Planning, and turn each hit into a quick learning conversation rather than a reprimand.
The rule is simple: don't create tasks until Sprint Planning, where those PBIs are forecast, or later in the Sprint as the plan emerges. Decompose the work you've actually decided to do, when you've decided to do it, with the people who'll do it.
Let the plan emerge when it's real. Sounds like good Scrum to me.