Can I use the Use Case Diagram in SCRUM?

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.

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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.

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!

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