1

Are they compatible concepts? If yes, there are any examples and cases of usages in the IT industry? Are there any tools supports and automated this kind of process.

lynch warren
  • 105
  • 10
  • 1
    Try http://www.agilemodeling.com/artifacts/useCaseDiagram.htm and http://www.agilemodeling.com/artifacts/systemUseCase.htm and other similar pages on the Agile Modeling website – xmojmr Jan 24 '18 at 07:31
  • 1
    I recommend to read **Use Case 2.0** [here](https://www.ivarjacobson.com/sites/default/files/field_iji_file/article/use-case_2_0_jan11.pdf), the **Use-Case 2.0 and backlog-driven iterations** section. It is so good explanation to apply Use Cases in Scrum. – Gholamali Irani Jan 24 '18 at 21:29
  • Read Use Case 2.0 find it suitable for Scrum process development. Hope use case 2.0 support by some vendors for facilitating team collaborative process managment. Unfortunately, Google around seems not yet available in the market at the moment yet. – lynch warren Jan 24 '18 at 23:57

1 Answers1

4

In short, yes these are compatible concepts, though in practice agile methodologies tend to leverage a parallel concept, the User Story. If you are following SCRUM by the book then I recommend simply following what SCRUM says to do as that is what your team will expect. However, if not, there is absolutely nothing wrong with using Use Cases in an agile context; I've done it many times over the last 20 odd years.

At its core, a Use Case is simply a specification of functional requirements (steps, flows). User Stories aim to do the same thing, ultimately describing a series of steps. Both are often elaborated incrementally, starting usually with a name, objective statement, a statement of key actors and so on and then elaborating on steps and flows, triggers, pre and post conditions etc as you discover more. There are other ways to express functional requirements in a structured way -- e.g. UML activity diagrams, BPMN processes which you might also consider. What I find useful about Use Cases however is that you can start with a diagram ("blobs on a page") and graphically illustrate their relationships with other use cases, actors and maybe illustrate the system boundary if you're at that level. You can also leverage a formal Use Case modelling tool (there are many, just google it). Both of these things are hard to do in Epics & User Stories which tend to just start as post-it notes on a kanban or some list of notionally unrelated "as a ..blar... I need to ...blar..." type statements. For this reason, even if you choose to elaborate as User Stories I would recommend using a Use Case diagram to establish scope and perform your initial analysis, with each Use Case representing ultimately a User Story.

muszeo
  • 2,312
  • 9
  • 13
  • 1
    The advantage of using UCs is the focus on added value. Unfortunately most people don't see that and focus on functions. Without ever having used user stories it smells like this is focused on functions too. – qwerty_so Jan 24 '18 at 20:41
  • Just to want some clarification: "with each Use Case representing ultimately a User Story." How about a use case has a number of scenarios? so a use case should usually represented by a single user story, or a number of user stories. – lynch warren Jan 25 '18 at 00:13
  • A Use Case has a main flow and can have a number of alternate flows and/or exception flows. In contrast, you would probably write a separate User Story for each of these, one for the main flow and then one for each of the alternates etc. In my synopsis above I glossed over this as in a scoping exercise you'd probably focus in on main flows and then elaborate this later. – muszeo Jan 25 '18 at 07:59