An overview of Scrum diagrams

I have noticed a few discussions recently about the ‘scrum diagram’. I will be posting mainly in response to these 3 blogs: David Harvey – The Scrum picture is wrong, Karl Scotland – A New Lean And Agile Picture , Andy Brandt – Scrum picture is quite right. I will be collating these ideas into this post to offer an analysis/ pro’s and cons of current diagrams and create a discussion to (hopefully) find a solution.

Brief background, I am a designer/front-end developer at 3months and a certified Scrum Master, what I have to offer is experience in design, illustration and experience working in an agile software development team.

The Original Scrum diagram

A Visual Introduction to Scrum

(Mike Cohn and Mountain Goat Software)

After reading David’s article on The scrum picture is wrong – in reference to this diagram above, I started off thinking how I could incorporate David’s ideas into an improved, polished diagram. The main issue David has with the current (most used) scrum diagram is the lack of people and the focus on only one of the deliverables – the product or ‘potentially shippable product increment’.

He suggests the diagram should illustrate benefits to the team, product and client.

“..I worry about what happens when we surround ourselves with process pictures which (1) don‚t include people, and (2) only tell half the story…”

Pros

• Colours
• Mention of daily scrum
• Easy to talk about when presenting

Cons

• Lack of people – Where is the team? Where is the client?
• No product vision

Agile Project Management with Scrum – Ken Schwaber

Pros

• Shows people
• Shows product vision
• Daily scrum
• Feedback loop

Cons

• No retrospective (not technically a must in Scrum but it’s common practice)
• Not clear that the outcome is a ‘potentially releasable product’
• No visible end to the process

The Process Model for Scrum

(Scaling Software Agility – Best Practices for Large Enterprises by Dean Leffingwell)

Pros

• A detailed overview of scrum process

Cons

• No product vision
• Lots of text

Scrum for Team System

Pros

• Lists preparation tasks, but probably isn’t necessary

Cons

• Does not flow well
• Interestingly the first step from the large prep section takes you to more prep rather than getting you going
• Daily cycle feels a little hidden
• Artefacts and people feel like an adjunct to the cycle rather than part of it.

A New Lean and Agile Picture

Karl Scotland’s blog post A New Lean And Agile Picture offers this diagram which focuses on 2 inputs VISION and REALITY and 2 outputs PRODUCT and TEAM.

Pros

• Minimal – but whilst minimal it is very open to interpretation
• Easy to remember
• Shows benefits to client and to team

Cons (*taken from comments on Karl Scotland’s blog)

• *inputs should say VISION and TEAM
• *outputs should say PRODUCT INCREMENT and TEAM CAPABILITY
• No break down of the actual Scrum (or other) process

A new and improved Scrum Diagram?

My first attempt at this focused on combining the positive aspects of these main diagrams, especially Mike Cohen’s and Karl Scotland’s diagrams.

Feedback from my team members

• Sprint backlog should be within in cycle
• Try visually indicating that the product back log ‘feeds’ into the sprint
• How about move the daily scrum to the center of the cycle?

and now for the latest version….

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 New Zealand License.

So there we have it,

• Vision + Team as inputs
• Product + Team Capability as outputs
• An Initial Product Backlog that feeds into the Sprint Cycle
• Within the Sprint Cycle we have all the tasks that make up a sprint – planning, sprint backlog, product increment, sprint review, sprint retrospective, updated product backlog

and at the core of cycle we have the Daily work!

Kelly Cheesman is an Interaction Designer at 3months.