对我来说，非技术 PO 不应该查看诸如“升级服务器”之类的故事。这不是一个商业故事，最终用户看不到它，因此如果以这种方式制定，就很难确定优先级。应根据工作的业务价值分配优先级。 “升级”并没有多大意义。 “允许更多的同时连接”、“减少停机时间”甚至“提高团队速度”可能为非技术人员提供更有价值的见解。如果您找不到非技术描述，请自问有关升级必要性的问题:)
Usually in the 'vanilla' SCRUM the technical tasks you mentioned will not go as separate stories.
To me the non-technical PO should not be looking at the stories like 'Upgrade the server'. It's not a business story, it is not visible to the end-user so it is difficult to prioritize if it is formulated this way. Priorities should be assigned according to the business value of the work. 'Upgrading' does not mean much. 'Allowing more simultaneous connections', 'Reducing the downtime' or even 'improving the team velocity' might provide much more valuable insight to a non-technical person. If you cannot find a non-technical description ask yourself a question about the necessity of the upgrade :)
The 'refactoring' story is even more complicated. Did you ask yourself why is it a story at all? Refactoring could be done as a task in the story but it is rarely a story on itself. So if you want to make login work better or provide more features that's a story but tinkering under the hood does not count as one. Please also note that refactoring without a business purpose could easily lead to a so-called 'gold plating'
I would suggest doing the 'upgrade' stories as a spike with the 'improve performance' and 're-factor' being the tasks for a relevant business story.
I agree with the view of looking at the business benefit of any technical story and tracking it on the main product backlog
I do think that there are internal stories related to the velocity/capability of the team, which are sometimes more conveniently managed by assigning some capacity to the developers, especially when the Product Owner is not interested to prioritize or manage those stories.
E.g. assign 10% capacity to test automation backlog (of legacy regression), CI server setup, etc.
Yes, everything can certainly be expressed in business terms, but some of it should be considered "the way we need to do our job" where there is trust between Product Owner and team that the team will make best use of the capacity assigned for this.
I have had success with the dual backlog approach:
Product backlog is owned by the product owner. It contains story-level items (features) that get estimated by the team and then prioritized by the product owner. This estimation process splits the stories in smaller tasks.
Team backlog is owned by the development team. It contains task-level items that are relatively small (can be completed within a sprint). They can be linked to stories for example as impediments: to complete the story, the following technical tasks have to be completed first. They can also be independent so that they are not required for any story per se but they pay back some technical debt to enable higher velocity in the future.
(On some large, multi-project programs I've also had program backlogs that contain epic-level items, owned and prioritized by a program management team, to be split to stories into product backlogs further on.)
发布评论
评论（3）
通常，在“普通”SCRUM 中，您提到的技术任务不会作为单独的故事进行。
对我来说，非技术 PO 不应该查看诸如“升级服务器”之类的故事。这不是一个商业故事，最终用户看不到它，因此如果以这种方式制定，就很难确定优先级。应根据工作的业务价值分配优先级。 “升级”并没有多大意义。 “允许更多的同时连接”、“减少停机时间”甚至“提高团队速度”可能为非技术人员提供更有价值的见解。如果您找不到非技术描述，请自问有关升级必要性的问题:)
“重构”的故事甚至更加复杂。你有没有问过自己，为什么这是一个故事？重构可以作为故事中的一项任务来完成，但它本身很少是一个故事。因此，如果您想让登录工作得更好或提供更多功能，那是一个故事，但在幕后修修补补并不算一个故事。另请注意，没有商业目的的重构很容易导致所谓的“镀金”，
我建议将“升级”故事作为一个尖峰，将“提高性能”和“重构”作为任务相关商业故事。
PS 您可能会在 Mike Cohn 撰写的名为“应用的用户故事：用于敏捷软件开发”。
Usually in the 'vanilla' SCRUM the technical tasks you mentioned will not go as separate stories.
To me the non-technical PO should not be looking at the stories like 'Upgrade the server'. It's not a business story, it is not visible to the end-user so it is difficult to prioritize if it is formulated this way. Priorities should be assigned according to the business value of the work. 'Upgrading' does not mean much. 'Allowing more simultaneous connections', 'Reducing the downtime' or even 'improving the team velocity' might provide much more valuable insight to a non-technical person. If you cannot find a non-technical description ask yourself a question about the necessity of the upgrade :)
The 'refactoring' story is even more complicated. Did you ask yourself why is it a story at all? Refactoring could be done as a task in the story but it is rarely a story on itself. So if you want to make login work better or provide more features that's a story but tinkering under the hood does not count as one. Please also note that refactoring without a business purpose could easily lead to a so-called 'gold plating'
I would suggest doing the 'upgrade' stories as a spike with the 'improve performance' and 're-factor' being the tasks for a relevant business story.
P.S. You might find a good discussion on this topic (mostly in part 3 of it) in the excellent book by Mike Cohn called "User Stories Applied: For Agile Software Development".
我同意查看任何技术故事的商业利益并在主要产品积压中跟踪它的观点，
我确实认为存在与团队的速度/能力相关的内部故事，有时通过分配一些内容可以更方便地管理这些故事开发人员的能力，特别是当产品负责人不感兴趣优先考虑或管理这些故事时。
例如，分配 10% 的容量来测试自动化积压（遗留回归）、CI 服务器设置等。
是的，一切当然都可以用业务术语来表达，但其中一些应该被视为“我们需要完成工作的方式”，其中产品负责人和团队之间存在信任，团队将充分利用为此分配的能力。
I agree with the view of looking at the business benefit of any technical story and tracking it on the main product backlog
I do think that there are internal stories related to the velocity/capability of the team, which are sometimes more conveniently managed by assigning some capacity to the developers, especially when the Product Owner is not interested to prioritize or manage those stories.
E.g. assign 10% capacity to test automation backlog (of legacy regression), CI server setup, etc.
Yes, everything can certainly be expressed in business terms, but some of it should be considered "the way we need to do our job" where there is trust between Product Owner and team that the team will make best use of the capacity assigned for this.
我通过双重待办事项方法取得了成功：
产品待办事项归产品负责人所有。它包含故事级别的项目（功能），由团队评估，然后由产品负责人确定优先级。此估算过程将故事拆分为更小的任务。
团队积压工作归开发团队所有。它包含相对较小的任务级项目（可以在一个冲刺内完成）。它们可以与故事相关联，例如作为障碍：要完成故事，必须首先完成以下技术任务。它们也可以是独立的，这样任何故事本身都不需要它们，但它们可以偿还一些技术债务，以在未来实现更高的速度。
（在一些大型的多项目计划中，我还拥有包含史诗级项目的计划待办事项，由项目管理团队拥有并确定优先级，以便进一步将故事拆分为产品待办事项。）
I have had success with the dual backlog approach:
Product backlog is owned by the product owner. It contains story-level items (features) that get estimated by the team and then prioritized by the product owner. This estimation process splits the stories in smaller tasks.
Team backlog is owned by the development team. It contains task-level items that are relatively small (can be completed within a sprint). They can be linked to stories for example as impediments: to complete the story, the following technical tasks have to be completed first. They can also be independent so that they are not required for any story per se but they pay back some technical debt to enable higher velocity in the future.
(On some large, multi-project programs I've also had program backlogs that contain epic-level items, owned and prioritized by a program management team, to be split to stories into product backlogs further on.)