Hey Reader,

So I've been working on some new materials. Just a few pages explaining Scrum in easy terms.

The idea behind it was to create a wiki that teams can use for onboarding and just as a quick overview of Scrum. Not everyone may be able to attend a class, but at least they have the most important information about how the teams work in the organization.

(these materials probably will make their way to existing products like the Intro to Scrum and the SM Startup Guide)

Obviously, I needed to add information about each element of the framework, as well as a high-level overview.

Initially, I thought I could just reuse whatever I had created already. For example, in my "Scrum in 5 minutes" video, I used a simple graph I always use:

​

​

But then I thought again... wondering if this is actually helpful. If someone was looking at it on their own, would they understand what the heck this all means?

Presenting the information in an easy-to-consume way, especially when explaining complex concepts, is essential! Visualization was a must. If I want the readers to understand Scrum with a quick overview, I need to have an accompanying graphic to whatever text I'm going to write.

With that settled, the next challenge is making my graph easy to follow. So, the graph above that I always use is good enough. But you can really only understand it if I am drawing it as I'm explaining it. If someone who knows nothing about the topic looks at it, they would not be able to understand what's going on here.

It's unclear whether it's a process, and how it flows exactly. Who is doing what and when? It's unclear that this is a Sprint cycle that restarts once it's finished. It means I need to put this into perspective. What does it actually look like in real life?

After some brainstorming, a new graph started to emerge. And the more I refined it, the more I liked it. So here below I present you the new Scrum overview:

It's not perfect. But there are a few things I think this graph does better than the previous one:

• It guides the viewer with clear steps. Start at number 1 and keep going from there.
• It shows the Sprint Events in order from left to right (and doesn't have the Retro at the top to show the cycle part of the Sprint)
• It also clarifies when different events take place: Day 1, Day 2 - Day N, Last Day)
• It's clear who attends
• The cycle nature of the Sprint is easily represented in steps 3 and 10

And of course, this graph is not complete without an explanation. Thanks to the clear steps to go through, a reader can follow it and see exactly what is being described in the graph.

Here is the explanation I created:

1. It starts with a demand coming from stakeholders and customers to build a product. And so the team begins their work.
2. The Product Owner collects information about customers’ needs and wants and decides on the next steps. All the work to be done in the Product is documented in the Product Backlog.
3. The team starts their Sprints.
4. At the beginning of the Sprint, the team plans their work for the Sprint following the guidance given by the Product Owner on what they should work on. This is done with the help of a Sprint Goal that is initially defined by the Product Owner and then discussed and adjusted with the team if needed.
5. The team pulls the work from the Product Backlog into their Sprint Backlog guided by the Sprint Goal. They discuss what exactly needs to be done and decide how much work is reasonable.
6. The work starts. Every working day Developers meet for 15 minutes to discuss their progress and plan their work for the day.
7. The team continuously refines its Product Backlog as more is discovered about the Product and customers’ and stakeholders’ needs.
8. At the end of the Sprint, the work that has been completed is added to the product Increment that can be presented to the stakeholders at the Sprint Review. Completed work must meet the Definition of Done - a checklist defining the minimum acceptable quality. The goal of Sprint Review is to get stakeholders’ feedback, discuss potential completion dates, and adjust the team’s plan for the next Sprint.
9. The Sprint ends with a Sprint Retrospective where the whole team discusses how to make their work more productive, enjoyable, and organized while also upholding the standards of Product quality.
10. This ends the Sprint and the next Sprint can start right away going over the same steps. The whole flow is facilitated by the Scrum Master who helps the Team to organize themselves and plan better.

This is a pretty short explanation for a whole framework. But it's essential to give the information out in small pieces and only give relevant information.

For example, at this point, it's not important how long each event should be, or provide details of the exact agenda items for each meeting. This is the job of the next sections in the guide, where the readers can deep dive into each topic separately.

​

As I was working on this, I also saw opportunities to give more clarification to specific elements of Scrum with real-life examples. Because often this is what's missing making the framework (any framework, really) difficult to apply in real life beyond just theory.

If you have the SM Startup Guide, you've seen the section where I give you the Sprint Events agenda. That's already a huge step forward from a generic explanation we can find in the Scrum Guide itself.

But even with this, some people still have questions. Like: how does it run exactly? who leads it? And so I added some additional information.

Let's take an example of Sprint Planning.

Firstly, a clarification on who leads the meeting. Here's what I say: "Each role has a different part of the meeting to lead. The whole team participates together and should not be dependent on one person leading the meeting."

Then, I'm adding an example of a real-life meeting highlighting different roles and actions:

• If the Sprint hasn’t been closed yet (e.g. if using tools like Jira), the team may review and confirm that all work items are up to date and close the Sprint.
• The PO starts by showing the current Product Backlog and the top priority items on the list.
• The PO also states the Sprint Goal for the upcoming Sprint. The team discusses if it is achievable.
• If there are some incomplete items that were moved from the past Sprint, the team needs to decide if they want to complete it in the upcoming Sprint or put it on the back burner for now.
• The team then reviews what items they want to pull into the Sprint required to achieve the Sprint Goal, usually starting from the top of the list. This creates their Sprint Backlog.
• The Product Owner provides any additional information on what needs to be done if developers have questions.
• Developers should review each item and discuss what exactly they need to do in order to complete it. They may decompose it into subtasks, add more details to the description, discuss test cases, etc.
• If some items are not estimated (in case the team uses estimation) or some items are in progress from the past Sprint, the team should estimate each work item. This is usually done in story points, but it’s not mandatory.
• The Scrum Master should provide some information on the team’s velocity using past Sprints data.
• The team then reviews how much work they pulled into the Sprint and discusses whether it is doable based on their past velocity. They readjust the Sprint Backlog at this point.
• The Scrum Master asks additional questions about whether the workload is reasonable but also challenging enough, what blockers may prevent the team from completing the work, whether there are holidays or absences planned, etc.
• Once the team feels comfortable with the work they pulled into their Sprint Backlog, they can start the Sprint. This usually means that Developers believe that they can complete the work based on the information they have thus far.

So these are just a couple of things I wanted to share with you today.

How did you find these explanations? Do they make more sense or make it more confusing?

I hope that this can give you some ideas of how you can simplify some of the educational info you're putting out there for your team. But also - feel free to grab the graph and texts and use it to explain Scrum.

The more people understand the framework, the easier it is on us in the end!