Certified Scrum Master: Raw Takeaways That Actually Matter
I always wanted to go through the certification course to organize my empirical knowledge. After spending two days with James Coplien, I found myself with insights that challenged my mindset.
I recently got my Scrum Master certification. Some takeaways align with the official guide, others come from my experience and might differ from what you'd typically hear. These are my notes – plain and practical.
In the quotes area, you’ll see the plain note. Right after, you can see my reflection and/or thoughts on that. Let’s go…
Scrum Master Training Notes
The product backlog is supposed to be ordered but not prioritized.
Priority is about goals, and backlog order is about delivery order. There might be dependencies, for example.
Interestingly, in the official guide, there is no ‘priorities‘. On the other hand, all talks among PMs are about priorities.
An ideal Scrum team has three developers.
The guide suggests 10 or fewer, but three is ideal. I also noticed that big groups (teams) naturally split in groups of three to work on epics/tasks/PBIs.
It's better to focus on the outcome rather than the output.
Outcome vs output. I’ve heard about this so many times. In my mind: we can control output. In other words, we are mostly responsible for output, we literally craft output. It’s about delivered features and getting things done.
Outcome is about measured results such as lower CAC, higher revenue and retention. And here, I’d say, we contribute to the outcome, not craft it.
So, it's hard. It’s hard mentally to accept the new paradigm. “How can I be responsible for something that I don’t craft but only contribute?”. So, most POs and teams focus on output.
Focus on outcome is the next level. You can analyze your last 3-6 months/sprint delivery and assess your level.
Scrum or "feature factory." It's a good contradistinction because Scrum is about value (outcome), and "feature factory" is about features (output)
I just like “feature factory“ phrase. This so precisely describes what many teams do.
It's okay for the team to idle. It's not about working hours. It's about value for the end-user. Time tracking leads to a "feature factory."
When I ran my consulting agency (Conversion42), I asked to track time. Why? Because a) we had a lot of repeatable tasks, b) we sell hours. It was a core of the business. Yep, it was a feature factory.
We estimate PBI (Product Backlog Items), not tasks. PBI is a holistic entity that delivers value. We can add tasks during the sprint to deliver PBI, but we don't add PBIs. Change scope is about PBIs, not tasks.
OMG. I was almost crying at the session. I’ve gone through so many disputes about if we have to estimate sub-tasks or not.
Interesting observation: the more senior team you work with, the less they care about that.
Burn-down is about PBI, not tasks.
Just leave it here.
If the dev team spends time overengineering or beautifying code, it might mean the PO failed to motivate them.
Insightful reframing, isn’t it? I love analogies with children.
Why can children spend hours putting dolls in their places, or arranging cars, cleaning their rooms? Because right after, they have to go eat soup!
If you say that after cleaning they are going to play outside. Then suddenly it may turn out that they are actually finished.
5-Why's technique is about breaking loops.
At that moment, I remembered an engineering manager I had worked with previously. No one asked Why so many times as he did :) It was good for the team, even though it annoyed me.
Retrospective: Take only one point of improvement.
I can't say I didn't know that before, but it's always good to refresh the memory.
Scrum is about end users, not customers.
It's tricky. As a product, I'm used to thinking about customers, activation, retention, and revenue. Scrum is wider. It's about end-users. From this point of view, even the CS Team is an end-user.
The product goal is about the end user. Business goals are about Revenue, etc. It's two different goals. The product goal has to contribute to the Business goal.
It might be tough to follow this using KPIs. OKRs fit better, imo.
Organize complexity, not get rid of it.
We got used to decreasing complexity. "Keep it simple", right? Right! It's okay, but at some point, you may realize that you can't level up keeping all that simple. From this point of view, we should organize complexity.
We don't categorize (prioritize) bugs — we fix them. If you need to categorize bugs, it means they are not the core issue here.
Never thought about it from this point of view. And it’s true.
Vacation as a backlog item: deliver a refreshed and rested team member.
A controversial point. But I'll leave it here.
Kanban is happening when managers want to destroy self-organization to gain more control.
Thinking about this, I’d say, it works if we have self-organization. If we don’t, then we have to build it. Then we’ve got questions such as: do we need it?
Furthermore, building self-organization is a process. Maybe kanban can help give teams a part of control. Need to think about it more…
Sprint duration shapes our minds towards a lean mindset.
I just like it. I love teaching and mentoring, challenging mindsets.
There is no agility without uncertainty!
Every coin has its flip side!
If you have more than three columns on your board, you do Scrumfall, not Scrum.
My personal observation:
the more senior team, the more they communicate and the more effective they do it.
the better communication, the less they depend on tools (columns, epics, automations, etc)
Activities performed manually, e.g. building the burn-down chart manually, likely increase ownership and engagement.
Here is the point: not everything you do is about efficiency. Sometimes to get results we need to achieve a certain level of ownership, engagement, etc. It takes time. Doing something manually, we get the required time.
Scrum is about visibility and continuous improvement. It doesn't help avoid problems by itself; it makes problems visible to the team. The team decides if they want to solve the problem and how to approach it.
Actually, it makes problems visible to all the company. If your company is not about transparency, Scrum won’t work. If you company is not about a healthy (I don’t use “safe“) environment, Scrum won’t work.
Btw, Scrum has its five values described in the guide. If you company is not about the values, what can we talk about?
Two metrics are hard to game: 1. Velocity. 2. Number of bugs from the field.
I think velocity can be gamed as well. But the point is that it’s not so easy. This must be a deliberate conspiracy.
Technical debt is literally technical. That said, it will not be paid off.
I love this. I saw several tactics to work with tech debt. All of them boil down to these two:
We put all overengineering and/or clean up tasks to tech debt. We take them back when we don’t have ready items in the product backlog.
We decrease the quality ignoring the developer opinions, promising them that we will come back and address all the tech debt.
Vocabulary matters:
Done – there is no known remaining work.
Done – it's released on the production to the end user.
Released – it's released on the production to the end user.
Done – we measure that it's bringing value to the end user.
Delivered – we measure that it's bringing value to the end user.
The definition of done reflects your team's level of seniority. Yep, it is that simple.
Make estimates quickly. Long conversations don't work. The faster, the better.
The team may allocate 10% of time (sprint time) to working with PO on a backlog, which is about 1 hour daily.
50% of sprints do not deliver all PBIs. But they meet the sprint goal.
Continuous delivery is a good thing.
I have nothing to add. I knew that, I did that. I wanted to keep it here as one more reminder.
P.S.
James, our coach, shared an observation that I also noticed while running the Conversion42 agency:
There are no clients in the middle. There are only two edges: "We are good and want to become better" and "We failed; we will close in a year if we don't change anything."
What a wonderful summary! :)