Can I use the Use Case Diagram in SCRUM? [closed]

Question

I'm starting a project with a team and we're using SCRUM as methodology. It's my first time with SCRUM. We have listed our functionalities and we made our stories, (user stories and technical stories as well as their tasks).

I've a tight UML approach to start any dev project and for me, after listing all the functionalities, the next step is to make the User Cases Diagram to let everybody see what's the application going to do and who's gonna interact with it. But my team said that there's no interest in using UML in SCRUM.

Can I use the User Diagram of UML to represent the User Stories in SCRUM? Which other diagrams can be used in SCRUM? (It could be a stupid question 'cause I cannot imagine an application without a class Diagram or a Sequence Diagram, but I really wanna see the advice from the experts in SCRUM)

Thanks.

Tuberosity

I'm voting to close this question as off-topic because it is not about programming. – Overthrow

Answer 1

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.

Monstrance

I like your answer. Only thing to add would be to stress the difference between use cases and user stories. – Way

I see use cases as features or small features. A feature consists of different user stories. So a use case is a bunch of user stories for me – Monstrance

+1 interessting insight – Bresnahan

@Monstrance your suggestion is interesting. I wonder if you have any simple real world example of using mind mapping for user stories? – Needless

Answer 2

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.

Audubon

Answer 3

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.

Otero

Answer 4

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".

Mitosis

Thanks for your answer. Good to know the "How to test thing". Talking about the technical stories, in our projet we have to make a special algorithm to give some results. We have consider this as technical. Is this a technical story? I think that this part is involved in a user story as a part of its development, so I see it as a task... but I'm not sure. :S – Tuberosity

Yes, in that case you probably have no choice but to specify it in technical terms. About the "how to test thing", you can also use it as a guideline for the demo at the end of sprint, and mark the story as "validated" if the test goes ok. And your team will also know what you expect at the demo. – Mitosis

Another question... at the end of a sprint, do we have to finish a story, or just some tasks of a story?? Gracias. – Tuberosity

The whole story. From the point of view of the Product Owner, he got nothing if the whole story is not finished. If your story is too large to be done in a sprint, split it. Download this free PDF, it is very insightful and will give you many answers infoq.com/minibooks/scrum-xp-from-the-trenches – Mitosis

Answer 5

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.

Doubleton

If diagrams are mirrors of the code, why not look at the code instead? Diagrams make the programs no simpler. Modeling is for abstracting details, not for being happy about some pictures. – Way

The code needs abstraction which is formalized and UML is the solution I use in my company. Don't forget that UML goal is to gives views of your architecture in which you can hide the not needed information. You can also add notes, comments and even constraints. What I do in my projects is to extract an UML model from the code, then keep going modeling at UML level, validate it and then put back it into the project. It means that I can manipulate my model without any code and decide what time to merge it. This is really marvelous and add real value to the code. – Doubleton

Answer 6

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!

Dimphia

Answer 7

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.

References

• UML 2 State Machine Diagrams: An Agile Introduction

Chiropteran