Archive them for reference on future projects. They will be useful when you have to estimate story points. Often times, similar-sounding stories occur across projects.
Um - keep them and put them in the project file. CYA in all cases. You never know when a client will come back and ask you "why is this this way?", or "who decided that was how it was?". You can then pull out the user story and have backup.
Always keep everything like this until the warranty period has expired on your software... unless you want to be put in the position where you could be asked to "fix" something that was really a change for free.
Another vote for keeping them. I know it's a dirty word, but the user stories are part of your documentation, and serve an important purpose.
Three years from now when you (or the inheritor) are making changes to the system it's helpful to have the historic documents to know why you did things the way you did.
It also helps when the situation changes and you have to rewrite to be able to go back over the user stories that the application satisfies and determine whether or not those same stories apply to the new version.
I usually wrap each iterations worth of user stories (and tasks) in a rubber band and a new card in front stating the velocity and estimated points. I've never had any use for them though, except for nostalgic reasing. So keep them for the archive I'd say :-9
I write requirements (rather than code), but I frequently find myself rereading old user stories and acceptance tests (mine and others').
Reviewing old stories can help me find the clearest phrasing for complicated concepts, rather than reinventing the wheel. They sometimes serve as a useful reminder for details I might otherwise forget to document. Stories written by others help me come up to speed on features I wasn't involved in, and will probably be a good learning tool for new hires.
I could go on, but let me just put it this way: Which is more likely to cause greater problems -- keeping the stories and not needing them, or needing the stories and not having them?
Completed user stories are essentially the final specification for your project. If you started with a formal requirements document or specification, there are many lessons to be learned by comparing your completed user stories with that document. If you don't have an initial document, then your completed user stories document the functionality of your project. In either case, I think it's very valuable to hang on to them for future reference, whether in project post-mortems or when estimating and planning subsequent projects.
I find that we never know what's going to be useful in the future, so my recommendation is to tag them and file them. If you're using physical cards, scan them then do something as simple as adding a tag to the image file. Imagine looking at a tag cloud later to find common threads or to locate and re-use your content.
As with all things scrum, though, if it starts taking too much time, it's probably not worth your effort. Don't make it a crazy process, just quickly file it and forget it.
发布评论
评论（10）
将它们存档以供将来项目参考。 当您必须估计故事点时它们会很有用。 很多时候，听起来相似的故事会发生在不同的项目中。
Archive them for reference on future projects. They will be useful when you have to estimate story points. Often times, similar-sounding stories occur across projects.
嗯 - 保留它们并将它们放入项目文件中。 在所有情况下都是 CYA。 你永远不知道什么时候客户会回来问你“为什么会这样？”或者“谁决定事情就是这样的？”。 然后您可以提取用户故事并进行备份。
始终保留这样的所有内容，直到您的软件的保修期到期为止...除非您希望被要求“修复”实际上是免费更改的内容。
Um - keep them and put them in the project file. CYA in all cases. You never know when a client will come back and ask you "why is this this way?", or "who decided that was how it was?". You can then pull out the user story and have backup.
Always keep everything like this until the warranty period has expired on your software... unless you want to be put in the position where you could be asked to "fix" something that was really a change for free.
垃圾桶似乎是一个合适的地方。
The trash can seems like an appropriate place.
PEZ 几乎是正确的。 回收卡片而不是扔掉它们。 :)
保留它们确实没有意义。 如果您需要更改历史记录，可以从 SCM 和测试脚本中获取。
PEZ is almost right. Recycle the cards rather than trash them. :)
There really is no point in keeping them. If you need a history of changes you can get that from your SCM and test scripts.
又一票支持保留它们。 我知道这是一个肮脏的词，但用户故事是文档的一部分，并且具有重要的用途。
三年后，当您（或继承人）对系统进行更改时，历史文档有助于了解您为什么这样做。
当情况发生变化并且您必须重写才能回顾应用程序满足的用户故事并确定这些相同的故事是否适用于新版本时，它也会有所帮助。
Another vote for keeping them. I know it's a dirty word, but the user stories are part of your documentation, and serve an important purpose.
Three years from now when you (or the inheritor) are making changes to the system it's helpful to have the historic documents to know why you did things the way you did.
It also helps when the situation changes and you have to rewrite to be able to go back over the user stories that the application satisfies and determine whether or not those same stories apply to the new version.
我通常将每次迭代的用户故事（和任务）包裹在橡皮筋中，并在前面放一张新卡，说明速度和估计点。 不过，除了怀旧的放松之外，我从来没有用过它们。 因此，将它们保留为存档，我想说：-9
I usually wrap each iterations worth of user stories (and tasks) in a rubber band and a new card in front stating the velocity and estimated points. I've never had any use for them though, except for nostalgic reasing. So keep them for the archive I'd say :-9
坚持下去！
我编写需求（而不是代码），但我经常发现自己重读旧的用户故事和验收测试（我的和其他人的）。
回顾旧故事可以帮助我为复杂的概念找到最清晰的措辞，而不是重新发明轮子。 它们有时可以作为有用的提醒，提醒我可能忘记记录的细节。 其他人写的故事可以帮助我快速了解我没有参与的功能，并且可能对新员工来说是一个很好的学习工具。
我可以继续说下去，但让我这样说：
哪一个更有可能导致更大的问题——保留故事但不需要它们，还是需要故事但没有它们？
Hang on to them!
I write requirements (rather than code), but I frequently find myself rereading old user stories and acceptance tests (mine and others').
Reviewing old stories can help me find the clearest phrasing for complicated concepts, rather than reinventing the wheel. They sometimes serve as a useful reminder for details I might otherwise forget to document. Stories written by others help me come up to speed on features I wasn't involved in, and will probably be a good learning tool for new hires.
I could go on, but let me just put it this way:
Which is more likely to cause greater problems -- keeping the stories and not needing them, or needing the stories and not having them?
保留它们（存档），以便将来如果对某事发生争议或争论，您可以参考它，并可以掩盖自己。
Keep them (archive them) so that if there is a dispute or argument over something in the future, you have a reference to it, and can cover yourself.
完成的用户故事本质上是项目的最终规范。 如果您从正式的需求文档或规范开始，通过将已完成的用户故事与该文档进行比较，可以学到很多经验教训。 如果您没有初始文档，那么您完成的用户故事会记录项目的功能。 无论哪种情况，我认为无论是在项目事后分析还是在评估和规划后续项目时，保留它们以供将来参考都是非常有价值的。
Completed user stories are essentially the final specification for your project. If you started with a formal requirements document or specification, there are many lessons to be learned by comparing your completed user stories with that document. If you don't have an initial document, then your completed user stories document the functionality of your project. In either case, I think it's very valuable to hang on to them for future reference, whether in project post-mortems or when estimating and planning subsequent projects.
我发现我们永远不知道将来什么会有用，所以我的建议是标记它们并归档它们。 如果您使用的是实体卡，请扫描它们，然后执行一些简单的操作，例如向图像文件添加标签。 想象一下稍后查看标签云以查找共同线程或查找和重用您的内容。
不过，与所有 Scrum 事情一样，如果它开始花费太多时间，那么可能就不值得您付出努力。 不要让它成为一个疯狂的过程，只需快速归档并忘记它即可。
干杯，
里夫斯
I find that we never know what's going to be useful in the future, so my recommendation is to tag them and file them. If you're using physical cards, scan them then do something as simple as adding a tag to the image file. Imagine looking at a tag cloud later to find common threads or to locate and re-use your content.
As with all things scrum, though, if it starts taking too much time, it's probably not worth your effort. Don't make it a crazy process, just quickly file it and forget it.
Cheers,
Reeves