Answers:
Scrum并不要求使用用户故事。它们只是一种有用的敏捷实践。尽管产品负责人当然可以使用技术规范而不是用户故事来构建产品待办事项列表，但您的其他大多数流程问题都源自未能接受有效的Scrum和敏捷实践。
您的Scrum似乎以多种方式被破坏，包括：
尽管Scrum 并非总是适合每个项目，但在这种情况下，说Scrum不能正常工作是更准确的，因为团队实际上并未在做Scrum。您关于用户故事的问题只是团队所面临的较大流程问题的一小部分。
技术规范从根本上打破了传达要求的方式。从观点来看，不受限制的需求不会为开发人员提供任何有用的指导。使用您发布的示例：
从开发人员的角度来看，无法回答此类问题会导致您所描述的确切类型的过程问题。这就是用户故事的用途：它们提供了急需的上下文，并充当占位符，用于与利益相关者或最终用户就特定功能进行其他对话。
您不应该使用用户故事，因为您认为这是框架要求，或者是广泛接受的敏捷实践。相反，您应该有效地创建和使用它们，因为它使编程任务变得更容易，并使编程职业变得更加有趣。当然，您的里程可能会有所不同。
我不认为这里的问题就是Scrum这样的问题，我认为问题在于没有明确定义的项目可交付成果，并且（我已经经历了很多次）没有明确的方向。
我认为您的技术任务很好，可能在很大的方面，但是可测量和可定义的，因此对于故事来说绝对合适。
在Scrum中，研究任务对我来说是一个巨大的危险信号，因为它们几乎没有带来明显的收益，并且会造成巨大的范围爬行。我主张在冲刺中限制这些前期准备，不应添加它们，当然也不应以承诺的目标为代价添加它们。如果需要他们完成约定的sprint任务，则在计划时应该已经明确依赖关系（否则，他们估计了什么？）。
以我的经验，具有很多“调查峰值”的项目可以掩盖开发人员的实际工作，他们实际上并没有做很多事情，他们想要花时间去寻找新的闪亮事物而不是创造业务价值。我并不是说您的团队正在这样做，但是一个项目需要明确的目标，如果开发人员被赋予了“研究”的自由，那么他们会做并继续这样做，只要您允许。
Scrum说，您最好为客户提供可交付的产品。但是，这里的要点是，它没有指定可交付产品和客户。
换句话说，在您的特定情况下，您可以将可交付产品定义为代码改进，平台更改，重写和重新设计等，然后将技术经理视为您的客户。
这对我来说是100％合理的。您创建了一个积压案，该积压案告诉您产品用户的故事，用户是谁？技术经理。因此，像这样的项目：
您交付给客户（技术经理）的是一个日志系统。
但是，关于您谈论的R＆D任务，我建议您阅读有关Scrum 高峰的信息。它们本质上是带时间限制的微型任务，可帮助您确定执行较大的陌生任务所需的时间。
作为Scrum Master，由于工作性质，您可能需要考虑较长的sprint。这将为您提供更多用于“研究”任务的缓冲区。但是，我认为您需要确保任务在代码中产生某种工作产品/概念证明。您希望程序员做什么？要求他们采取一些措施，并使用这些信息来确定A：是否达到了我们想要的效果B：使其表现更好C：需要多长时间才能达到最新速度并开始知道将需要多长时间拿东西来做。
如果发现对当前重写的了解不多，则可以缩短冲刺周期。进行过程中，不要害怕调整它们。这就是敏捷。研究完成后，您可能还决定采用新技术。这可能是缩短冲刺的另一个原因，以便在无法控制之前。您可能会在sprint的中间发现新的东西行不通。停止冲刺并使用旧技术进行调整。毕竟，您的开发人员应该能够比较和对比新旧方法。
您在兼顾开发人员的需求，在这种情况下，需要重写应用程序。我猜想有些产品负责人希望这个项目早日完成，而不是长期接受“研究”的要求。