Henrik Kniberg

Henrik Kniberg

I debug, refactor, and optimize IT companies. And jam alot too.


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)


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
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
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:

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