How to pass Professional Scrum Master (PSM I) Certification?

So, Finally, I am a Professional Scrum Master (PSM I). It was kind of overdue to have an attempt on Professional Scrum Master Certification conducted by I have been using Agile (and Scrum) in my projects in various capacities for many years now. And to be honest, the simplicity of the framework and the empirical process behind the Scrum has fascinated me to pursue the subject further.

Scrum Master Badge

I registered for the exam last week. The process is relatively simple. Register on the and pay $100 for the PSM I exam. They would send your password to access the exam within a business day. And you have a period of 14 days to give the exam. I kind of used 7 days just to make sure I don’t waste my $100 as the score you need to get is fairly high (85%). That means from a set of 80 questions, you need to get at least 68 right.


I did not do excellent and just made sure to pass the exam on border by having 69 answers correct i.e. 86.6 % as score. Well, not really bad for first attempt. After the exam, you do not get report of the question which you did not answer correct but you do get a consolidated report on the areas with your scores. Mine looked something like this. This at least helps me to focus on specific areas for Scrum.

Scrum Score

Tips and tricks to pass Professional Scrum Master Certification

Let’s be honest, there is no ready-made formula for success in any field and same applies here while you try to attempt get the certificate for Professional Scrum Master. And in fact, the certificate value just drops to nothing if you have not learned anything during the process.


Nevertheless, here are my two cents based on my own experience.

  1. Make sure you go through the official Scrum Guide written by Ken Schwaber & Jeff Sutherland thoroughly. The guide is very concise, but covers the essence of Scrum.
  2. I would suggest you to go through the Scrum Open Assessments (both and Scrum Master and Scrum Developer) multiple times before you are scoring 95% or more consecutive time. The open assessment has a set of approximate 40 questions. Out of which 30 questions are presented in an assessment.The assessment will give you an idea of questions which would be asked in the actual assessment. Additionally, you would find some of the questions from open assessment repeated in the actual assessment. This gives you surplus time and confidence during the examination.Personally, I found 10-15 questions being repeated in the actual exam.
  3. Don’t look around on internet for dumps of questions. You are not going to find any. And even if you do, then what’s the point of giving exam and get credentials? You could better create a Photoshop version of certificate to boss around.
  4. PSM I Simulated Exams from Management Plaza is a good tool to evaluate your preparation and readiness for the PSM I Exam. The simulator not only contains a set of 250 practice questions but also explains each and every answer.

    Thanks to team at Management Plaza who have offered a discount coupon of up-to 20% on purchase of their learning courses. Don’t forget to use the coupon code “manas2018” to get benefit from this offer.

  5. Everyone has their own preference over books, I went through the ‘A Guide to the SCRUM BODY OF KNOWLEDGE (SBOK™ GUIDE), 2013 Edition’. It’s to the point and gives you decent read before the exam.
  6. The Scrum Master Training Manual from Frank Turley and Nader K. Rad is another resource guide which compliments the original Scrum Guide. It has a lot of practical examples which are important from the exam point of view. One thing which I liked in the manual is the explanation of burn-down charts which is not explicit in the Scrum Guide. And ofcourse, it’s FREE!
  7. Go through the discussions on Scrum Forum. You would find a lot of people discussing their experience and queries on this forum. Group of folks here are willing to help you if have questions.  A great place to hang around for Scrum enthusiasts.
  8. During the exam, don’t try to Google (or Bing) around for the answers. First, you won’t find any. Second, there is no guarantee that the answer is right. Third, you would be wasting your time. Keep in mind that you need to complete 80 questions in 60 minutes. That gives you 45 seconds per question. Yes, you need to be fast.
  9. And yes, make sure you have an isolated place where you can concentrate while giving the examination. As the examination is online, you need to have a good and consistent internet connection in place. Have a glass (or two) of water with you. You would feel thirsty during the exam. Psychological? Not sure!

Good luck to those of you who are preparing and attempting for PSM!

And while you are here, you can read my earlier related posts on Scrum and Agile.

A beginner’s guide to Scrum

The curious case of Scrum Master’s role

An introduction to Agile Methodology

A beginner’s guide to various Software development methodologies

PSM Certification Guide

The curious case of Scrum Master’s role

At the very core, both agile manifesto and scrum are frameworks and not a detailed method or process. This was intentional because the founders of scrum wanted to keep it as lightweight framework which can be used by the organizations to develop the software with value.

However, the reason often leads to different interpretations of scrum and sometimes leads to the result which is completely against the scrum framework.

There are three distinct roles which identified within the Scrum methodology:

  • The Scrum master, who ensures the process is followed, removes impediments, and protects the Development Team from disruption.
  • The Product Owner, who represents the stakeholders and the business.
  • The Development Team, a cross-functional, self-organizing team who do the actual analysis, design, implementation, testing, etc.


And one of the most misunderstood role in scrum team is of Scrum Master. Before we go more into details of Scrum Master, if you are interested to read about the fundamentals of Scrum and the various roles defined in a Scrum team, refer to my previous post ‘A beginners guide to Scrum’

A whole lot of development organizations and teams are using scrum these days. Having said that, I have noted that most of these teams use scrum as a planning methodology focusing only on the daily scrum meetings and/or sprints. And just because it’s fashionable to say that the project follows scrum approach, someone from the team takes the responsibility of being a scrum master. In most of the cases, as the world ‘master‘ is involved, it is either the erstwhile project manager or the architect/lead developer of the project.

Scrum Master is not Project Manager

By definition, project managers have the responsibility of the planning, execution and closing of project. In addition, project manager is often a client representative and has to determine and implement the exact needs of the client, based on knowledge of the firm they are representing. A project manager is the bridging gap between the team and client.

On the other hand, a scrum master does not have any responsibility of planning and delivery of the project. The main focus of a scrum master is to make sure that he removes any impediment or blockage which comes in the way of development team.

Scrum Master is not Lead Developer

The Development Lead’s role is focused on providing more detail to the Solution Architect’s architecture. This would include creation of detailed technical design, program specifications etc. The Development Lead is also the first line of support for the developers who need help understanding a concept or working through a particularly issue. The Development Lead does not need to be hierarchically up in the organizational chart and is not responsible for the administrative work of the employees. Their primary focus is on helping the developers to deliver the quality software on time.

There has been a real debate and questions coming in if the Scrum Master should know the technical details of the software development.

It’s completely OK if the scrum master does not understand a single bit of architecture, technical design or other details of the software project.

The real focus of a scrum master is on the process and not the details of the work which development team is responsible. However, if the development team is stuck with a technical impediment which they can not solve themselves then they should contact scrum master. For e.g. it could a technical or architectural decision which they are not sure how to progress with. In such case, a scrum master can reach out to other parts of organizations or even outside organizations to make sure development team gets the answer and they can continue with.

So, Who exactly is Scrum Master?

Schwaber & Sutherland gave a precise definition of Scrum Master role in the scrum guide without detailing the day-to-day activities.

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

Scrum master is for sure not a project manager and/or a development lead. He does not manage people and he is not someone to whom people should be reporting (in context of Scrum). Having said that, it should be noted that Scrum Master is a management position. Scrum Master should have organizational management powers and ability to reach other parts of the organization to make sure he is able remove any impediment faced by the team.

Scrum Master is a shield for the development team so that they focus on what they should be doing and continue the same. A Scrum Master makes sure that the product owner is aware of the scrum process and acknowledges the structure of the framework to formulate and prioritize the product/sprint backlog.

At the same time, I am a believer that scrum master is a role rather than a position.

Have you also observed similar situation where the Scrum Master role is mingled or is not properly defined in your organization?

An introduction to Agile Methodology

Agile is one form of software development methodology. Its main focus is on client satisfaction through continuous delivery. The focus of Agile is more on limiting the project scope. An agile project sets a minimum number of requirements and turns them into a deliverable product.
Agile development methodology provides opportunities to assess the direction of a project throughout the development lifecycle. By focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology is described as “iterative” and “incremental”. In waterfall, development teams only have one chance to get each aspect of a project right.
(Haag & Cummings, 2009) says an agile project sets a minimum number of requirements and turns them into a deliverable product. Agile means what it sounds like: fast and efficient; small; lower cost; fewer features; shorter projects.
In February 2001, the Manifesto for Agile Software Development (The Agile Manifesto, 2001) was created by seventeen people with desires to find alternative approaches to software development. Each of them played a prominent part in the opposition of the prevailing software development processes, which they considered rigid, heavyweight and too focused on documentation. Their response, summarized in the manifesto, clarifies their focus by valuing:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

In agile literature, agile methods generally denote a family of methods under the umbrella of the Agile Alliance, including: extreme Programming, Scrum, Dynamic Systems Development Method, Crystal Methods, Feature-Driven Development, Lean Development and Adaptive Software Development. Although differing in specific techniques, these methods have much in common, including short iterative life cycles, quick and frequent feedback from customers, and constant learning. Among them, Scrum and XP/Scrum hybrid are by far the most widely adopted in the past decade. Agile processes bring about a dramatic increase in productivity and quality. This is achieved through a high degree of communication and interaction, short iterative development and a strong sense of team responsibility.
However, there have been some criticism of agile as well.

(Kruchten, 2011) compared agile methodology to a teenager: very self-conscious, checking constantly its appearance in a mirror, accepting few criticisms, only interested in being with its peers, rejecting en bloc all wisdom from the past, just because it is from the past, adopting fads and new jargon, at times cocky and arrogant.

(Boehm & Turner, 2004) convincingly argue that there is a pragmatic need to balance stability and agility. They analyze the home grounds of agile and traditional approaches based on application characteristics, management characteristics, technical characteristics, and personnel characteristics. Further, they assert that the choice of traditional or agile methods for a given project is largely contingent on five factors:

  1. The size of the systems development project and team
  2. The consequences of failure (i.e., criticality)
  3. The degree of dynamism or volatility of the environment
  4. The competence of personnel
  5. Compatibility with the prevailing culture

(Krill, 2013) also pointed out that barriers to agile adoption include an inability to change an organization’s culture, followed by general resistance to change and trying to fit agile into a non-agile framework. The framework for organizational change articulated by Adler and Shenhar (1990) is useful for assessing the effort required to meet these challenges. The biggest concerns about agile include lack of upfront planning, loss of management control, and management opposition. Other reasons include communication problems between development teams and other areas of the business and problems with the Scrum master.

Framework for Organizational Change (Adler & Shenhar, 1990)

Further Reading

A Beginners Guide to Scrum

Cohn, M., 2010. Succeeding with Agile. 1st ed. Boston: Addison-Wesley.

Wanga, X., Conboyb, K. & Cawley, O., 2012. “Leagile” software development: An experience report analysis of the application. The Journal of Systems and Software, Issue 85.

A beginner’s guide to Scrum

Introduction to Scrum

Scrum is an iterative and incremental agile software development method for managing software projects and product or application development. Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication between all team members and disciplines in the project. Three distinct roles are identified within the Scrum methodology:

  1. The Scrum master, who ensures the process is followed, removes impediments, and protects the Development Team from disruption
  2. The Product Owner, who represents the stakeholders and the business
  3. The Development Team, a cross-functional, self-organizing team who do the actual analysis, design, implementation, testing, etc.

The development cycle of a software project is broken in to time boxed units which are called sprints. A common time frame for one sprint is one week. Every day within a sprint the progress of the project is evaluated.


Requirements of the final product are maintained in a list called the backlog (product backlog). In each sprint one or more requirements will be implemented (sprint backlog) after which the next sprint is started.


Scrum Master

Scrum is facilitated by a Scrum Master, sometimes written as ScrumMaster, who is accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables. The Scrum Master is not the team leader, but acts as a buffer between the team and any distracting influences. The Scrum Master ensures that the Scrum process is used as intended. The Scrum Master is the enforcer of rules. A key part of the Scrum Master’s role is to protect the Development Team and keep it focused on the tasks at hand.

Product Owner

The Product Owner represents the voice of the customer and is accountable for ensuring that the team delivers value to the business. The Product Owner writes customer-centric items (typically user stories), prioritizes them, and adds them to the product backlog. Scrum teams should have one Product Owner, and while they may also be a member of the development team, it is recommended that this role not be combined with that of Scrum Master.

Development Team

The Development Team is responsible for delivering potentially shippable product increments at the end of each Sprint. A Development Team is made up of people with cross-functional skills who do the actual work (analysis, design, develop, test, technical communication, document, etc.). The Development Team in Scrum is self-organizing.


A sprint is the basic unit of development in Scrum. Sprints last between one week and one month, and are a “time boxed” (i.e. restricted to a specific duration) effort of a constant length.

Each sprint is preceded by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made, and followed by a review or retrospective meeting, where the progress is reviewed and lessons for the next sprint are identified.

During each sprint, the team creates finished portions of a product. The set of features that go into a sprint come from the product backlog, which is a prioritized list of requirements. Which backlog items go into the sprint is determined during the sprint planning meeting. During this meeting, the Product Owner informs the team of the items in the product backlog that he or she wants completed (the ones with the highest priority). The team then determines how much of this they can commit to complete during the next sprint, and records this in the sprint backlog. During a sprint, no one is allowed to change the sprint backlog, which means that the requirements are frozen for that sprint. Development is time boxed such that the sprint must end on time; if requirements are not completed for any reason they are left out and returned to the product backlog. After a sprint is completed, the team demonstrates how to use the software.

Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication between all team members and disciplines in the project.

A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredictable challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements.


Daily Scrum

Each day during the sprint, a project status meeting occurs. This is called a daily scrum, or the daily standup. This meeting has specific guidelines:

  • The meeting starts precisely on time.
  • All are welcome, but normally only the core roles speak
  • The meeting length is set (timeboxed) to 15 minutes
  • The meeting should happen at the same location and same time every day

During the meeting, each team member answers three questions:

  • What have you done since yesterday?
  • What are you planning to do today?
  • Any impediments/stumbling blocks?

It is the role of the Scrum Master to facilitate resolution of these impediments, although the resolution should occur outside the Daily Scrum itself to keep it as short as possible.

Sprint planning meeting

At the beginning of a sprint, a “Sprint planning meeting” is held.

  • Select what work is to be done
  • Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team
  • Identify and communicate how much of the work is likely to be done during the current sprint

The team should spend time during a sprint doing backlog grooming. This is the process of: estimating the existing backlog using effort/points, refining the acceptance criteria for individual stories, and breaking larger stories into smaller stories.

  • Meetings should not be longer than an hour
  • Meeting does not include breaking stories into tasks
  • The team can decide how many meetings are needed per week.

Sprint review meeting

  • Review the work that was completed and not completed
  • Present the completed work to the stakeholders (a.k.a. “the demo”)

Sprint retrospective

  • All team members reflect on the past sprint
  • Make continuous process improvements
  • Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?

Scrum of Scrums

Each day normally after the Daily Scrum.

These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration.

  • A designated person from each team attends.
  • The agenda will be the same as the Daily Scrum, plus the following four questions:
  • What has your team done since we last met?
  • What will your team do before we meet again?
  • Is anything slowing your team down or getting in their way?
  • Are you about to put something in another team’s way?


Team Foundation System has integrated scrum support. With the Microsoft Visual Studio Scrum 1.0 template it is possible to maintain a product backlog, scope the sprints, define tasks, assign tasks and create several reports to monitor the progress of the sprint and the project.

The Scrum tools in TFS can either be accessed from Visual Studio or by using a web interface. The latter is useful for testers and project managers who do not have access to Visual Studio. Furthermore the web interface exposes some batch processing commands not available in Visual Studio.


Scrum is a suitable method to support development process. It is very efficient in creating solutions with the highest business value in the shortest possible time. Due to the daily scrums any impediments are known to everyone as they occur making it possible to resolves them as quickly as possible. Furthermore it adds support to prioritize work and closely monitor the progress of a project with little to no overhead.

References and recommended reads