A very good place to start as far as books are concerned is User Stories Applied and Agile Estimation and Planning both by Mike Cohn. This have excellent examples and good starting points for anyone first coming to agile methodologies.
As far as website resources they are few and far between. Probably a good place to actually start would be searching for those keywords on Google Images as many people take photos of their burndown charts and User Stories. This helped me a lot when starting. Here are some samples: Burndown Chart, and User Stories
Please note however while a burndown chart is a simple report that you run on your current story points left in an iteration, User stories are more complex than that and do require a bit of reading to wrap your head around. Start with User Stories Applied book for that.
I think for both of these questions, you can do a lot worse than scan over Alistair Cockburn's web site. In particular, he has a great article about burndown charts and some different ways to generate them:
(thoug I echo the earlier poster's recommendation of Mike Cohn's work).
One of the tricks is deciding what kind of documentation is good for YOUR project. Do you have many developers, spread over time and space? You will need bigger, heavier, more detailed stories. Do you have one or two devs working in the same place? You can get away with lighter ones. Has the team worked in the system (if it's legacy) for a long time? Light stories will probably do. Is the team new to the system, or are its business requirements complex? This pushes you in the more-detail direction.
If you're on a "small" project by any of the dozen definitions of small, you may be fine with very light stories. Here's an example, again from Cockburn's site:
A few months ago, we started writing the user documentation at the same time as we are developing features. A technical writer is assigned to each Scrum teams.
Having to write the user documentation while developing helps validating the design. The technical writer also participate in the design of the application.
This is in addition of release burndown and sprint burndown.
Additional documentation is created by the team when they feel it is useful to communicate with the product owner. This became less important as we are learning to write better user stories.
Consider reading Ambler's "Agile Modeling". He makes a very strong case as to why just creating tons of full UMLs is a fairly bad idea, and gives some good examples.
发布评论
评论（4）
就书籍而言，一个非常好的起点是应用的用户故事和敏捷估算和规划均由 Mike Cohn 撰写。 对于任何第一次接触敏捷方法论的人来说，这都有很好的例子和良好的起点。
就网站资源而言，它们少之又少。 实际开始的一个好地方可能是在谷歌图片上搜索这些关键词，因为很多人都会拍摄燃尽图和用户故事的照片。 这对我刚开始的时候帮助很大。 以下是一些示例：燃尽图和用户故事
但请注意，虽然燃尽图是您在当前故事点上运行的简单报告在迭代中，用户故事比这更复杂，并且确实需要一些阅读才能理解。 从用户故事应用书开始。
希望有帮助！
A very good place to start as far as books are concerned is User Stories Applied and Agile Estimation and Planning both by Mike Cohn. This have excellent examples and good starting points for anyone first coming to agile methodologies.
As far as website resources they are few and far between. Probably a good place to actually start would be searching for those keywords on Google Images as many people take photos of their burndown charts and User Stories. This helped me a lot when starting. Here are some samples: Burndown Chart, and User Stories
Please note however while a burndown chart is a simple report that you run on your current story points left in an iteration, User stories are more complex than that and do require a bit of reading to wrap your head around. Start with User Stories Applied book for that.
Hope that helps!
我认为对于这两个问题，你可以做得比浏览 Alistair Cockburn 的网站更糟糕。 特别是，他有一篇关于燃尽图以及生成燃尽图的一些不同方法的精彩文章：
http://alistair.cockburn.us/Earned-value+and+burn+charts
（尽管我赞同早期发帖者对 Mike Cohn 作品的推荐）。
技巧之一是确定哪种文档适合您的项目。 您是否有许多开发人员，分布在不同的时间和空间？ 你需要更大、更重、更详细的故事。 您是否有一两个开发人员在同一个地方工作？ 你可以选择较轻的。 团队是否在该系统（如果是遗留系统）中工作了很长时间？ 轻松的故事可能就可以了。 团队是系统新手，还是业务需求复杂？ 这会将您推向更详细的方向。
如果你正在进行一个“小”项目，按照十几种“小”的定义中的任何一个，你可能会喜欢非常轻松的故事。 这里有一个例子，同样来自 Cockburn 的网站：
http://alistair.cockburn .us/Examples+of+ultra-light+use+cases
I think for both of these questions, you can do a lot worse than scan over Alistair Cockburn's web site. In particular, he has a great article about burndown charts and some different ways to generate them:
http://alistair.cockburn.us/Earned-value+and+burn+charts
(thoug I echo the earlier poster's recommendation of Mike Cohn's work).
One of the tricks is deciding what kind of documentation is good for YOUR project. Do you have many developers, spread over time and space? You will need bigger, heavier, more detailed stories. Do you have one or two devs working in the same place? You can get away with lighter ones. Has the team worked in the system (if it's legacy) for a long time? Light stories will probably do. Is the team new to the system, or are its business requirements complex? This pushes you in the more-detail direction.
If you're on a "small" project by any of the dozen definitions of small, you may be fine with very light stories. Here's an example, again from Cockburn's site:
http://alistair.cockburn.us/Examples+of+ultra-light+use+cases
几个月前，我们在开发功能的同时开始编写用户文档。 每个 Scrum 团队都分配了一名技术作家。
开发时必须编写用户文档有助于验证设计。 技术作家也参与应用程序的设计。
这是发布燃尽图和冲刺燃尽图的补充。
当团队认为与产品所有者沟通有用时，他们会创建额外的文档。 当我们学习编写更好的用户故事时，这一点变得不那么重要了。
A few months ago, we started writing the user documentation at the same time as we are developing features. A technical writer is assigned to each Scrum teams.
Having to write the user documentation while developing helps validating the design. The technical writer also participate in the design of the application.
This is in addition of release burndown and sprint burndown.
Additional documentation is created by the team when they feel it is useful to communicate with the product owner. This became less important as we are learning to write better user stories.
考虑阅读 Ambler 的“敏捷建模”。 他提出了一个非常有力的案例来说明为什么仅仅创建大量完整的 UML 是一个相当糟糕的主意，并给出了一些很好的例子。
Consider reading Ambler's "Agile Modeling". He makes a very strong case as to why just creating tons of full UMLs is a fairly bad idea, and gives some good examples.