Preparation for Professional Scrum Master certificate

The Scrum.org Professional Scrum Master assessment is a 60 minute test with 80 multiple choice type questions taken from a bigger pool of questions. To pass the assessment, you have to score 85% correct answers, in other words you need to have 68 of 80 questions answered correctly.

I have never worked as Scrum Master before, so I did not have any experience and had to use theoretical knowledge to pass the exam. PSM 1 is the foundation level, so it’s quite doable on this level,

What I did before I studied

Before I studied for a specific assessment I organized interesting blogs, articles, forum topics and free resources within a Microsoft OneNote document. Later I switched to the browser Plugin Toby, which is great to organize bookmarks in categories. Organizing bookmarks and resources in the browser was way more intuitive and faster than using OneNote.

How I studied

I used Anki to learn the Professional Scrum Developer Glossary and the Scrum Glossary with the spaced repetition learning technique. I used Recoll for indexing and searching my digital resources.
I took open assessments everyday, tracked my results in a spreadsheet, so I could see my score stabilize and the average time per question decrease. I always took note of missed questions in a separate word document and also saved the whole assessment session as PDF so Recoll could index it.

The open assessments provided by scrum.org are a good starting point, but the pool of questions is very small compared to the pool of questions in the actual assessment. Nevertheless, the real assessment will contain questions from the open assessments, so you should do your best to know every question of the open assessments. I also used the PSM 1 Learning Quiz by Mikhail Lapshin and found this very useful, as it gives you instant feedback, and the questions are quite similar to the real questions.

I printed the Scrum Guide and read it multiple times. Besides the Scrum Guide I picked some information from the book Scrum and XP from the trenches by Henrik Kniberg but I did not read the whole book.

I was quite anxious to use resources that does not come from scrum.org, so I mainly used the Scrum Guide and the official forum to get my information. That’s why I did not spent money for external test assessments or additional books. Those would be interpretations of other people and might confuse me, so I avoided any external resources except “Scrum and XP from the trenches”, but I was very picky about what information to take in.

I have read books about Scrum in the past and I struggled to forget information I gained from these books, which have proven wrong when applied to open assessments.

Assessment

For the actual asessment, you have 60 minutes, You will see one question per page, so every questions causes internet traffic, so make sure your internet connection is fast and will not be interrupted for the duration of the test.

In the assessment, you’ll have the possibility to mark questions with a bookmark, so you can get to this question later. Try to use this as little as possible. I bookmarked 25 questions (out of 80 = 31%) and finished the last question after 40 minutes. So I had 20 minutes to review 25 questions. This also means, that I had to spent 30 seconds per question on average to answer the question or to make the decision to bookmark it. This is a lot slower compared to my average speed in the open assessment (10 seconds per question).

Don’t expect the real questions to be like the open assessment questions, they are not. Some are easy and others are quite demanding and want you to interpret the situation. Don’t expect that you can google the questions you can’t answer, you won’t find anything useful, and if you do, you simply don’t have enough time to read through the results.

Recommendation

Make a directory to store your scrum.org open assessment results. Use recoll to index these documents. This is quite helpful to find useful information within your test results.

Do the open assessments and the PSM 1 Learning Quiz until you get every question right, consistently.

Don’t use external resources, all the information is in the Scrum Guide. Don’t rely on what you already know, if this is your first scrum.org certification,

I actually used external resources like the Mountain Goat Software Blog and  Scrum and XP from the trenches, because I like to gather a lot of information to understand a topic. You can do this as well, but you have to permanently make sure, that the information is in line with the Scrum Guide. If you are uncertain, ask in the Scrum Forum.

 

Cheers. 🙂

Useful resources

Scrum Guide

Scrum Glossary

Scrum Developer Glossary

PSM 1 Learning Quiz

Scrum Open Assessment

To git or not to git

Time warp: back to the past

Back in 2010 I came into contact with git for the first time. It was introduced to me by a colleague who used it for his projects and he was confident it would be a good idea to use it across the whole development team. My colleague was one of these guys who always knew when something is worth the effort to learn it and he was the guy I was looking up to. He built the tools and systems which enabled us to deliver our data records to our clients. He was the smart guy with the nerdy hairdress.

Because he was the developer and later maintainer of some really cool stuff – one system provided extensive data of german soccer matches – today it would be called “Microservice” – he had the respect of other developers and also some influence to our technical lead. So git was open for evaluation and used for a major project which required four to five developers to work on this over half a year.
We had no theoretical introduction to the concepts of git (or any other distributed source code management) and no one had time to become an expert, furthermore the project was already behind schedule. We regularly struggled with the concepts of git: daily merge conflicts, someone force-pushed to master and rewrote history and now and then mysterious data loss which caused headaches to all of us.
So my colleague was asked to give advice but educating others how to use git also prevented him from getting his work done.

Quickly, some guidelines where defined, which enabled us to collaborate and avoid conflicts. I just list them here for sentimental reasons, not to make them appear to be the most brilliant guidelines ever written.

  1. pull before you start your work (in case of merge conflict, merge together with the author of the other changes)
  2. push before you go home
  3. use a command line interpreter because the plugin for Eclipse is crap
  4. communicate with others if you think you might break their changes or you know they’re working on the same files
  5. never force push (again)

As you can see, there is no word about checkouts, branching or merging. We integrated everything on master. Back in the day it was a lack of knowledge how to use feature branches properly. That came later. But for the scope of this project, we just used the master branch.

Time warp: back to the not so distant past

When I picked up my latest job, I came into a team of developers who merely heard of git. The situation was somewhat similar to the one in 2010, but in the meantime I learned to use and love git. One of them was using git in a project, which should become my first project, so we collaborated and he should become my first adopter. In fact it was pretty easy to convince him to use git from now to eternity.

But I faced some resistance when I demanded others, who were required to contribute to my project, to use git. Especially those who used Subversion for a long time. This was made clear to me when I was asked: “I don’t understand why we can’t just use svn for this?”
I assume this was caused by the amont of steps git requires you to do, and if I try to take the perspective of my older svn-loving friends I can understand this:

  1. I have to clone the project – no problem so far.
  2. Telling git my name and my e-mail? Are you crazy?
  3. I have to checkout another branch? Why is that so? The source code is exactly in front of me? Why is there a development branch I have to use? But okay, you’re the guy, I do as you command.
  4. I have to create my own branch and switch to it? Why is that so? I did that a second ago? Well, just did it. What’s next?
  5. Ah cool, I can do my stuff. Cool, I’ll do my stuff. Eh wait – where are you going? Leaving me alone with this shenanigans? Ah okay, you’ll come back as soon as I run into any trouble. Ah, you’ll come back as soon as I want to publish my changes? Don’t you think I can do that on my own, kid?
  6. Ah cool, there you’re again! I just can’t commit my changes. Something seems to be broken. Ah, you’re saying I have to add them first? That requires an extra step? Okay. Seems fine to me now.
  7. Can you please come back again? I commited my changes but apparently they’re not available to others. Ah, I have to publish my changes explicitly? Wait! What do you mean: “Merge or rebase your changes before pushing. And maybe do some interactive rebase here and there and ammend this commit.”?
  8. This feels … not … right.

Okay, I’m kidding. I know that there are some obstacles when you’re working with git for the first time. When I made first contact with git, I didn’t know what I was doing at all. But I think the problem is not the human, it’s the work environment.
When I started this job, there was a lot of pressure to all of us to get things done. And a new tool which costs you a lot of time before you earn the benefits is not welcome. Of course I can not claim that there’s always pressure by a closing deadline. But in an unhealthy work environment there are other factors which prevents you from learning new tools and techniques.

With unhealtly I mean: there’s someone under pressure, it’s maybe not always the same person, but if it’s a small team and you never have the opportunity to get all people together to review and evaluate some new stuff, change is always an additional burden. Also the team may consist of too similar personalities which might reduce the effort to explore something new and stick to what is already proven useful. In the case of this team, there’s a core of developers who are really loyal and are with the company for many years. On the other hand, there’s a heavy fluctuation of new members who eventually leave after some months. Such a fluctuation impacts the performance of the team immensely and leads to cynical thinking of some individuals who then are only interested in getting their work done and not caring about the opportunities other techniques come with.

Make others love the idea, not the tool

So we had to come up with a plan to fight these struggles, in particular to improve the skills and knowledge about git so that each developer has a sufficient knowledge and can operate on his own. Luckily, a way of spreading the knowledge was the project I mentioned earlier. It is one of our major projects and it requires constant development. And since it is too big to be handled by my colleague and myself, others have to contribute from time to time, consequently they have to use git because it is a git project.

Despite we are not using pair programming on a regular basis, we already know that it is a great way to share knowledge and it is always an opportunity to learn. It’s much less of a rushed instructional session and more of a dialogue which enables the teaching person to give insight into the advantages and concepts of git. It is really educational for people when they realize that it’s actually quite hard to lose data with git.

Another action to promote collaboration and change in mindset was to remove our old code repository. We used a minor provider where we stored our repositories. We moved to Bitbucket, which is slightly more expensive, but the benefits outweigh the costs: code reviews, forks and pull requests, issue tracking, better user interface and activity streams to name a few. In other words: using the source code management became much more fun and improved the developer experience.

So legacy projects will be migrated from svn to git once they are touched and then pushed to Bitbucket. We also committed to a policy that new projects will be under git. It is a slow process and to monitor the progress we have to sit together or have a talk while cooking coffee in the kitchen, since we’re not pairing for programming. But my impression is this: it’s constantly rewarding to all of us.

© 2025 Just a Developer

Theme by Anders NorenUp ↑