IMO a backlog should not include developer stories. There is no way that any Product Owner can sensibly prioritise these alongside business functionality. And what happens if the Product Owner deems one of them unimportant and so pulls it out the backlog? If the team then insists on keeping the story, you are in a situation where ownership of the backlog becomes unclear.
However, I do definitely think that the team need to build architecture early on in the project. One problem on my project was that we focussed too heavily on functionality in the first few sprints.
Let's think about "architectural debt" (similar to technical debt) as time that needs to be spent building infrastructure and architecture. Unlike technical debt (which starts at zero and builds up as the team produces functionality without proper refactoring), a team starts with architectural debt and must work to reduce it. Time spent reducing architectural debt means that less time is spent producing functionality, i.e. a lower team velocity and reduced sprint output. In this way architectural debt is similar to technical debt. If requirements emerged that didn't fit the current architecture, then the level of architectural debt would increase.
Bear in mind, that the team should decide (and be able to justify to the Product Owner) how they are going to spend their time. And so they can split their effort between functionality, technical debt and architectural debt as they see fit.
Architecture work should still be driven by functionality though. In other words, the team should build infrastructure to support and enable a particular user story. Not just because they think it will be useful in the future. The YAGNI principle applies to that sort of approach.
There is a very challenging balance between doing architecture work and more feature specific work. Technically both are valid approaches and work, but the longer you delay some amount of usable product (sprint results) the larger the risk you take that you aren't building the right product (user requirements, performance requirements, ect.). As early as you can, get to a point where you can perform system level tests to prove your product works and you can demonstrate the value and direction of the product with your stake holders.
It is as simple as putting a Make sure the Membership component can be tested unplugged from all the other components 'user' story, your backlog SHOULD have system/development-stories, as long as it is sync'ed with the product owner's desire of such implementation.
This is how we usually put the non-functional requirements in a backlog, like "The domain model has to run on a different datacenter under load balancing" etc.
In our team we call it "IT-cards", which is cards of the form: "As a developer. I wan't to refactor the xyz-component. To reduce maintenance cost and increase flexibility."
Team members are free to pick any IT-card they deem important instead of popping a "Feature-card" from the prioritized backlog.
I find this approach to work reasonably well to keep technical debt at an acceptable level and allow a healthy pace of innovation.
I've found it somewhat lacking as a means of re-architecting the system though. It's hard to justify to long departures from the feature producing flow.
As I'm writing this I'm thinking that one could approach architecture by theming the stories. Identify the architectual goals with epics that you break down into a theme to focus on.
One lens that I find useful to take on developer stories is to think about who "the user" for any given story is. Just because you're not writing a feature that will be seen by people outside your company doesn't mean that there isn't a user for that piece of work. You may be writing code for a team down the hall. In some cases, the user is yourself. This is often the case for developer stories. Think "As a developer, I have a scalable architecture so that I can easily add new functionality." By calling out the particular user, it gives the product owner some insight into who will see the value of the story. And pointing out the "why" is also helpful to convey what benefit the story hopes to achieve. As others have mentioned, the management of the backlog does come down to a negotiation between the product owner and the team. And as always, you need to work out what works best for your team, regardless of process dogma. Every team has a different situation, and ideas that work well for one team don't always translate to another.
发布评论
评论（5）
IMO 积压工作不应包含开发者故事。任何产品负责人都无法明智地将这些与业务功能一起优先考虑。如果产品负责人认为其中一项不重要，因此将其从待办事项列表中删除，会发生什么情况？如果团队坚持保留故事，那么积压的所有权就会变得不清楚。
然而，我确实认为团队需要在项目的早期构建架构。我的项目的一个问题是我们在前几个冲刺中过于关注功能。
让我们将“架构债务”（类似于技术债务）视为需要花费在构建基础设施和架构上的时间。与技术债务（从零开始，随着团队在没有适当重构的情况下生产功能而逐渐增加）不同，团队从架构债务开始，并且必须努力减少它。减少架构债务所花费的时间意味着生产功能所花费的时间更少，即较低的团队速度和减少的冲刺输出。从这个角度来看，架构债务与技术债务类似。如果出现不适合当前架构的需求，那么架构债务水平就会增加。
请记住，团队应该决定（并能够向产品负责人证明）他们将如何度过他们的时间。因此，他们可以按照自己认为合适的方式在功能、技术债务和架构债务之间分配工作。
尽管如此，架构工作仍然应该由功能驱动。换句话说，团队应该构建基础设施来支持和启用特定的用户故事。不仅仅是因为他们认为这在未来会有用。 YAGNI 原则适用于这种方法。
IMO a backlog should not include developer stories. There is no way that any Product Owner can sensibly prioritise these alongside business functionality. And what happens if the Product Owner deems one of them unimportant and so pulls it out the backlog? If the team then insists on keeping the story, you are in a situation where ownership of the backlog becomes unclear.
However, I do definitely think that the team need to build architecture early on in the project. One problem on my project was that we focussed too heavily on functionality in the first few sprints.
Let's think about "architectural debt" (similar to technical debt) as time that needs to be spent building infrastructure and architecture. Unlike technical debt (which starts at zero and builds up as the team produces functionality without proper refactoring), a team starts with architectural debt and must work to reduce it. Time spent reducing architectural debt means that less time is spent producing functionality, i.e. a lower team velocity and reduced sprint output. In this way architectural debt is similar to technical debt. If requirements emerged that didn't fit the current architecture, then the level of architectural debt would increase.
Bear in mind, that the team should decide (and be able to justify to the Product Owner) how they are going to spend their time. And so they can split their effort between functionality, technical debt and architectural debt as they see fit.
Architecture work should still be driven by functionality though. In other words, the team should build infrastructure to support and enable a particular user story. Not just because they think it will be useful in the future. The YAGNI principle applies to that sort of approach.
我的答案此处适用。
在进行架构工作和更多特定功能的工作之间存在非常具有挑战性的平衡。从技术上讲，两者都是有效的方法和工作，但是延迟一定数量的可用产品（冲刺结果）的时间越长，您所承担的未构建正确产品（用户需求、性能需求等）的风险就越大。尽早进行系统级测试以证明您的产品有效，并且可以向利益相关者展示产品的价值和方向。
My answer here applies.
There is a very challenging balance between doing architecture work and more feature specific work. Technically both are valid approaches and work, but the longer you delay some amount of usable product (sprint results) the larger the risk you take that you aren't building the right product (user requirements, performance requirements, ect.). As early as you can, get to a point where you can perform system level tests to prove your product works and you can demonstrate the value and direction of the product with your stake holders.
就像放置一个确保会员组件可以在与所有其他组件拔出的情况下进行测试一样简单“用户”故事，您的积压工作应该有系统/开发故事，只要它是同步的”与产品负责人对这种实施的愿望相一致。
这就是我们通常将非功能性需求放入待办事项中的方式，例如“域模型必须在负载平衡下在不同的数据中心上运行”等。
It is as simple as putting a Make sure the Membership component can be tested unplugged from all the other components 'user' story, your backlog SHOULD have system/development-stories, as long as it is sync'ed with the product owner's desire of such implementation.
This is how we usually put the non-functional requirements in a backlog, like "The domain model has to run on a different datacenter under load balancing" etc.
在我们的团队中，我们将其称为“IT 卡”，其形式如下：“作为开发人员。我不想重构 xyz 组件。以降低维护成本并提高灵活性。”
团队成员可以自由选择他们认为重要的任何 IT 卡，而不是从优先待办事项中弹出“功能卡”。
我发现这种方法相当有效，可以将技术债务保持在可接受的水平，并允许健康的创新步伐。
但我发现它作为重新架构系统的手段有些缺乏。很难证明长期偏离功能制作流程是合理的。
当我写这篇文章时，我在想人们可以通过故事主题来研究建筑。通过将史诗分解为要关注的主题来确定架构目标。
In our team we call it "IT-cards", which is cards of the form: "As a developer. I wan't to refactor the xyz-component. To reduce maintenance cost and increase flexibility."
Team members are free to pick any IT-card they deem important instead of popping a "Feature-card" from the prioritized backlog.
I find this approach to work reasonably well to keep technical debt at an acceptable level and allow a healthy pace of innovation.
I've found it somewhat lacking as a means of re-architecting the system though. It's hard to justify to long departures from the feature producing flow.
As I'm writing this I'm thinking that one could approach architecture by theming the stories. Identify the architectual goals with epics that you break down into a theme to focus on.
我发现对开发者故事有用的一个视角是思考任何给定故事的“用户”是谁。仅仅因为您编写的功能不会被公司外部的人看到，并不意味着该工作没有用户。您可能正在为大厅里的一个团队编写代码。在某些情况下，用户就是你自己。开发者故事中经常出现这种情况。想想“作为一名开发人员，我拥有一个可扩展的架构，这样我就可以轻松添加新功能。”通过召集特定用户，产品所有者可以深入了解谁会看到故事的价值。指出“为什么”也有助于传达故事希望达到的好处。正如其他人所提到的，积压的管理确实取决于产品所有者和团队之间的谈判。与往常一样，您需要找出最适合您的团队的方法，无论流程教条如何。每个团队都有不同的情况，对一个团队有效的想法并不总是适用于另一个团队。
One lens that I find useful to take on developer stories is to think about who "the user" for any given story is. Just because you're not writing a feature that will be seen by people outside your company doesn't mean that there isn't a user for that piece of work. You may be writing code for a team down the hall. In some cases, the user is yourself. This is often the case for developer stories. Think "As a developer, I have a scalable architecture so that I can easily add new functionality." By calling out the particular user, it gives the product owner some insight into who will see the value of the story. And pointing out the "why" is also helpful to convey what benefit the story hopes to achieve. As others have mentioned, the management of the backlog does come down to a negotiation between the product owner and the team. And as always, you need to work out what works best for your team, regardless of process dogma. Every team has a different situation, and ideas that work well for one team don't always translate to another.