I do something similar to the OP when working on established systems. The trick is to treat everything that you can't break down to a triviality as an area of

I do something similar to the OP when working on established systems. The trick is to treat everything that you can't break down to a triviality as an area of research until you've solved that problem. So, say, you plan three days in a sprint to research a certain requirement, the results being a set of small east-to-estimate features and maybe more tricky features. If you're working in an area where your team have absolutely 0 experience then there's no way you can estimate anything accurately. In these cases I hope that you're working with a small team (2-3 developers and a BA/PO) who are highly experienced and work well together. Then you should run flexibly with features. Work Kanban style and implement the 80/20 effort/win features - and don't be scared to drop a feature if it's looking like it's not part of the 20% effort group of features.