0

I am making a simple class diagram for the project management techniques using the Scrum methodology, where projects are made of releases and releases are made of different sprints. All I want to know is, is this Class diagram is correct for this management techinique. If not then what I am missing please help me out to figure out this Class diagram.enter image description here

  • 1
    Sprints methodology? You mean Scrum? What is the goal? Are you making a tool for Sprint management or are you just trying to visualize the Sprint cycle in a UML diagram? – Niels van Reijmersdal Jan 13 '16 at 8:47
  • Do you mean a sprint backlog? Has the product backlog being groomed? Is this for a specific project or is this a 'one size fits all diagram'. Releases seems to fall under waterfall methodology. Although Scrum is used in my organisation in conjunction with Waterfall releases i.e code drop to live. – Treasa Jan 15 '16 at 23:49
  • From an UML perspective, all your arrows with a black diamond are the wrong way around and the link between feature/sprint should probably have no diamond (or hollow diamonds on the links to feature). – Bart van Ingen Schenau Jan 22 '16 at 9:53
0

This is interesting and I would say that it is an excellent start! I see this exercise that you are doing to be valuable and potentially an excellent way to describe scrum to developers. Since you are talking about Sprints, I am guessing you are using scrum, if that assumption is wrong please let me know. Here are some points that might help you improve the UML Diagram:

  1. I like to think of Releases as a collection of features, not sprints. With a release you can release one or more features, or even one or more bug fixes and no new features.
  2. It is difficult to make the assertion that Releases are composed of sprints because you could theoretically have a release mid sprint if you are releasing a critical bug fix.
  3. Depending on the software you use, you can break the backlog up into objects as well. In JIRA, the backlog is composed of Epics, which are composed of Work Items (that can be stories, spikes, bugs, etc).
  4. In TFS, Epics are composed of Features, which are composed of Work Items (User Stories or Bugs) and Work Items are composed of Tasks.
  5. You can also add objects to the Project object for your Team. The Team Class would consist of a Product owner, a Scrum master, one or more developers/testers, perhaps a designer and a BA.

This is a fun looking and also useful project. Please share the final result with us when you are done!

  • My happy pleasure! If I ever need to explain scrum to developers again I will try to use this technique. Thanks for the really great idea! – zeeple Jan 22 '16 at 22:19
0

While I think this is a really cool exercise, I think it may be doomed to be perpetually inaccurate. Of course, I'm not an expert in UML, so I'll explain why and you can see if that helps.

There is one set of relationships around the work and another set of relationships around how the work gets done. These are loosely coupled through the backlog.

For the work to do, you would have a project, which is made of releases. After this the exact names change a lot depending on your tool but each release probably has some epics which are composed of user stories. The backlog is an abstraction for presenting the work-to-do set of objects to those doing the work. I'm going to set aside scaling frameworks for a moment and just talk about Scrum, so that "do-the-work" diagram would have a team, which has members including a Scrum Master, Product Owner, and a group called the development or delivery team which has members of its own which may or may not be developers (obviously if it's software, some almost certainly are).

The backlog really presents the whole of the work-to-do set of objects, but it's important to understand that it connects at the team level, not at the developer level. Scrum allows the team to determine its own internal strategy for completing the work.

As I said, I don't know if this is possible to represent in UML.

  • I feel it is a bit strong to say that it is "doomed to be perpetually inaccurate", although I do see your point. I prefer to think of it as something that, in a very Agile-y way, can be constantly iterated over and improved. Also, your point about the team-centric nature of scrum is well taken. Perhaps it is better to say that the UML diagram can be made more accurate on a team by team basis, customizing it as necessary to fit their internal strategies? Anyway, thanks for the contribution! – zeeple Jan 22 '16 at 20:54
  • It may be a bit dramatic. What I meant is just that I don't know if it is possible to represent this in UML, and so you might be stuck using a representation that, while roughly close, doesn't accurately describe the way the team interacts with the backlog. – Daniel Jan 22 '16 at 22:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.