Can I use the User Diagram of UML to represent the User Stories in SCRUM?
A use case diagram would be helpful, because it is pretty straightforward, and gives a high level idea what the project is about.
However I won't recommend to use any other UML diagram in scrum. I agree with the others that in an agile project the code changes so frequently that your diagrams will be obsolete after several days. In this case you have to redraw them, which is a waste.
For example if you are using eclipse for development, a simple refactoring step can ruin your class diagram :-(
Which other diagrams can be used in SCRUM?
I would suggest to use mindmaps. Recently we started to create our own user stories with drawing large mindmaps and put them on the office walls.
We have a feature in the middle, and we connect sub user stories to it - and sub-sub user stories to them -, and every available information we have at the moment. With this approach we have everything in one place: user stories, technical informations, questions, etc.
Of course the mindmap grows day by day, and we know more and more about the feature we have to implement.
Actually we are doing something similar described in this agile dzone article, but since you are using scrum not xp+kanban I talked about user stories not MMFs.
You can use whatever you like in Scrum that helps your team communicate effectively. Scrum makes no decisions, judgements, or guidance on what tools are effective for that team. It only asks that you reflect on the tools and practices used in executing a Sprint and make adjustments accordingly. This is the inspect and adapt loop.
Being open and honest in discussing the benefit of the tools and techniques used to deliver value requires a lot of effort and willingness by the individual members to be open to change.
What I've been told from people who've been using Scrum for a while (ie: this is opinion) is that doing UML diagrams can be a bit time consuming because as your development methodology is agile, your requirements could very easily radically change after the first sprint's show-and-tell, which means you could be doing fairly big redesigns.
Of course, do scratch up how you will tackle your tasks in the sprint backlog - you could certainly document as you go, but maintaining a central repository of class diagrams, etc. could be a slight waste in resources.
I'm not sure what's your role in the project, I'm supposing you are the PO. In that case, use additional documentation if it makes sense. Consider a user story as a reminder for the team to have a conversation with the PO about it.
If you think the user case diagram will clarify the functionality you are asking for, the it's ok. In fact, place it on the wall beside the scrumboard and burndown chart.
In my experience it is sufficient to specify for each story a "how to test" scenario. For example, suppose I have a story for Stackoverflow:
"As a user I can post a new question"
The "how to test" scenario could be:
"Click on a 'Ask Question' button, a form is displayed with a textarea for the question text and a textfield for tags. After the user enters both -they are mandatory- the user is redirected to the question list. The user can see the question title in the list, along with the tags"
So maybe a use case diagram is not really needed. I would recommend to try the "how to test" and see how it goes. It is very useful for the team because they know what you are expecting from the story, from a functional point of view. And you won't be doing documentation for every story.
If you don't like it, the go with the use case diagram, but it is a good idea to give the team something more than the story description.
Now, about the technical stories you mention. What are they? Why is a technical requirement mixed with the functional requirements? Maybe it IS a real requirement for the project, but usually it is not, and can be rewritten as a functional story. Unless your product is something like a framework or library.
For example, the technical story "create indices for the 'get questions' query" could be rewritten as "speed up the questions list page".
I only use class and sequence diagrams with Scrum because these two diagrams are live synchronized with the java code. I certainly don't create UseCase or other diagrams or even try to generate code from diagram (e.g. MDD) because as soon as something is changed in my project and my code it is really too painful to update my diagrams. Diagrams should be automatically updated without any human intervention. I did many project with Omondo EclipseUML and it worked really well.
SCRUM is a application lifecycle management framework, not a methodology as you stated. Please refer to scrum.org
Use Cases are abstracted. If they help your team during refinement, then great. BUT once your team has committed to the story, change is welcomed and there is little point maintaining them once the story is done. The goal is always user acceptable working software!
UML state machine diagrams are useful in Scrum for projects focused on redesigning UI while retaining business logic:
State machine modeling is a dynamic modeling technique, one that focuses on identifying the behavior within your system-in this case, behavior specific to the instances of a single class. My style is to draw one or more state machine diagrams when a class exhibits different behavior depending on its state. For example, the Address class is fairly simple, representing data you will display and manipulate in your system. Seminar objects, on the other hand, are fairly complex, and therefore it makes sense to create a state machine diagram for them.
发布评论
评论（7）
用例图会很有帮助，因为它非常简单，并且给出了项目内容的高级概念。
不过，我不建议在 scrum 中使用任何其他 UML 图。我同意其他人的观点，在敏捷项目中，代码更改如此频繁，以至于您的图表几天后就会过时。在这种情况下你必须重新绘制它们，这是一种浪费。
例如，如果您使用 Eclipse 进行开发，一个简单的重构步骤可能会毁掉您的类图 :-(
我建议使用思维导图。最近，我们开始通过绘制大型思维导图来创建自己的用户故事，并将它们放在办公室墙上。
我们在中间有一个功能，我们将子用户故事连接到它 - 并将子子用户故事连接到它们 - 以及我们目前拥有的所有可用信息。通过这种方法，我们将所有内容都集中在一个地方：用户故事、技术信息、问题等。
当然，思维导图日益增长，我们对必须实现的功能也了解得越来越多。
实际上，我们正在做这篇敏捷 dzone 文章中描述的类似事情，但由于您使用的是 scrum 而不是 xp+kanban，所以我谈论的是用户故事而不是MMF。
A use case diagram would be helpful, because it is pretty straightforward, and gives a high level idea what the project is about.
However I won't recommend to use any other UML diagram in scrum. I agree with the others that in an agile project the code changes so frequently that your diagrams will be obsolete after several days. In this case you have to redraw them, which is a waste.
For example if you are using eclipse for development, a simple refactoring step can ruin your class diagram :-(
I would suggest to use mindmaps. Recently we started to create our own user stories with drawing large mindmaps and put them on the office walls.
We have a feature in the middle, and we connect sub user stories to it - and sub-sub user stories to them -, and every available information we have at the moment. With this approach we have everything in one place: user stories, technical informations, questions, etc.
Of course the mindmap grows day by day, and we know more and more about the feature we have to implement.
Actually we are doing something similar described in this agile dzone article, but since you are using scrum not xp+kanban I talked about user stories not MMFs.
您可以在 Scrum 中使用您喜欢的任何内容来帮助您的团队有效沟通。 Scrum 不会就哪些工具对该团队有效做出任何决定、判断或指导。它只要求您反思执行 Sprint 时使用的工具和实践，并做出相应的调整。这是检查和调整循环。
开诚布公地讨论用于交付价值的工具和技术的好处需要个体成员付出大量努力并愿意接受变革。
You can use whatever you like in Scrum that helps your team communicate effectively. Scrum makes no decisions, judgements, or guidance on what tools are effective for that team. It only asks that you reflect on the tools and practices used in executing a Sprint and make adjustments accordingly. This is the inspect and adapt loop.
Being open and honest in discussing the benefit of the tools and techniques used to deliver value requires a lot of effort and willingness by the individual members to be open to change.
使用 Scrum 一段时间的人告诉我（即：这是观点），绘制 UML 图可能会有点耗时，因为当您的开发方法很敏捷时，您的需求可能很容易发生根本性的变化在第一个冲刺的展示和讲述之后，这意味着您可以进行相当大的重新设计。
当然，一定要重新考虑一下如何在冲刺待办事项中处理任务——您当然可以边做边记录，但维护类图等的中央存储库可能会稍微浪费资源。
What I've been told from people who've been using Scrum for a while (ie: this is opinion) is that doing UML diagrams can be a bit time consuming because as your development methodology is agile, your requirements could very easily radically change after the first sprint's show-and-tell, which means you could be doing fairly big redesigns.
Of course, do scratch up how you will tackle your tasks in the sprint backlog - you could certainly document as you go, but maintaining a central repository of class diagrams, etc. could be a slight waste in resources.
我不确定您在该项目中的角色是什么，我假设您是 PO。在这种情况下，如果有意义的话，请使用其他文档。将用户故事视为团队与 PO 就此进行对话的提醒。
如果您认为用户案例图能够阐明您所要求的功能，那就可以了。事实上，将其放在墙上的 Scrumboard 和燃尽图旁边。
根据我的经验，为每个故事指定一个“如何测试”场景就足够了。例如，假设我有一个关于 Stackoverflow 的故事：
“作为用户，我可以发布一个新问题”。
“如何测试”场景可以是：
“单击‘提出问题’按钮，将显示一个表单，其中包含一个文本区域，用于用户输入问题文本和标签的文本字段后（它们是强制性的），用户将被重定向到问题列表，用户可以在列表中看到问题标题以及标签”
所以可能是用例图。并不是真正需要的。我建议尝试“如何测试”并看看效果如何。这对团队非常有用，因为从功能的角度来看，他们知道你对故事的期望。而且您不会为每个故事都编写文档。
如果您不喜欢它，可以使用用例图，但最好给团队提供比故事描述更多的内容。
现在，关于你提到的技术故事。这些是什么？为什么技术需求与功能需求混合在一起？也许这是项目的真正需求，但通常不是，并且可以重写为功能性故事。除非您的产品是框架或库之类的东西。
例如，技术故事“为‘获取问题’查询创建索引”可以重写为“加快问题列表页面的速度”。
I'm not sure what's your role in the project, I'm supposing you are the PO. In that case, use additional documentation if it makes sense. Consider a user story as a reminder for the team to have a conversation with the PO about it.
If you think the user case diagram will clarify the functionality you are asking for, the it's ok. In fact, place it on the wall beside the scrumboard and burndown chart.
In my experience it is sufficient to specify for each story a "how to test" scenario. For example, suppose I have a story for Stackoverflow:
"As a user I can post a new question"
The "how to test" scenario could be:
"Click on a 'Ask Question' button, a form is displayed with a textarea for the question text and a textfield for tags. After the user enters both -they are mandatory- the user is redirected to the question list. The user can see the question title in the list, along with the tags"
So maybe a use case diagram is not really needed. I would recommend to try the "how to test" and see how it goes. It is very useful for the team because they know what you are expecting from the story, from a functional point of view. And you won't be doing documentation for every story.
If you don't like it, the go with the use case diagram, but it is a good idea to give the team something more than the story description.
Now, about the technical stories you mention. What are they? Why is a technical requirement mixed with the functional requirements? Maybe it IS a real requirement for the project, but usually it is not, and can be rewritten as a functional story. Unless your product is something like a framework or library.
For example, the technical story "create indices for the 'get questions' query" could be rewritten as "speed up the questions list page".
我只在 Scrum 中使用类图和序列图，因为这两个图与 java 代码实时同步。
我当然不会创建用例或其他图表，甚至不会尝试从图表（例如MDD）生成代码，因为一旦我的项目和代码发生变化，更新我的图表就真的太痛苦了。图表应该自动更新，无需任何人工干预。我使用 Omondo EclipseUML 做了很多项目，效果非常好。
I only use class and sequence diagrams with Scrum because these two diagrams are live synchronized with the java code.
I certainly don't create UseCase or other diagrams or even try to generate code from diagram (e.g. MDD) because as soon as something is changed in my project and my code it is really too painful to update my diagrams. Diagrams should be automatically updated without any human intervention. I did many project with Omondo EclipseUML and it worked really well.
SCRUM 是一个应用程序生命周期管理框架，而不是您所说的方法论。请参阅 scrum.org
用例已抽象。如果他们在改进过程中帮助您的团队，那就太好了。但是，一旦你的团队致力于这个故事，改变就会受到欢迎，一旦故事完成，就没有必要再维护它们了。我们的目标始终是用户可接受的工作软件！
SCRUM is a application lifecycle management framework, not a methodology as you stated. Please refer to scrum.org
Use Cases are abstracted. If they help your team during refinement, then great. BUT once your team has committed to the story, change is welcomed and there is little point maintaining them once the story is done. The goal is always user acceptable working software!
UML 状态机图在 Scrum 中对于专注于重新设计 UI 同时保留业务逻辑的项目非常有用：
参考资料
UML state machine diagrams are useful in Scrum for projects focused on redesigning UI while retaining business logic:
References