ScruML

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

Doesn’t the world need another modelling language? :o)

ScruML stands for “Scrum Modelling Language”. Like UML, but domain specific and not as strict and… um… well maybe not that much like UML after all.

ScruML is used to visualize a Scrum organization in a simple even-the-managers-get-it way. It focuses only on the Scrum elements (product owners and teams and who delivers to who), so it is not a complete organizational map. This is useful as tool when a company is trying to figure out how to implement Scrum in their particular context.

How will the organization look like in the first step? The second step? Which teams do we have? Which teams need to synchronize with each other? Which stakeholders feed which product backlogs? Which product backlogs feed which teams? If there are multiple product owners, who resolves priority conflicts between them? What is the definition of Done? How long are the sprints? Etc. All in one simple, beautiful picture.

NOTE FOR SENSITIVE READERS: Some of the diagrams below show non-optimal Scrum organizations, including terrible things such as handovers to QA. I’ve heard that such organizations exist in reality-land :o)

You seem like a smart & impatient person so instead of writing a tedious spec I’ll provide 3 examples and let you figure out the details yourself.

Example 1: Single team (or Hello World)

ScruML1

This diagram says:

  • We have one team consisting of 5 team members, with Reza Farhang (RF) as ScrumMaster.
  • There is only one product owner (the stick figure) and one product backlog.
  • The product backlog is mostly populated by requests directly from end users.
  • The definition of done is “delivered to the end user”.
  • Sprint length is 2 weeks.

Example 2: Multiple teams
ScruML2
This diagram says:

  • We have two teams working off the same product backlog.
  • The definition of done is “delivered to operations” (who in turn may deploy to production now or later).
  • Team 1 does 2-week sprints, Team 2 does 4-week sprints.
  • The teams need to synchronize their work through a Scrum-of-Scrums (the dotted line) but they deliver independently to operations. There is no integration step.
  • The product backlog is populated mostly by sales, management, beta testers, and the support department.

Example 3: Multiple teams & product owners
ScruML3
This diagram says:

  • We have 2 product owners and product backlogs (JM and LJ).
  • LJ’s backlog is fed by helpdesk.
  • JM’s backlog is mostly fed by product management, but requests from other stakeholders end up there as well.
  • Team 1 and Team 2 are fed by JM’s product backlog, both do 3-week sprints.
    • Their definition of done is “integrated & delivered to QA”, i.e. team 1 and team 2 integrate to a single release before handing to QA.
  • Team 3 is fed by LJ’s product backlog, they do 1-week sprints. They basically work for helpdesk.
    • Their definition of done is “ready for shipping”, they don’t need to go through a separate QA step.
  • All three teams have dependencies and therefore synchronize through a Scrum of Scrums.
  • If JM and LJ run into resource conflicts (for example who gets the new recruits or the cool server), the conflict is resolved by AS.

Having to hand off to a QA department isn’t very agile, so here’s the cleaned up version:
ScruML4

Feel free to add any other elements you need. Just remember that adding too many new elements will quickly make the diagram unreadable…

5 Comments

  • 1
    August 25, 2007 - 12:41 pm | Permalink

    I found the "Hello World" comment to be hysterically funny.

  • 2
    August 31, 2007 - 6:43 am | Permalink

    Henrik,

    Looks nice and what is more important provides an easy way to visualize organizational structures.

    But what would be more interesting (to me) is to be able to model the current (on-the-way-to-Scrum) structures so that the Scrum smells become inevitably visible.

    E.g. the hand-offs to QA as you said can be visualized and tagged as a smell.

    Just an idea.

  • 3
    Peter Hundermark
    September 28, 2007 - 10:49 am | Permalink

    Henrik,

    I like the modelling concept and the ‘smells’ comment.

    What ideas do you have about a forum for sharing and discussing models?

  • 4
    September 30, 2007 - 5:52 am | Permalink

    I’m sure there are lots of interesting forums to discuss models like this, no particularly suitable one comes to mind though. The problem with many modeling forums that I’ve seen is that they tend to get quite academic. ScruML is intended to be 100% simple and practical.

    ScruML is probably going to spread and grow and diverge as different people decide to add their own favorite doodles to it.

    It seems to be taking hold already. Last week during the JAOO conference Jeff Sutherland opened the whole Agile Track by showing several ScruML slides :o)

  • 5
    August 20, 2008 - 8:28 am | Permalink

    Alexey: I do model the “current org” as part of getting started with a team. I use a standard “DFD” context diagram: circle in middle is team (if needed for clarity: inside we indicate who is considered “team). On border of this may be some shared resource (ex: tech writer) and the ScrumMaster if they already have one.

    I start by asking: “What do you deliver, and to whom?” and I put in all the “outputs” as outgoing arrows. They usually need to be reminded of less sexy deliverables like API doc, etc.

    Then I ask “What comes in to request or to help you create these outputs, and from whom?” and we add the incoming arrows, sometimes in another colour.

    “And what is still missing here?” This reveals things they take for granted: different kinds of interruptions, like 2nd tier support for help desk, etc.

    Now we have a picture of the team “in context.” This gives a good basis for further discussions, reveals some of the team’s assumptions and maybe a few blindspots, too. Usually at this point I emphasise that the team needs to decide whether to engage these parties directly and educate them about Agile or simply to “build bridges” to them, so the relationships are ready when Agile’s changes start to impact those interactions.

    People often don’t understand why ScrumMasters should be full time, at least at first. These relationships are reason enough, not to mention the need to support team members going thru the chaos of major change :-)

    deb

  • Leave a Reply

    Your email address will not be published. Required fields are marked *