The Periodic Table of Scrum
Lots of trainers and agile coaches tries to touch advanced elements of Scrum, Agile, motivation, models, frameworks etc. We are building new theories or looking for existing ones to back up our understanding of the subject. We are trying to bend and break rules to show that we are the best. But not everyone is on the “RI” level. And even if you are, you can still benefit from a well-organized basics.
Today I’m presenting a way to easily imagine how Scrum elemenst interlock, how they react with each other, what, who and when is needed. Inspired by my friend, Paweł Feliński – [I will link to his blog if he writes something :D], a Periodic table of Scrum:
Periodic Table of Scrum : at-a-glance scrum chart
The main table is a chart where you can quickly spot where an element belongs. You can print it in high resolution – the PDF is attached below.
Then apart from the main table, all elements are explained like this:
Element chart – Increment
It will be changing if there are changes to the Scrum Guide.
If you spot a typo or any other error, please comment.
Polish version coming soom!
All licensed with Creative Commons, so use, extend and Scrum On!
PDF: Periodic Table Of Scrum EN 1.1
Update: Small but important changes made to the Grooming description – thanks to Tomek Wlodarek @poddrzewem and fixed faulty links
Periodic Table of Scrum by Kate Terlecka is licensed under a Creative Commons Attribution 3.0 Unported License.
Control Your Chaos 
Nice Table! Very Usefull… But I have one question abou DOD – shuldn’t it belongs both to Development Team and Product Owner? Or even to whole Scrum Team?
So I have a question for you – why should it?
DOD is created by Development Team and Product Owner – it is level of product quality accepted by PO and possible to implement by the team. It shouldn’t be possible to create DOD only by the DT or only by the PO. Also Quality in Scrum is defined by DOD so PO can and should decide about Quality of the Product, as a one of the product value dimension.
SM role is to take care about the process and DOD is one of the very important parts of the proces.
What happens if the Product Owner is purely a business person has virtually no knowledge of technology? In many companies that’s the case. Should he also equally participate in the creation of the DoD?
Yes. He/she should because quality is one of the product value dimension and team members are not correct ppl to set this level alone. Do you remember squirell burger story from (your) SM training?
Exactly – a person purely from business might (and probably will) not be able to assess how engineering practices will impact quality and logn term return on investment. Although it might be under Product Owner’s wishes and business influence, it is up to the Development Team as professionals to ensure that the customer is not getting the squirrelburger. Or, if he decides to buy a squirrelburger, to be fully aware of the risk. That’s why I placed it on the DT level.
Oh, and Scrum Master doesn’t have to be there 😉
OK, IMO it’s one of the reason’s why scrum would not work… Soon or later PO will came and said something like: “Don’t waste your time for this useless tests etc…”
DOD need to be created by the whole team and everyone need to understand why it is like it is… Otherwise we will end up in situtuation where quality is only a compromise between budget, time and… well scope need to be done, cause we can cut quality…
“Too high” quality could be a waste – from bussines perspective… in some situations…
PO NEED to be aware of his/her decisions… If he is not he shouldn’t be PO.
And DOD is not only about technical decisions. At high level of abstraction and with good description of possible consequences everyone could understand it.
You are a technical person and you understand technical implications to the core. Let’s say I’m developing a system for myself. Being a PO, I need the Dev Team’s guidance on what technical practices to employ to give me the desired quality level. Just like you said – a PO has to be aware of his decisions, but not necessarily needs to be a technical expert to assess every technical practice.
A PO can decide to write a hardcoded soution that will be cheap as long as he does it consciousy. Part of being a professional is to refuse service to a PO who refuses to understand and trust in what the Dev Team is teling him. In that case, better find another PO. But still, crafting the DoD is weighted to the Dev Team.
One more thing – the fact that something is in DT’s or PO’s zone does not mean that it’s theirs and only theirs responsibility. It’s the major weight or importance that falls upon the role in each of those cases.
Don’t understand me wrong, I don’t want PO to be a technical person. It’s not about technical details but about high level of understanding why we are doing this. Terms like: Technical Debt, Legacy Code, Iron Management Triangle etc. should be known for every PO – if not you should teach them.
If PO don’t understand DOD then it’s easy to him to reject it. Dev Team can not be always against the Product Owner – that situation is dysfunctional.
If PO consciously agreed that this is OUR Definition of Done, then he will do everything to help DT in complying DOD.
If DT decide about DOD alone, soon or later PO would blame them or DOD for lower velocit or even say that DOD is an obstacle. It would be to late to try to convince him that he is wrong…
I get the impression that you are perceiving the PO as a technically conscious person who always makes the right decision and has to be aware of the technical debt and guarding the iron triangle. This is not the case. A PO is a businessman with a need or conveying the need from the user/customer. Let’s get into a basic analogy – if you were a plumber, would you agree on not properly connecting the pipes, just because it is cheaper to the customer? Even though he assures you that he will not call you if everything breaks, if it does he will still tell his friends how crappy of a professional you are or call you to fix it because it has broken so fast.
Same here – have you ever tried working on a dev team who tried to convince their business of good practices, business said they understood, but still devs were to blame for bugs and poor quality?
IMHO: if a dev team cannot say no to their PO requesting poor quality, this is not a professional team. And Scrum is all about professionalism. I don’t want to see flaccid scrum, where they only execute their events and roles without understanding. Scrum is about good products and satisfied customers.
On the other hand, if the PO requests poor quality, better find himself a poor team that will do this to him and the professional team find themselves a better place to work.
Hi, let me say the periodic table its a great idea, thanks for sharing, maybe I can help with the spanish translation, if you want some help or tell me how we can work in the spanish (latin) translation, best regards.
Hi Jorge,
I’m glad you like this idea 🙂
You can go ahead and translate it – it’s a creative commons licensed thing, so all you have to do is just point to the source. If you’d like I can then publish the spanish version for you 🙂
Kate
Hi Kate,
This is really great and I’d like to know if there’s a new version calling grooming refinement instead?
I’d ideally also see that the Daily Scrum also includes the Sprint Goal and Sprint Backlog – IMHO both are inspected, the latter adapted.
/ Fredrik
Hi Fredrik,
thank you for a great idea. I will update the table for the changes. And you’re right – the Daily Scrum has to include the Sprint Goal, but I wouldn’t include the Sprint Backlog – some teams don’t inspect it on their DS, they do it constantly or it’s in electronic form so it’s a pain. They do it afterwards or on the nearest occasion.
New version coming up soon then 🙂
Kate