There is no such thing as design and implementation stories, User Stories should provide some level of end-to-end functionality to the user (i.e. delivering customer value).
The fact that you are mixing the terms stories and features doesn't help to communicate but what you're describing sounds actually like tasks (Sprint Backlog level), not user stories (Product Backlog level).
And if they are not tasks, then they are very bad stories. Maybe the "functionality" is too big and you should put the story on diet but what I see here is a typical story smell.
If you are new to User Stories, I strongly recommend to use the regular template (As a <type of user>, I want <some goal> so that <some reason>) and also to follow the INVEST model. This will really help you to avoid pitfalls like the one of your question.
Back to the real question (Am I doing waterfall?): there is nothing wrong with doing so design inside a Sprint (as a task of a story). But if your whole story is about design, you're not really doing Scrum, you are supposed to deliver a demonstrable end-to-end increment at the end of the Sprint.
Business value is a concept that describes the relative worth of any development effort to the business. Business value is often unquantifiable, but often relates to money.
You can think of business value as something that could still be sold if the project was stopped.
If you write a story to create: "a high level design of the feature", what you would produce by implementing that story isn't something that the business can sell. It's not something customers can try, buy, use. In effect, the business value of that story is zero.
You might have better luck thinking about stories "vertically". "Vertical slices" are minimal features that cover your entire technology stack. For example: "A user should be able to enter their name in a text box, click a button, and be shown their record in the database." It's not, by itself, especially useful, but it is more valuable than a feature design.
No, you're not. The sub tasks can be added to the backlog (presumably with roughly equal priority so they come out around the same time) and then the super-task would be to integrate/test/etc the separate components.
It sounds like a valid way to breakdown a large component to me. Just make sure you size up the different chunks appropriately. I've found 4-16 hour chunks work best. Giving 40 hours for a task means they'll do 2 hours of work until Friday when they cram the other 32 in (along with lots of bugs).
发布评论
评论（3）
不存在设计和实现故事，用户故事应向用户提供某种程度的端到端功能（即交付客户价值）。
事实上，您混合使用“故事”和“功能”这两个术语无助于沟通，但您所描述的内容听起来实际上像是任务（Sprint 待办事项级别），而不是用户故事（产品待办事项级别）。
如果它们不是任务，那么它们就是非常糟糕的故事。也许“功能”太大，你应该 让故事节食，但我在这里看到的是典型的故事味道。
如果您是用户故事的新手，我强烈建议您使用常规的 模板（作为一种<类型的用户>，我想要<某个目标>，以便<某种原因>）并遵循INVEST 模型。这确实可以帮助您避免像您的问题一样的陷阱。
回到真正的问题（我在做瀑布吗？）：在 Sprint 中进行这样的设计（作为故事的任务）没有任何问题。但如果你的整个故事都是关于设计的，那么你并没有真正进行 Scrum，你应该在 Sprint 结束时提供可证明的端到端增量。
There is no such thing as design and implementation stories, User Stories should provide some level of end-to-end functionality to the user (i.e. delivering customer value).
The fact that you are mixing the terms stories and features doesn't help to communicate but what you're describing sounds actually like tasks (Sprint Backlog level), not user stories (Product Backlog level).
And if they are not tasks, then they are very bad stories. Maybe the "functionality" is too big and you should put the story on diet but what I see here is a typical story smell.
If you are new to User Stories, I strongly recommend to use the regular template (As a <type of user>, I want <some goal> so that <some reason>) and also to follow the INVEST model. This will really help you to avoid pitfalls like the one of your question.
Back to the real question (Am I doing waterfall?): there is nothing wrong with doing so design inside a Sprint (as a task of a story). But if your whole story is about design, you're not really doing Scrum, you are supposed to deliver a demonstrable end-to-end increment at the end of the Sprint.
Scrum 故事往往是关于“商业价值” :
您可以将商业价值视为如果项目停止仍可以出售的东西。
如果您编写一个故事来创建：“功能的高级设计”，那么您通过实现该故事所产生的内容并不是企业可以出售的东西。它不是客户可以尝试、购买、使用的东西。事实上，这个故事的商业价值为零。
你可能会更幸运地“垂直”思考故事。 “垂直切片”是最基本的功能涵盖您的整个技术堆栈。例如：“用户应该能够在文本框中输入他们的姓名，单击按钮，然后在数据库中显示他们的记录。”它本身并不是特别有用，但它比功能设计更有价值。
Scrum stories tend to be about "business value":
You can think of business value as something that could still be sold if the project was stopped.
If you write a story to create: "a high level design of the feature", what you would produce by implementing that story isn't something that the business can sell. It's not something customers can try, buy, use. In effect, the business value of that story is zero.
You might have better luck thinking about stories "vertically". "Vertical slices" are minimal features that cover your entire technology stack. For example: "A user should be able to enter their name in a text box, click a button, and be shown their record in the database." It's not, by itself, especially useful, but it is more valuable than a feature design.
不，你不是。子任务可以添加到待办事项中（大概具有大致相同的优先级，因此它们大约在同一时间出现），然后超级任务将是集成/测试/等单独的组件。
对我来说，这听起来像是分解大型组件的有效方法。只要确保适当地调整不同块的大小即可。我发现 4-16 小时的组块效果最好。为一项任务分配 40 个小时意味着他们将完成 2 个小时的工作，直到周五他们才将另外 32 个小时塞进去（以及大量错误）。
No, you're not. The sub tasks can be added to the backlog (presumably with roughly equal priority so they come out around the same time) and then the super-task would be to integrate/test/etc the separate components.
It sounds like a valid way to breakdown a large component to me. Just make sure you size up the different chunks appropriately. I've found 4-16 hour chunks work best. Giving 40 hours for a task means they'll do 2 hours of work until Friday when they cram the other 32 in (along with lots of bugs).