It sounds to me that its not so much that you don't know what the next task is but that you don't understand how to achieve the task. ie. It requires investigation.
So the story/task is "Make the program run in under 3 seconds". You know that you have some slow SQL in there, which you have a good idea about how you might improve it. But you don't know if the improvement will bring the time down to under 3 sec. If not, you'll have to do more, unknown, things.
In this case it's better to say that the task as a whole requires investigation, or a "spike" to see if you can find a solution which will achieve the goals.
In this case the spike is probably just screwing with the code until you get the time down. But then at least you have a solution, and you can potentially roll it out to multiple programs.
Say for example you found that reversing the polarity on the main deflector makes all sql run 30% faster and takes 20min per database. Now you can line up a bunch of well estimated tasks, even if the first one was essentially unestimatable.
More usually a spike will be "see if upgrading the db to mssql2020 makes it run faster" or something. So you are working in a dev env and will still have 'real' tasks to do even after the spike is complete.