How did this approach deal with difficult technical/algorithmic problems where someone needs to investigate something before further decisions can be made? Exa

How did this approach deal with difficult technical/algorithmic problems where someone needs to investigate something before further decisions can be made? Example: You want to improve performance. Somebody will have to fire up a profiler and measure things, and then figure out which hotspots are worth optimizing. I totally get breaking it down to "set up profiling tool", "do profiling runs for workflow X/Y/Z", and "identify low-hanging fruit". Presumably these tasks are not going to take the entire sprint. How do you plan the next step in task format? Do you not do any further work on the topic until the next sprint, where you then plan out concrete "optimize function X" tasks? If not, i.e. whoever does profiling also gets to optimize code during the same sprint, how do you account for that in planning? Three dummy tasks "optimize a hotspot" without any actual idea what it will involve? Maybe it requires rewriting a component to use different data structures? Maybe it's just a single JVM config tweak? "Could be a 1 or it could take my whole life?" Maybe it's just less common in certain domains, but this kind of "we need to investigate this issue and then decide what changes to make based on the investigation (and good engineering judgement)" - which is bread and butter in my part of the org - does not seem to fit into the "tasks with points" concept at all. Well, unless you want to always spread the process of "investigate issue", "identify problem and solution(s)" and "implement solution" over a whole month. That seems soul-crushing to me. To be clear, I'm very interested in seeing how to make this mesh with Agile. But it feels like trying to write a binary search in a language that has no indirection or conditionals.