Agile Scrum Crash Course
Discover How to Get the Professional Scrum Master Certification PSM1 and
Boost Your Team’s Effectiveness With Agile Project Management
Liam Taylor
© Copyright 2020 - All rights reserved.
The content contained within this book may not be reproduced, duplicated or
transmitted without direct written permission from the author or the
publisher.
Under no circumstances will any blame or legal responsibility be held against
the publisher, or author, for any damages, reparation, or monetary loss due to
the information contained within this book, either directly or indirectly.
Legal Notice:
This book is copyright protected. It is only for personal use. You cannot
amend, distribute, sell, use, quote or paraphrase any part, or the content
within this book, without the author or publisher’s consent.
Disclaimer Notice:
Please note the information contained within this document is for educational
and entertainment purposes only. All effort has been executed to present
accurate, up to date, reliable, complete information. No warranties of any
kind are declared or implied. Readers acknowledge that the author is not
engaged in the rendering of legal, financial, medical, or professional advice.
The content within this book has been derived from various sources. Please
consult a licensed professional before attempting any techniques outlined in
this book.
By reading this document, the reader agrees that under no circumstances is
the author responsible for any losses, direct or indirect, that are incurred due
to the use of the information contained within this document, including, but
not limited to, errors, omissions, or inaccuracies.
Introduction
Who Is This Course For?
Preparing for Certification
Agile Basics
History of Agile
12 Principles of Agile
Main Agile Frameworks
Waterfall vs. Agile
Review and Exercises
PSM1 Exam Example Questions
Answers
Scrum Basics
Pillars of Scrum
Key Values of Scrum
Scrum Basics
Timeboxes
Sprint
Product Backlog
Review and Exercises
PSM1 Exam Example Questions
Answers
Scrum Events
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective
Review and Exercises
PSM1 Exam Example Questions
Answers
Accountabilities
Scrum Team
Scrum Master
Product Owner
Developers
The Stakeholders
Review and Exercises
PSM1 Exam Example Questions
Answers
Scrum Artifacts
Product Backlog
Sprint Backlog
Product Increment
Burndown Chart
Definition of Done
Users Stories
Definition of Done vs. Acceptance
Review and Exercises
PSM1 Exam Example Questions
Answers
Scrum 2017 vs. Scrum 2020
Changes Over Time
2017 vs. 2020 Comparison
Review and Exercises
PSM1 Exam Example Questions
Answers
How to Pass the PSM1 Exam
How to Pass the Exam
Exam Structure
Review and Exercises
PSM1 Exam Example Questions
Answers
Conclusion
Resources
About the Author
My name is Liam Taylor and I am a Software Engineer since 2002 and I am
always been interested in Leadership and Agile Frameworks. I have worked
as a CTO and a team leader for the past 10 years and I am currently the team
leader of one of the most influential companies in the world.
First of all, thank you for purchasing this book. I know you could have
picked any number of books to read, but you picked this book and for that I
am extremely grateful.
I hope that it added at value and quality to your everyday life.
If you will enjoy this book and find some benefit in reading this, I’d like to
hear from you and hope that you could take some time to post a review on
Amazon. Your feedback and support will help this author to greatly improve
his writing craft for future projects and make this book even better.
I wish you all the best in your future success!
Introduction
First off, congratulations on deciding to take the PSM1 certification exam.
This certification will validate you as a Professional Scrum Master. However,
before you can claim this title, you must first prepare and study for the PSM1
certification exam.
The purpose of this crash course is to provide you with a comprehensive
introduction to Agile and Scrum. This course is very intense and will require
100% of your focus and willingness to review and reflect on what you
learned in order for you to be prepared and pass the exam.
This course will cover the Agile and Scrum basics, such as the Waterfall vs.
Agile software methodology, the main agile frameworks, the 12 principles of
agile, the goal of timeboxes, sprints, the daily Scrum, the effectiveness of
Scrum, and much more. In an ever-changing technological world, having an
understanding of Agile and Scrum as a whole will make you even more
qualified to handle projects in this field.
Who Is This Course For?
This course is aimed at those who are about to take the PSM1 examination, as
well as those who have already taken the exam but failed to achieve
certification. Some of you may already have a basic understanding of the
agile methodology and Scrum framework, but the information presented here
will provide you with a useful recap so you can polish your skills concerning
the topic.
Furthermore, this course can be beneficial to those of you who are
considering a career in this field and would like to get a basic breakdown on
the topic. For example, when you hear the words “Agile Scrum” together,
you might think it is referring to one topic and that both terms means the
same thing.
Well, that’s where you’re wrong. Agile or Agile software development, to be
particular, refers to a collective term for working and developing software
based on a set of values and principles, which has become the norm for those
in the software industry (Naik & Jenkins, 2019). On the other hand, Scrum is
a framework of the Agile software development methodology, and it focuses
on creating high-quality software in a short period of time (Kurnia, Ferdiana,
& Wibirama, 2018). As you can see, Agile and Scrum are totally two
different things, but don’t fret as the following chapters will cover both sides
of the spectrum.
Preparing for Certification
Now that you have a brief understanding of the differences between Agile
and Scrum, let’s take a look at the PSM1 Certification Exam. The PSM1
Exam has a total of 80 questions, and you will only have 60-minutes to
complete the entire exam and answer the questions correctly. Therefore,
we’ve provided exercises at the end of each chapter to test your
understanding of the subject and provide you with the practice you need to be
prepared.
You can add an additional challenge to the exercises by setting a 45 second
timer to answer each question separately. This will prepare you for when you
take the real exam and make sure you work quickly enough when answering
questions. The minimum passing score for the exam is 85%, but this course is
not aiming to meet the minimum, although it’s still good, but to help you get
90-100% on the first try.
Chapter 1
Agile Basics
Since the recent advancements in technology, Agile Development has
become the new framework for developing high quality software. What is the
reason you might ask? Well, Agile development is based on the idea that
when a project is managed by a disciplined group of people, working
together, the project is likely to be of high-quality.
Because of this methodology, technology companies such as IBM, Google,
Apple, and 3M have adopted the model into their software building process
(Barcelos & Silva, 2020; Kurnia et al., 2018). Not only does using the agile
process make it easier for tech companies to plan projects, but it also makes it
easier to build effective software and electronics according to the customer’s
specifications.
As a professional engineer and developer, it is important for you to
understand the additive and iterative phases that you will experience while
using the agile development method. It is a continuous process of improving
the software and seeking the feedback of customers to reach the final point in
the software development process (Barcelos & Silva, 2020). Agile may seem
like a complicated process, but once you have an understanding of the
method, it will come as second nature.
In fact, some organizations avoid using the agile development process due to
issues that arise with management and organizational culture, employee work
relationship, adapting or changing from a process-centric development to
feature-drive, and suitable technologies due to availability (Barcelos & Silva,
2020). Thus, not everyone agrees with the method, but because of its
effectiveness in software development, many companies are adopting the
different methodologies surrounding agile which will be discussed later on.
History of Agile
To fully understand Agile, you must first understand the history behind the
method. The agile development process was first introduced by William
Royce in 1970 (Alexander, 2018). Royce published a paper on the agile
method for developing larger types of software systems, which garnered mass
attention from the technology industry. Royce's paper simply explained how
agile can be utilized in technology based on old and new methods, including
the Waterfall method.
The reason Royce wrote this paper is because during the time around the
1970s to the 1980s, computers and software were coming into existence
(Varhol, 2015). However, the process or system that was in place did not
provide Developers with the freedom or flexibility to work on these
development projects quickly and effectively. Royce defined the Agile
methodology to offer a better system and method in which Developers could
be used as a principle in their working field.
Even the aerospace industry was having issues with the current system. In
fact, it was predicted at the time that it would take 20 or more years for a new
system to go into use. For example, the Space Shuttle program launched an
operation in 1982; however, they already had the data ready back in the
1960s but didn’t have the proper system to put it into place earlier.
Then around the 1990s, things got even worse as PCs were now operating in
households and companies were moving faster. However, the software
development system was too slow, which led to many projects being
canceled halfway through the process, and the ones that were completed were
not able to meet the business’s needs (Varhol, 2015).
Jon Kern, who was Aerospace engineer in the 1990s, was fed up with the
system and the long times that it was taking to get a project moving forward
or to make a decision. He would later join a group who were working to fix
this system (Varhol, 2015). This group would come to be known as the 17
software thought leaders who changed the game of building software, and
John Kern was one of them.
Although Royce’s paper made big waves in the technology community, the
term was not fully defined. As the year 2001 approached, the 17 software
developers introduced the Agile Manifesto (Alexander, 2018; Saha, 2019).
The developers wanted to create a proper combination of the agile
methodology based on old and new ideas, which would help future
developers to effectively develop their product.
After countless discussions and a lot of research, the 17 software developers
created a set of principles and values that comprised the Agile Manifesto. The
manifesto describes Agile as a mindset rather than a methodology (Saha,
2019). It serves as a guide for developers and engineers to become agile
thinkers and performers when working on various projects.
Nonetheless, with any type of change or implementation of a new program
there is likely to be disagreements. The Agile Manifesto received some
backlash because some people thought that this new methodology was
criticizing the other methodologies that came before it (Varhol, 2015).
However, that was far from what Jon Kern and the other 16 software
developers were trying to do. They wanted to offer software developers, in
this case, the opportunity to use a method or approach that works for them.
However, looking at it today, the Agile methodology has grown and
improved over the years. One of the major benefits of the Agile method is
that it has helped improve the rapidity of the software development system.
Moreover, it allows developers to identify issues or new insights into the
development of a product (Alexander, 2018). They can also make
adjustments and do a 360 turnaround on the project to remove any defects or
malfunctions due to bad programming.
Furthermore, in the past, the developers took years to finish one project. The
Agile methodology provides a way for the developers and teams to deliver a
greater product in a fast manner (Alexander, 2018). This is based on short but
effective iterative, interactive meetings, and sprints. The Agile method can
help companies with processing volumes of information and finding a perfect
methodological alignment.
The biggest pro of the Agile Methodology is that it offers more rapid
solutions. The developers will never again run into issues when making a
decision unless they do not follow the principles of the Agile methodology.
They are able to minimize waste through the minimization of the resources
that are needed and have fast turnarounds that have a lighter framework.
They can also optimize development, obtain optimal project control, and
faster detection of issues and defects.
The negative drawback of the agile method is that it is not suited for every
project. The reason is that agile may not fit the business setup due to how
customers request products or due to the lack of experience with agile among
the staff. Furthermore, if you have a customer that is not clear about the goals
they want the project to attain, then this is going to lead to further fallback in
the project.
12 Principles of Agile
The Agile Manifesto contains 12 principles that developers must follow.
These principles provide an idea of the type of culture technology companies
are building based on the principles they apply among their engineers and
developers (Eby, 2016). Furthermore, the principles focus on welcoming
change and making the customers the focus of the developers’ reason for
building the software.
The 12 principles of Agile Software Development:
1. Satisfying the customers’ needs by delivering highly valuable
software continuously and efficiently. Customers feel a great
sense of appreciation when they are able to receive working
software regularly, rather than waiting extended periods of time
(Alexander, 2018; Eby, 2016). Thus, meeting their expectations
is important.
2. Embrace change in the agile process so that customers have a
competitive advantage. Professional Agile Masters should
welcome change with no hesitation when a requirement or
feature of the software is in need of changes.
3. Delivery should always be of high frequency. This principle
interrelates with the Scrum process in which the team operates in
sprints to deliver quality software on time.
4. Stakeholders and Developers must work as a team during the
development process. The reason is that collaboration with
Stakeholders and Developers leads to better choices and
successful software.
5. Motivation is key to supporting an agile environment. As the
saying goes, a motivated team is a productive team. Creating an
uplifting environment where each member feels energized will
lead to better results.
6. Information and ideas are better-expressed face-to-face. The
most efficient way to get an understanding within a group is to
communicate face-to-face. This will lead to a better work
relationship and trust among team members.
7. A high-quality working product leads to returning customers.
When the product performs as it should, this creates success
within the company.
8. Sustainability is achieved through the Agile process. When the
Stakeholders and Developers are able to repeat the process on
future projects, this promotes a continuous repetition of pace.
9. Agility is enhanced based on attentiveness to the detail and
design of the software. Applying the right skills and effective
designs leads to the agility to build better products.
10. Keep it Simple Scrum. Maintaining a simple idea is enough to
complete the process.
11. Self-disciplined teams lead to better architectures, requirements,
and designs. Thus, having team members who are self-managed
can lead to better teamwork.
12. Reflect and project. Regularly reflecting on successes and
failures can lead to self-improvement, improved skills, and better
techniques to work effectively (Alexander, 2018; Eby, 2016).
Hence, reflection is key to success.
When Developers are able to align themselves to these principles, this leads
to a better outcome for the project. Moreover, the customers can enjoy the
benefits of the agile development methodology since it provides them with
high-quality technology or software. This was the goal the 17 developers had
in mind upon creating the Agile Manifesto.
However, besides the 12 principles that make up the Agile Manifesto, there
are four foundational values that focus on the Agile development process.
These values are also connected to each of the agile methodologies, which
guides the creation of high-quality software. Those four values are based on:
1. Individuals and Interactions over Processes and Tools. Placing
value on individuals rather than processes and tools is common
sense because individuals are the ones who provide the monetary
needs to companies in the development process (Eby, 2016).
Therefore, valuing the individual needs in communication or
interaction can be beneficial to processes and tools.
2. Working Software over Comprehensive Documentation. Before
the Agile method was set in place, developers and technicians
spent countless hours documenting specifications, development,
prospectus, and design without focusing on the development of
the software. The Agile Manifesto replaced this tedious process
by making user stories the documentation for product
development and improvement.
3. Customer
Collaboration
over
Contract
Negotiation.
Collaborating with customers during the development stage or
before development leads to customer involvement. Negotiation
comes into play when the customers are able to negotiate the
requirements for the product.
4. Responding to Change over Following the Plan. Changes
provide additional value to the product since they focus on
offering better and improved features. Whereas following a plan
based on the traditional software was too complicated to carry
out. Therefore, concentrating on change is key to the agile
development process.
Having a clear understanding of these values promotes the Agile Manifesto
mindset. Developers and Engineers who’ve mastered the four values along
with the 12 principles can create an effective and progressive working team
when developing products. If the Agile Method did not exist today, and if not
John Kern along with the 16 other software developers didn’t come up with
the Agile Manifesto, technology companies would still be finding it difficult
to develop working software.
The chances of those 17 software developers codifying a process is not seen
or possible. However, they were determined to offer developers struggling
just like them a process and way they could get the work done without any
hassle or postponing for years to come. If you take a look at news articles
relating to Agile, you’ll see that the software development community has
made this their thing (Alexander, 2018; Varhol, 2015). You will find not one
team that doesn’t apply the Agile Manifesto 12 principles, the definitive
statement of building software, and the movement Agile created.
Moreover, more and more businesses are beginning to identify themselves as
using the Agile methodology. You do have some who are combining
different methods to create hybrid versions of the methodology, but they all
still identify with the Agile Manifesto. In all honesty, the Agile methodology
took the software and technology industry by storm. However, because of
this significant change, there is bound to be another system that will be
introduced at some time in the future. The main thing is that learning about
the origin of this methodology will prepare you for future Agile methods.
You are already taking the first step with this course. The Agile process is the
first step that you must master in order to move on to the Agile Scrum
Methodology. Do not be afraid to choose a methodology that will fit you
once you enter the market to work as a Professional Scrum Master. The Agile
methodology did not come about because everyone follows one
methodology, such as the Waterfall method. It came about because a small
group wanted a better system and a better outline of how to work, and they
were able to accomplish that and create a space where others could create
mixed or hybrid versions of the method.
Main Agile Frameworks
Within the last two decades, Agile has become the most successful software
development framework. Consequently, this success has led to various Agile
frameworks and approaches. According to Mersino (2019), the most popular
frameworks in agile methodologies are Scrum, XP, Kanban, and hybrids.
There are other frameworks that exist but are no longer favorable.
The frameworks that are still in use today but are not popular include: Crystal
and Dynamic Systems Development Method, Feature Drive Method,
Adaptive Software Development, Agile Software Development, Behaviour
Driven Development, and many others that were not mentioned in this group
(Alexander, 2018; Mersino, 2019; Naik & Jenkins, 2019). As you can see, the
Agile development process expands into various methodologies.
However, this course will focus on the main agile framework which is Agile
Scrum in the next chapter. Nonetheless, a brief introduction will be given
here on the main frameworks to better understand the diversity of the Agile
methodology.
The first framework is called Crystal. This framework is somewhat of a
hybrid due to its variants in the Agile methodologies (Lamelas, 2018). The
principles of the Crystal framework are based on people, community, talent
and communication, and interactions. It was founded by Alistair Cockburn
who had the idea that Crystal should center around team members'
interactions when it comes to the software development process.
The second main framework is Lean Development. This Agile methodology
was created by Toyota and was based on Lean Manufacturing. The
framework's main principles are getting rid of things that have no
significance, such as things that do not bring value to the customer’s project.
Other principles include quality development to control the quantity
developed, creating knowledge to maintain the infrastructure, defining
commitment, fast delivery, respecting the team, and optimizing the entire
process.
The third framework is Extreme Programming (XP). This framework was
created by Kent Beck and focuses on communication, feedback, respect,
courage, and simplicity. In this framework, teamwork is valued because most
issues that are likely to occur in developing software can be solved by the
team as they work together. However, there is a story about how this method
came about. According to Varhol (2015), Beck was hired as a consultant to
work on an experimental software development project with Chrysler. During
his time there, he became known as the project leader since he would always
go to extreme levels to improve practices.
Thus, the XP methodology was born. However, he could not release this new
method immediately because Chrysler decided to cancel the project since
they had been acquired by another automobile company. Beck decided that it
would be best to publish his new methodology in a book called Extreme
Programming Explained, and from this point he became a founder of a
software development methodology like the 17 software developers. He even
went on to hold public speaking events where he gave keynote speeches
about the XP methodology (Varhol, 2015). It has been noted that this method
is based on the Agile methodology, but Beck never drew any relevance or
mentioned how he developed the process.
The fourth framework, according to Lamelas (2018), is Kanban, which is
another Agile methodology. Kanban comes from the Japanese language, and
it is linked to a time concept. The method focuses on team members being
transparent and communicating with each other to understand the
development stage of the product. The method was created by Taiichi Ohno
and a version of it has been around since the 1940s. However, Ohno, who
was an industrial engineer and businessman, wanted to create a working
system for the automotive industry in Japan. From there, he was able to
create a solid idea of Kanban, which is how this method came to be known.
The fifth and final main Agile framework is Scrum. Scrum is generally
preferred by most teams and developers due to the framework being based on
cycles of development. This framework’s principles focus on sprints and
provide tons of motivation to team members. The creators of the method
named it after a term in Rugby, which is why it has the concept of a team
working together to reach a common goal in software development (Varhol,
2015 Alexander 2018). The creators of this methodology codified it around
1995 so that they could make the work public by showcasing the Scrum
method at a conference in Texas.
Most of the frameworks focus on the same issue, but they provide a variance
in method. Per Mersino (2019), 54% of organizations preferred Scrum, while
14% preferred other hybrids, 10% Scrum and XP hybrid, 8% ScrumBan, 5%
KanBan, 3% preferred Iterative Development or was unsure, while 2% chose
Lean Startup, and 1% Extreme Programming (XP). Thus, Scrum is the
preferred Agile Methodology. However, how does it compare with a
traditional methodology known as Waterfall?
Waterfall vs. Agile
The Waterfall Methodology is the traditional methodology that developers
and engineers used before the Agile Method. This method was the beginning
of the technological approach to developing software (Lotz, 2018; McKnight,
2014). In 1970, Winston W. Royce provided an in-depth definition of the
term Waterfall Methodology, which quickly became popularized.
Waterfall is based on a linear method, where planning is the key to building
software. In fact, companies sometimes use the Waterfall method to juggle
one or more phases in the development process. The Waterfall Methodology
is considered better when it comes to planning out projects without rushing
through the process (Alexander, 2018). This helps the team avoid errors or
mistakes in the development process.
In Royce’s paper, he showed that the Waterfall methodology fundamentals of
software development are based on the fact that all value comes from
software delivery (Hering, 2015). Moreover, the value in software delivery
comes from the analysis conducted and the coding put into place when using
this method. He emphasized that everything else focuses on documenting and
testing and that implementing this thinking is fundamental to managing the
process and customers’ expectations. Furthermore, it was made clear that in
order to get customers to pay for the quality of software, the developers have
to provide that for them to see.
The traditional Waterfall steps involve gathering and documenting
requirements, designing, coding and unit testing, initiating system testing,
performing user acceptance testing, fixing issues, and delivering the finishing
product (Lotz, 2018). The process may seem long and detailed, but it helps
get the project completed, and some developers preferred this traditional
process.
The Waterfall Methodology actually represents a waterfall because it
involves completing one phase fully, then moving on to the next phase, until
all the requirements have been met (Varhol, 2015). In other words, the teams
are working in a downward flowing direction. Since the process requires that
the first task be done correctly and fully before beginning the next stage, this
has saved teams from making any revisions. However, the issue with this
methodology is that it takes developers too long to complete.
Royce even mentioned in the paper that the Waterfall model is fundamentally
flawed and that the stages are not really guaranteed to be successful (Hering,
2015). The system’s iterative process does not fully repeat all the steps
because it skips some as the developer goes over them. Royce understood
that this issue was a flaw within itself. However, he was able to correct this
with the Agile methodology. Even so, the Waterfall method was still a good
method because it created the first system that developers could rely on to get
their projects completed.
Another thing that was emphasized in Royce’s paper was the importance of
documentation. Documentation is important in the software development
process, especially with the Waterfall method because you can see how
everything was done, what steps were taken, what had to be corrected, where
things went wrong, and so on. The documentation process may seem tedious
and long, but it was helpful at the time since it provided clarity and a way for
developers to repeat the process again in other projects they were working on.
Lastly, Royce’s paper provided solutions and a different model of the
Waterfall method, which most developers have found complicated. However,
the system created showed a few agile practices, early customer involvement,
two iterations in the software process, and testing. The Waterfall system he
created at the time may seem confusing, but the Waterfall methodology is
still in use today, which means that some developers understood the
complexity of the model more than others.
Early on, when the method was first introduced to the development world.
Engineers, Developers, and Software programmers found it to be better than
the approach they were utilizing at the time. However, as time went by, a
better system was created that could eliminate the original framework
(Alexander, 2018; Varhol, 2015). The Waterfall method was able to bring
organization to developers, but it takes too long for them to complete. For
example, imagine if your city was currently building a new train track, but it
would take 20 years to complete due to the system that they’re using.
The Waterfall method may still be a good method for building roads,
railways, or bridges. The method can be used to work on long-term projects
so that they do not tie up time. The positive outcome of the Waterfall method
is that customers and developers get to decide together on what will be the
final product early in the software lifecycle. Furthermore, developers can
easily document their progress and the documentation provides access for
various team members to work on different phases of the product to get it
complete in time.
The negative aspect of the Waterfall method is that it incurs too many
expenses and risks to be considered effective, and revising to get a better end
product requires repeating a lot of the original work (Lotz, 2018; McKnight,
2014). Also, sometimes the customer might not like the end product, so this
can lead to additional drawbacks and more problems with this method. This
was the main reason why the 17 developers came together with the Agile
Manifesto.
Now, we have the Agile Methodology, which focuses on an iterative process.
The main benefits of this method are that customers are constantly involved
in the process from the planning to the development. What’s more, the
customer develops a sense of ownership over the software, since they are
frequently adding input. Thus, as it comes time for the product to enter the
market, the Agile process allows developers to release beta versions of the
software which can be improved over time.
The negative side of the Agile method is that customers become too involved
in the development of the software. Feedback can be a great thing, including
criticism, but too much of it can lead to a failed product or a non-completed
project. Another disadvantage is that the Agile methodology can only work
effectively when each team member is fully committed to the product
development.
The same applies if all the team members are living in different locations.
They have to be willing to invest their time attending meetings on time and
going through the iterative process, which can be hard for some. Therefore,
both methods have ups and downs, but the Agile method can be adapted to
any method—including the Waterfall methodology—to make up for the
approach’s flaws.
Review and Exercises
So, you completed the first phase of this course, hooray! Now, here are a few
things to remember about Agile, and of course Waterfall:
● Agile development is based on a disciplined group of people working
together to create high-quality software.
● Agile is an iterative process of improving the software and seeking
●
●
●
●
●
the feedback of customers to reach a final point.
The Agile Development process is based on 12 principles and four
values.
There are numerous frameworks based on the Agile Development
methodology.
The manifesto describes Agile as a mindset rather than a
methodology.
The Waterfall Methodology is considered better when it comes to
planning out projects.
The Waterfall is the traditional method for the software development
process.
Note: Although this section focuses mainly on the Agile and Waterfall
methodologies, this first part of the exam example questions is just to see
how much you know and what you need to work on. The following exam
questions will pertain to each chapter. After completing the course, give these
questions a second try to see how much you have learned.
PSM1 Exam Example Questions
1. Define Agile Scrum:
a. A system development methodology that is intended to enhance
software performance.
b. A lightweight framework that helps people, teams, and
organizations generate value through adaptive solutions for
complex problems.
c. A logical process that is used in the development of software,
which slows down the process.
2. Scrum Team must have the required talent to:
a. Convert the Product Backlog items into an increment based on
their usefulness and value for the product functionality.
a. Conduct the development work, except for specialized testing
which has additional requirements.
b. Finish the project as estimated, especially when the time and
expenses are based on the commitment of the Product Owner.
3. The Daily Scrum timeboxes are based on the size of the Scrum Team.
a. True
b. False
4. Concerning Definitions of Done, what should be considered? (Choose all
that apply.)
a. The Definition of Done based on the Teams working on other
software.
b. Guidelines, conventions, and standards implemented by the
organization.
c. Definition of Done concerning other Scrum Teams that are
working on the same project.
d. The knowledge of the Product Owner.
5. Scrum Teams need to have the same Sprint length if they are working on
the same product.
a. True
b. False
Answers
1. B. 2. A. 3. B. 4. B & C. 5.
Chapter 2
Scrum Basics
Scrum is considered the heartbeat of the Agile software development
framework. The reason is that Scrum was designed to be an easy but effective
methodology that software development teams could use to create highquality products in a short period of time. (Kurnia et al., 2018; Scrum
Alliance, 2019). This method combines iterative and incremental operations
to bypass issues that are often common with traditional methods, such as the
Waterfall methodology.
Iterative and incremental refer to two approaches that you will see mentioned
throughout this course. These two approaches have been around for years and
are used when working on larger projects (Kurnia et al., 2018; Scrum
Alliance, 2019). Iterative refers to the concept of developing software
through continuous repetitive cycles. While incremental refers to developing
small collections or units at a time that are delivered throughout product
development. Using these two together means that the software can be
developed within no time.
This also allows Developers to take advantage of the learning process so that
they can take what they learned into the next project. As they gain experience
with these practices, Developers are able to become quicker and faster in
these tasks. Implementation of the iterative and incremental approach allows
for them to make changes to the product and keep evolving until they are able
to deliver the same designs and modifications in every product that they
come across. However, to fully understand the iterative and incremental
approach, we’ll now provide more details on the two.
The iterative approach is a process for coming to the conclusion of a project
through constantly repeated rounds of analyzing and adapting the project.
With each stage of repetition, the team is looking to bring the product closer
to the working software they intended to build (Kurnia et al., 2018; Scrum
Alliance, 2019) The iterative process also involves setting up a simple
framework or method for redesigning the product.
They will continue revisiting the project with each iteration as modifications
are made, but it is a highly effective process. In the iterative process, the
Developers will fix a number of issues including the design and the coding as
well. The analysis of each iteration is based on the feedback coming from
users outside and inside the company. The analysis covers the usability,
reliability, modularity, and efficiency of the software as well as the
achievement of product goals.
The incremental approach involves making a series of small changes to the
project to improve its functioning. Incrementals are regularly used in the
technology industry, especially when companies need to improve their
product line or include new features for appealing to customers’ desired
preferences (Kurnia et al., 2018; Scrum Alliance, 2019). The incremental
process is work divided or sliced into pieces known as increments. For
example, a company could have software that requires some bug fixing,
building, user stories, and so forth. The increment stage takes this into
consideration, then starts building the software little by little until it is made.
Both these approaches connect within the Agile methodology. Iterative and
incremental software development enables an increase in features with each
cycle release and upgrade. The end result of the iteration is a fully working
product, which additional functionality can be added to in future increments.
Agile Scrum development, when implementing these two approaches, is
based on a short iterative cycle of 1-4 weeks. Furthermore, in this process,
the team can take the increments and make the changes to them one by one.
In other words, the Scrum methodology focuses on developing new, intricate
software, which can lead to good results, especially when the team is
provided with objectives rather than assignments. The Scrum Team is in
charge of how they intend to meet the objectives set forth. Scrum can also
define the timebox of the iterative process or the time within which working
software should be delivered. Any team can use this methodology to see
projects become simpler and more rapid than they were before.
The Scrum process also focuses on the versatility and satisfaction of the
customers based on the values, practices, and principles of the Scrum
methodology (Naik & Jenkins, 2019). Moreover, Scrum is built on a theory
that values lean thinking and empiricism. This means that teams can use their
experiences to make important decisions and concentrate their attention on
the essentials.
However, knowing this bit of information, you might wonder when Scrum
became a developed framework of the Agile methodology. According to
Barcelos Bica and Silva (2020), the history of Scrum traces back to an article
published in 1986 by Takeuchi and Nonaka, in which they compared rugby
games to product developers. The method was not ubiquitously adopted but it
had gained traction.
Nonetheless, Jeff Sutherland and Ken Schwaber in 1993 applied the concepts
that Takeuchi and Nonaka had utilized in their paper. This occurred when
Jeff Sutherland and Ken Schwaber were working in the Easel Corp business
environment. This led to the Scrum concept, which focused initially on the
development of commercial products and not software development.
Around the year 1995, Schwaber finally published an article relating to the
Scrum development process. In this paper, he explained the Scrum idea for
software development. Over the years, the Scrum method has been improved
and updated to fit modern times, and most software developers have become
keen to understand this Agile methodology.
This is exemplified by the Scrum framework’s essential role in the Software
Engineering curriculum for those studying computer degrees. Furthermore, a
recent study implemented the Scrum Agile methodology into a game-based
learning program using Trello to provide the students with knowledge on the
subject (Barcelos Bica & Silva, 2020; Naik & Jenkins, 2019). Therefore, you
can see that having an understanding of this method is imperative.
Developers who are dealing with a difficult project can benefit from using
Scrum. Although Scrum was based on the technology industry and software
field, there are no limits on where this system can be used (Barcelos Bica &
Silva, 2020; Naik & Jenkins, 2019; Scrum Alliance, 2019). It can even be
used in writing this book, which is based on the same principles as the Scrum
sprints. But, Scrum has the capability to change the world of business as
Scrum and even other Agile frameworks can make work life easier in every
field, business, and even education.
The Scrum methodology has a lot of hype behind it, but the hype is not false.
If you have experts in the technology field writing about this Agile
methodology, then there must be something amazing to it (Barcelos Bica &
Silva, 2020; Naik & Jenkins, 2019; Scrum Alliance, 2019). For example, the
Scrum method has been around since the early 1990s and even earlier years
have lightly touched on the subject. It’s a really good method, and it has solid
research backing the successful framework that’s been applied to a variety of
projects and teams. Why else would it be this popular?
Within the next 10-20 years, the Scrum Agile methodology will likely
become a major framework within most companies. If you take a look at
Scrum Teams that are using agile in the work process, they are able to learn
how to react more quickly and respond more accurately to the unforeseen
inevitable changes that come their way (Barcelos Bica & Silva, 2020; Naik &
Jenkins, 2019; Scrum Alliance, 2019). Moreover, this method is all about
staying focused, so collaborating and communicating with teams leads to
accomplishments that are handled with ease. This is simply because the
Scrum Agile Method is a system that experts in the software industry abide
by to make exponential progress in meeting project deadlines.
Research has even shown that Universities are now implementing Scrum
practices to deliver valuable projects to students (Barcelos Bica & Silva,
2020; Naik & Jenkins, 2019; Scrum Alliance, 2019). The Military is even
using Scrum to prepare ships for deployment, and this is also true in the
automotive world. Therefore, the system is already a part of the working
environment.
In fact, here is a list of reasons why companies are adopting this
transformative methodology into their workplace:
●
Increased capability to manage changing priorities within the
organization.
● Higher visibility among projects using the Sprint process.
●
More alignment between business and the information technology
field.
● Delivery of faster products to the market with high-quality.
So now you know that companies like Google, Amazon, Apple, and Samsung
are working on the next evolutionary smartphone program, logistics for
another amazon fulfillment, planning a charity, and so forth using Scrum
(Barcelos Bica & Silva, 2020; Naik & Jenkins, 2019; Scrum Alliance, 2019).
Scrum is a lightweight, simple to understand, but difficult to master
methodology. In order for a team to be successful, they need a Scrum Master
to direct the process because this person has the skills and knowledge needed
to lead the group; therefore, you will have an important role in a group
because you have mastered the subject of Scrum.
What’s more, Scrum is based on a philosophy, so although the concept is
hard to grasp, over time you will be able to express and talk about the Scrum
process with understanding and knowledge. The Scrum framework is
purposefully not complete, for the method only provides a definition of its
various parts needed to run an effective Scrum Team. Since Scrum is an
Agile methodology, it is based on the multiple intelligence of the people
using it within their group. If you look closely at the Scrum methodology, it
is not a set rule that you must follow, but it is more like guidance to have
better chemistry in the workplace with team members.
The Scrum framework allows for the implementation of processes,
techniques, and methods that teams can add to the framework. The Scrum
methodology is centered around existing practices but makes the
effectiveness of each of these processes a part of its system through
management, working environment, and employees' work behavior. This
creates a shield around the team where they can make improvements and
adjust the methodology to fit their needs. Thus, these are the benefits of the
Scrum Method.
Pillars of Scrum
The Scrum Theory relies on observing and experimenting to generate the
ideal product. This is enabled through process control that depends on
transparency, inspection, and adaptiveness. These three empirical process
controls are called the Three Pillars.
Transparency is the first pillar of Scrum. This pillar is based on the idea that
in order to make decisions, Developers need transparency in the process
(Scrum Alliance, 2019). This is to ensure that the team understands what they
are doing, for everyone on the team must share a common language on what
is happening in the process.
Transparency in Scrum can be realized through the Product Backlog, Task
Boards or Burndown Charts, Daily Scrums, Sprint Reviews, Definition of
Done, and Retrospective. As you can see, the transparency pillar is visible in
different stages of the Scrum process. This is a key benefit because when a
team is working towards a goal, the ones accountable for the project receive
appreciation based on their effort.
Inspection is the second pillar of Scrum. To prevent issues in the software
development process, constant inspection is applied to generate better results.
What’s more, Scrum users have to make sure that they inspect artifacts and
the finished product during a Sprint. Customers’ review can also be a process
of inspection, where Developers review the honest and transparent feedback
of the customers to make changes.
Inspections usually take place during the Scrum Artifacts process. The team
generally inspects the product towards the end of a goal to find any issues or
variance. The inspection is based on the Scrum board where the project is
made clear, the feedback from customers and Stakeholders is collected, and
deliverables are inspected. Furthermore, the inspection could also be based
on the Product Backlog and approval granted by the Product Owner.
Adaptation is the third and final pillar of the Scrum process. When there is a
turning point in the development process of the software, teams should be
willing to adjust quickly to meet the new requests. Failing to adjust to the
changes is a failure to apply the third pillar in the Scrum process. In the world
of Agile, adaptation is a part of the agile process (Kurnia et al., 2018; Scrum
Alliance, 2019). The teams must always find ways to improve and adapt by
changing what is not working to what will make it work better.
The adaptive stages of a project begin during the Daily Scrum. The Scrum
Team must run small experiments to find out what is not working, then
correct the errors upon the meetings. The Sprint Review process includes
when the Scrum Team seeks feedback on the software based on the
Stakeholders' opinions so that they can add the requested features to the
product. Furthermore, in the Sprint Retrospective process, the team will
discuss the internal problems and new ideas so that they can make
preparations to adapt to a new plan, which creates more value for the product.
Key Values of Scrum
As stated earlier in this book, this course is intensive and in-depth in order for
you to understand all aspects of the Scrum process to pass the PSM1 Exam.
Hence, Scrum has a total of five values that are: commitment, courage, focus,
openness, and respect.
Commitment is the key value for teams to be Agile in the Scrum process.
Commitment signifies the togetherness that teams apply when working on
projects (Kurnia et al., 2018; Scrum Alliance, 2019). This means that Scrum
and Agile teams build a bond where they trust each other and can rely on one
another to complete their part in the process.
Courage is the second key value to provide Agileness to teams. Courage
simply means doing what is right to maintain integrity in the software
development process. This also means creating an environment where team
members can have difficult conversations with each other, the product owner,
and Stakeholders to create a high-quality product.
Focus is one of the main Agile values of Scrum. The reason is that it is based
on the idea that team members should have the skill of focus and the ability
to maintain their concentration when it comes to difficult and even easy
projects that need full attention for completion.
The next value is openness. In daily Scrums, the team members are
frequently made aware of the process and discuss issues or the progress of
how a project is coming along (Scrum Alliance, 2019). The traits that the
team should reflect are creativity, honesty, humbleness, and respect so that
the teams can grow and improve during the sprint.
Respect is the last value of the Scrum process. Respect among members
represents that they respect one another and are on the same level so that each
member can see eye to eye with each other. Agile teams working in the
Scrum process should understand that respect is the biggest strength of the
team.
Scrum Basics
Now that you have an understanding of the Scrum core values, understanding
the basics of Scrum will make you an expert on the subject. Software
development using the Scrum process is laid out in The Scrum Guide. The
Scrum Guide basically provides a breakdown of the Scrum process including
Scrum Events, the Scrum Team, the Scrum Values, Theory, and so forth
(Scrum Guide, 2020). However, the main things that you will learn about in
this section are Timeboxes, Product Backlog, Sprints, and Sprint Goals.
These main parts of Scrum are the first step to understanding how Scrum is
set up and divided into various sections. The basics of Scrum are really
important since they focus on the time aspect of Scrum. Time and Scrum are
what you could call a match made in the computer technology world. The
Scrum process contains so many steps that Developers might become lost,
not knowing what to do due to the enormous amount of steps that Scrum
Teams implement in the project stages. However, the time log and list
sections of Scrum prevent Scrum Teams from getting lost in the
methodology.
The time frames break down each step and give the team a goal to complete
the project before the time expires. The team always knows when they have
to have a particular task completed or submitted because they were informed
via the Daily Scrums that this is what they had to do. If the Scrum process did
not have the time limits attached to it, then the Scrum methodology would
not fall far from the Waterfall methodology.
Scrum is a very rigid and easy process to follow because the Developers
don’t get lost in all the steps that have to be taken to implement the Scrum
methodology. The Timeboxes, Product Backlog, Sprints, Product Goal, and
Sprint Goals facilitate an on process methodology when it comes to Scrum
(Scrum Guide, 2020). Everything about the Scrum process is transparent and
predictable because the method of timing works. The creators who defined
Scrum understood that Developers had to be held responsible when working
on projects, and the only way they could make sure this was possible was by
implementing these timeline logs.
Therefore, Scrum Teams and any team who uses this method cannot use
excuses to procrastinate on finishing a project. The project already has a
sprint goal, timebox, and so forth set and anyone who falls behind will be
scolded by the Developers, Scrum Master, and Product Owner. Hence, this
gives them a sort of accountability to make them work harder and smarter.
This means they can finish the project within a week, two weeks, or a month,
and take time to relax or jump right into the next project. This is what makes
the Scrum basics unique because they facilitate a strict but non-demanding
system where it almost feels like each person on the team is pushing each
other to meet the goals.
Furthermore, the timelines in the Scrum process not only focus on the
deliverability of projects on time, but they also focus on quality. Throughout
each phase of the Scrum, the team has to come together and assess any issues
or impediments that may affect the quality of the product. Then they set a
goal and fix the problems. Additionally, each member gets to see what each
person is working on when it comes to the 15 minute Daily Scrum, around
this time they can correct or adapt new ideas to improve the software to get it
ready for delivery (Scrum Guide, 2020). This is why these four aspects of
Scrum are important to learn because they reveal the magic behind the Scrum
process.
Not only does Scrum evaluate the completion of a product based on time, but
by lists and a set order of Definition of Done, which will be discussed in
further chapters. Therefore, when reading about each aspect of the Scrum
Methodology, make it a responsibility of yours to truly understand the
various roles and aspects of Scrum.
Timeboxes
Timeboxing may seem like a confusing term at first since it entails the
process of Scrum Events. However, when looking at the entire definition,
Timeboxing is used by teams to decrease the amount of time that it would
take to complete a project (Barcelos Bica & Silva, 2020; Firdaus et al., 2019;
Jalote, 2004). Developers usually split the project into fixed periods of time
in order to limit the amount of time spent on an activity concerning the
software.
Moreover, in timeboxes, each iteration concerning the software is of equal
duration, which is based on the length of the timebox. Each timebox is
separated into specific stages where the teams complete tasks pertaining to
the process. In the Scrum framework, all the events are timed so the stages
are based on planning, implementation, review, and retrospect.
The five events which will be discussed further in the following chapters are
Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. The
timeframes or timeboxes that are usually set for Sprint Planning are around
two hours, the Daily Scrum should not exceed 15 minutes, while the Sprint
Review takes one hour, and Sprint Retrospective takes one hour as well
(Barcelos Bica & Silva, 2020; Firdaus et al., 2019; Jalote, 2004). However,
this may differ depending on how big the project is.
The positive aspect of Timeboxes in the Scrum process is that a certain level
of priority is set for each project. Meaning that software will be fully
developed and working properly based on the amount of time invested in
each stage of the development process. Furthermore, this allows the teams to
stay focused and saves them time when resolving issues, as each day has a
predictable pattern.
The negative aspect of Timeboxes is that the team may not be able to
complete the work in time, which may lead to semi-finished products.
Moreover, this is often due to a lack of communication because everyone is
dedicated to meeting the deadline in their sprint (Barcelos Bica & Silva,
2020; Firdaus et al., 2019; Jalote, 2004). What’s more, because the timebox
system is based on rushing, this could also lead to errors or inaccuracies in
project development. Hence, the timeboxing model has both advantages and
disadvantages during sprints.
One thing about timeboxes is that the time limit on events is set at a fixed
timeline that could be equal to minutes, hours, and even days. However, it is
not an intense time limit where the team will have to spend hours or days
working non-stop on the project until it is done. No, the timeboxes provide
the team with a realistic timeframe and remove the complexity that arises
from not knowing when a project will be finished. The timebox really
averages things out to make sure the schedule is comfortable for the entire
team.
However, keep in mind that the teams will have to work hard to complete the
project. It’s like when you were in school and you had assignments that were
due every week; you picked the days you were going to work on those
assignments and set aside a fixed amount of time to complete them (Barcelos
Bica & Silva, 2020; Firdaus et al., 2019; Jalote, 2004). Well, that is how the
timeboxes are created in the Scrum process.
The reason the timeboxes have this kind of setup is because it uses
psychology that motivates the Scrum Team to finish on time. Studies show
that time is a great motivating factor to make sure the employees or team
push themselves to finish their work as needed. When the employee or
teammate fails to accomplish this, they can receive criticism or feedback,
making them want to become better at managing their time and meeting the
deadlines when the organization sets a time limit.
Furthermore, procrastination is something that occurs in all workplaces.
People procrastinate because a project is too hard or because they do not
understand something, and the list of reasons goes on. Through the Daily
Scrums and Sprints, the Scrum Team cannot use these excuses to turn the
work in late because the Scrum Events have time limits on them, so the entire
team feels the pressure of timeboxes ticking away for them to finish. You’ll
notice that most aspects of the Scrum methodology have time limits set in
them, and this is why the Scrum method is so effective.
Timeboxes present a lot of value in the workplace. The reason is that the
product is dealt with altogether rather than focusing on one task. Timeboxes
are a mixture of vigorous focus that is met with a designated time limit and
facilitated by the Scrum Team receiving meaningful rest in between
timeboxes, which is a good approach to productivity (Barcelos Bica & Silva,
2020; Firdaus et al., 2019; Jalote, 2004). The timebox approach could be
looked at as similar to the Pomodoro technique, which focuses on something
for 30 minutes straight, then takes a quick break to refresh and start again.
The advantages of the timebox approach are the Scrum Team gains focus,
scope, and clarity. The reason the Scrum Team is able to stay focused is
because timeboxes rely on the idea of finishing one task at a time, and thus
the product managers can be sure that the Scrum Team’s focus is being
applied to each task. The timebox technique also requires that the tasks be
taken seriously with all attention invested in the project so that the deadline is
met.
Scope deals with the Scrum Team having a definite idea of the objective of
the project before beginning the process and setting the timeboxes. Once the
scope of the project is understood, this allows the timebox technique to
provide the scope of the product timeline (Barcelos Bica & Silva, 2020;
Firdaus et al., 2019; Jalote, 2004). When the timebox technique is put
together with task dependency, such as a Burndown Chart or Gantt Chart, the
project development is as easy as looking ahead via an estimation chart.
Additionally, timeboxes are a good way to implement monotonous tasks
while still adding valuable tasks in the Scrum project. For example, the team
may have to go through bugs or functions in an iterative process that could
become mundane; therefore, the time limit given can keep the process fresh,
where the team members feel like they have the same enthusiasm as when
they first went through the process.
Sprint
If Scrum is the heart of Agile Methodology, then a Sprint is the heart of
Scrum. A Sprint is considered a timeline that is set at one month or less
where Developers work on products that are additional, functional, and
completed (Firdaus et al., 2019; MiKnight, 2014; Scrum Alliance, 2019;
Scrum Guide, 2020). The Sprint process has several requirements that the
team must accomplish in that period.
The Sprint is broken down into daily semi-structured meetings, tracking the
completion of user stories. It also involves communicating with members of
the team to define what the team intends to accomplish as a goal in the Sprint
process. If the software is not able to be sent out within the Sprint timeframe,
the team has failed and the project will be further delayed.
Therefore, the Sprint Goal is the main objective that the team must abide by.
The goals are often specific and measurable, where the team gets the product
ready for release, addresses any risks that are apparent, and tests to see if the
product meets the assumptions pertaining to users (Firdaus et al., 2019;
McKnight, 2014). The main focus that should be remembered is that the goal
of the Scrum Sprint is to be met through the Product Backlog.
The Sprint consists of the Sprint Planning, Daily Scrums, the development
work, Sprint Review, and Sprint Retrospective. Sprints are often set to a fixed
time limit that can last around 2-4 weeks without any breaks until the project
is finished. This method is quite effective (Scrum Guide, 2020). Once a
Sprint finishes, the next one begins immediately, and the team takes the
experience they gained working on the first Sprint and applies it to their next
Sprint.
When the Sprint process begins, the team must avoid making any changes
that could harm the project. Moreover, they must keep the quality of the
product up to par, while the Product Backlog is often refined to update how
things have been accomplished. Also, the scope of the project can be made
clear and negotiated with the Product Owner to make changes if something is
not working.
Sprints make it easier for the team to predict the outcome of a project based
on the inspection and adaptive process. If the horizon of a Sprint is too long
to manage, such as ranging from 3-6 months. Then the Sprint becomes
complex, which increases risk, and the team may end up ruining the software
due to the long periods of time they have to spend with the project (Firdaus et
al., 2019; McKnight, 2014; Scrum Guide, 2020). Shorter Sprints are the
preferred way to go when it comes to developing software.
The reason why shorter Sprints are better is because they facilitate learning
and a fast paced environment where the team is always creating new projects
every month. If the Sprint is too long, then the team will lose motivation over
time, and because the project is taking too long, others might drop out of the
project before it even finishes. Furthermore, shorter Sprints equals less risk, a
decrease in costs and expenses, and more effort by the team to complete it on
time.
In the Sprint, numerous opportunities exist to predict progress, such as burnups, which will be discussed in this course, cumulative flows, and much
more. Although these practices are useful, they cannot replace the
imperativeness of the empiricism that is embedded in the Scrum process.
Furthermore, a Sprint can be eliminated or canceled when the Sprint goals
become obsolete, but the Product Owner has the power to make this decision.
When a Sprint is canceled, items from the Product Backlog that have been
completed go through a review process. The Product Owner generally will
accept completed items, while items that are incomplete are put back onto the
Product Backlog after estimating the time they will take.
Product Backlog
The Product Backlog is actually an Artifact of Scrum. However, it is an
ordered list that the team must follow in order to meet the needs of the
completed software (McKnight, 2014; Naik & Jenkins, 2019; Scrum
Alliance, 2019; Scrum Guide, 2020). From the Product Backlog, the team can
choose the tasks they want to develop and add these into Sprints. The Product
Backlog items can be done by the team, and this usually requires
transparency. However, it is managed by the Product Owner.
The Product Backlog has a total of four main tasks and can have various subtasks from the user stories. The main tasks are stories, bugs, refactoring, and
knowledge acquisition (Naik & JenKins, 2019). Each of these tasks presents
different aspects of the project that must be fully investigated, worked on,
and completed. The user stories go further in-depth, but that will be discussed
later.
Moreover, the Product Backlog must meet the requirements of the Product
Goal. The Product Goal is a commitment in the Product Backlog, in which
the team must take measurable steps in order to achieve or meet the future
desired state of the product (Scrum Guide, 2020). Once the team can meet the
Product Goal, they have fulfilled the requirements of the product or software.
Furthermore, the refining process in the Product Backlog deals with adding
details, such as order and size, description, and attributes dealing with the
work. If the team is not able to accomplish the Product Backlog, they must
fulfil or completely abandon the project. However, abandonment is not an
answer, thus, the team must work hard to finish the project.
The disadvantages in working with the Product Backlog are that ordered lists
do not necessarily mean the product will end up being high-quality. Steps can
be missed in the Product Backlog stage, which in this case, abandonment is
required since the software may have flaws or defects that the customers will
not like (McKnight, 2014; Naik & Jenkins, 2019; Scrum Alliance, 2019;
Scrum Guide, 2020). Moreover, the team can leave out the user experience or
separate this information from the product. Therefore, the Product Backlog
must be followed and planned correctly as with any stage or process in the
Scrum Framework.
Review and Exercises
The Scrum Framework or methodology contains numerous terms and
processes. However, the best way to understand Agile Scrum is to review this
chapter to catch any information that was missed. In fact, you should be able
to cite from memory the various terms surrounding Scrum based on the
amount of times you’ve reviewed the material. Nonetheless, the review
section and quizzes can help you review and remember the information:
● Scrum is considered the heartbeat of the Agile software development
framework.
●
Scrum theory relates to a process of control that depends on
transparency, inspection, and adaptiveness.
●
Scrum has a total of five values: commitment, courage, focus,
openness, and respect.
● In the Scrum framework, all the events are timed so the stages are
based on planning, implementation, review, and retrospect.
● A Sprint is a timeline that is set at one month or less and has specific
Sprint Goals.
● Timeboxing is used by teams to decrease the amount of time that it
would take to complete a project.
●
The disadvantages in working with the Product Backlog are that
ordered lists do not necessarily mean you’ll end up with a highquality product.
PSM1 Exam Example Questions
1. Scrum is a process and a technique.
a. True
b. False
2. What is Scrum Based on? (Choose all that apply.)
a.
b.
c.
d.
System
Rules
Events
Artifacts
3. The three pillars of Scrum are Transparency, Inspection, and Added Value.
a. True
b. False
4. Sprints can be canceled if:
a. The Scrum Team cannot handle the work.
b. It becomes apparent that everything will not be completed by the
end of the Sprint.
c. The Product Owner had a new idea.
d. The Sprint Goals become obsolete.
5. Which of the following are the main key values of Scrum? (Choose all that
apply.)
a. Commitment is a key value of Scrum, and it signifies the
togetherness within a team.
b. Agility is a key value in Scrum, and it refers to doing what is
right to maintain integrity in the software development process.
c. Focus is a key value of Scrum, and it is a skill that each team
member needs.
d. Honesty is a key value of Scrum, and it deals with being humble
among team members.
6. Select the correct duration based on the Timebox process.
a.
b.
c.
d.
Sprint Planning takes 1 hour.
Daily Scrum should not exceed 15 minutes.
Sprint Review requires 2 hours or more.
Sprint Retrospective takes 2 hours.
7. What occurs when a Sprint is canceled? (Choose all that apply.)
a. Any and all finished and “Done” Product Backlog items are
reviewed.
b. If part of the work is potentially releasable, the Scrum Owner
will accept.
c. More Product Backlog items are used in the Sprint Backlog to
replace the obsolete ones.
d. The incomplete Product Backlog items are re-adjusted and
placed in the Product Backlog again.
8. Which of the four is responsible for managing the Product Backlog?
a.
b.
c.
d.
The Stakeholders
The Developers
The Scrum Master
The Product Owner
9. Product Backlog contains only functional requirements for the software.
a. True
b. False
10. The work done by the Developers must originally come from the Product
Backlog.
a. True
b. False
Answers
1. A.
2. B, C, & D.
3. B.
4. D.
5. A & C.
6. B.
7. A, B, & D.
8. D.
9. B.
10. A.
Chapter 3
Scrum Events
The Scrum Events provide the team the opportunity to inspect and adapt
Scrum Artifacts. The events are designed to create transparency in the team
so that nothing is hidden and the process is upfront (Scrum Alliance, 2018;
Scrum Guide, 2020). If the team fails to initiate any of the events, this could
lead to negative outcomes in the software inspection and adaptation process.
The Scrum Events or ceremonies that happen with each Sprint are Sprint
Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. Each Event
requires the Developers to communicate and discuss the issues, problems, or
ideas they have for the product. Moreover, each event will involve a meeting
which will be outlined by the goals, participants, and timeline of the software
or product.
In actuality, the Scrum Events have a total of five events because the Sprint
itself is an event. If any of the events were to be modified or left out, then the
idea of Scrum goes out the window because the team is no longer
implementing Agile Scrum practices, but poor workmanship. The Scrum
Events are all about being accurate, on time, and following the rules of the
Scrum process.
Sprint Planning
Sprint Planning is all about the beginning stage of the Sprint process. Sprint
Planning requires that each member of the team meet during the duration of
the Scrum process to map out the Product Backlog (Kurnia et al., 2018;
Scrum Alliance, 2019; Scrum Guide, 2020). The Sprint Planning process can
take up to eight hours depending on the size of the project, based on a
monthly Sprint. However, the maximum time for the Sprint Planning based
on a smaller project is four hours. Keep in mind that two hours can be
sufficient for Sprint Planning as long as the project duration is very short.
Sprint Planning is also based on three topics that the team must understand:
Topic One: Why is this Sprint valuable? It is the responsibility of the Product
Owner to suggest or propose ways in which the product’s value and utility
could increase as a result of the Sprint (Scrum Guide, 2020). What’s more,
the entire Scrum Team must work together to explain to the Stakeholders
why the Sprint is valuable based on the commitment of completing the Sprint
Goal at the end of Sprint Planning.
Topic Two: What can be done this Sprint? Through the process of
communication with the Product Owner, the Developers can choose items
from the Product Backlog to be included in the current Sprint. The Scrum
Team has the right to refine these items during the Sprint, which increases
understanding and confidence among the team.
Topic Three: How will the chosen work get done? Based on the selected
Product Backlog item, the Developers must plan the necessary work to create
an increment that fulfills the Definition of Done. This process is done by
breaking down the Product Backlog items into smaller work items that take a
day or less. How this is accomplished is based on the sole discretion of the
Developers. No one else on the team can tell them how to convert Product
Backlog items into increments of value.
The Sprint Planning team that carries out the Scrum process includes the
Developers, Product Owner, and Scrum Master. Each of these members
discusses the roles they will take in developing the software, and the
development team has the final decision on the amount of work they will
complete during the Sprint. The team uses the timebox as discussed earlier to
set a period in which they work on the product and finish it.
Therefore, as a developer, the outcome you should achieve in a Sprint
Planning event is to set a Sprint Goal and Backlog that everyone on your
team agrees with and can achieve (Barcelos Bica & Silva, 2020; McKinght,
2014; Scrum Alliance, 2019; Scrum Guide, 2020). The process can be
challenging, but through constant exposure to the process, the team will
develop confidence when it comes to Sprint Planning.
Additionally, Sprint Planning involves the story process. Teams will often be
met with many stories that must be included in the Sprint (McKnight, 2014).
The reason is that the story points act as a substitute for the measurements
and work effort the teams need to deliver. If the team is not able to meet all
the story points, then this could result in a loss for the team. Although this is
true, if the story point becomes too much for a team member, other team
members can step in and offer their assistance to make sure the story is
completed, meaning everyone wins.
Daily Scrum
The next step that follows after Scrum Planning is the Daily Scrum. The
Daily Scrum is considered the perfect part of Scrum Events. The reason is
that during the Daily Scrum, everyone comes together and communicates
their status by explaining where they are in the process and answering
questions (Barcelos Bica & Silva, 2020; Firdaus et al., 2019; Kurnia et al.,
2018; McKnight, 2014). So, for those who seek connection with team
members, they can develop it through the Daily Scrums.
The meetings last a total of 15 minutes and are set a specific time every day
so everyone can get a rundown. The Daily Scrum also allows team members
to ask for help if they are having trouble with a development process or do
not clearly understand what they are doing. In other words, members can
seek advice and get reassurance that they are not the only ones working hard,
but an entire group is in it with them. This is what makes the Daily Scrum the
perfect process in the Scrum Events.
Another advantage of the Daily Scrum is that the team members can start the
inspection and action process early on. The constant meetings allow them to
see what works with the product and what they should do to make it better.
What’s more, the Product Owner can attend these meetings if need be, but the
owner does necessarily have to attend. However, the daily meeting does
require the members to stand up and present their work, and also discuss
what task they intend to finish before the next meeting.
Common information that members might report during the Daily Scrum: (1)
What they have accomplished since the prior meeting, (2) what they intend to
finish by the next Scrum meeting, and (3) discuss any constraints or obstacles
in their way (Barcelos Bica & Silva, 2020; McKnight, 2014). Communication
is key when it comes to the Daily Scrum process.
Every time the Daily Scrum is held, the team is able to set plans and then
begin working on fulfilling the requirements that were handed out during the
15-minute session. This process truly optimizes team collaboration and
boosts performance because they are checking the work of everyone and
predicting the next Sprint work that will take place on the next day.
The Developers use the Daily Scrum to inspect what is happening with each
member and the goals they need to set to be ready for the next item in the
Sprint Backlog. The Daily Scrum can be looked at as taking a break from
work in order to reflect and start fresh with new ideas and purpose in mind.
The Developers and everyone else in the group are able to manage their time
efficiently and work as hard as they can until that goal is accomplished.
The setup of the meeting is generally determined by the Developers and can
be held in many different ways. Meaning that the meetings may lead with
different topics, whereas the first Daily Scrum theft talks about what they
intend to accomplish, the next meeting could be about issues members are
having. So, the Daily Scrum is not just set up one way where everyone only
reports what they have done; it is very diverse. Common questions that might
be asked may pertain to What, When, Why, and How.
For example, members may be asked “What did they do yesterday?”, “How
are they coming along in the project?”, “Do they see any impediments in the
near future or during the next Scrum?”, and so forth (Barcelos Bica & Silva,
2020; McKnight, 2014). The Developers aim to keep the team members
motivated which is why this process exists in the Scrum Methodology. When
working on long and tedious projects, members are bound to get tired, lose
focus, and begin to lack the motivation to complete their work.
The Developers have to make sure they are managing the team's motivation
through this process. The Scrum Master might lend a hand by making sure
the Developers are actually holding these meetings, but in the end, the
Developers are responsible and accountable for the Daily Scrum. The Scrum
Master’s job is mostly to monitor and make sure they are staying within the
time limit. The Daily Scrum is internal, so the Scrum Master has to make
sure no one is trying to interrupt the process.
Nonetheless, Daily Scrums are the heart and brain cells of communication.
Without the Daily Scrum, the communication between members would be
stagnant, and the process for developing working software would be back
like it was in the days before Agile or Scrum came about. Hence, this method
is important to the group.
Sprint Review
The Sprint Review is the third stage where the team presents their results. Per
Kurnia et al. (2018), the team has to come together and demonstrate what
they have done over the entire Sprint to the Stakeholders both inside and
outside the Scrum Team. For example, The Scrum Master, Product Owner,
Stakeholders, and Scrum Team will participate in the Sprint Review to
improve the product. Stakeholders may refer to the managers, users, or
various representatives from different departments. The Sprint Review may
help address issues, but it does not address all team members' concerns.
Furthermore, competitors may also be affected by the results.
From the information present, the Product Owner or customer can provide
feedback on what needs to be changed or added before the release of the
product. The Sprint Review event usually follows this pattern where the
members and Stakeholders can collaborate on the next process and adjust the
backlog for new opportunities. The Sprint Review timebox goes to a
maximum of four hours based on a one-month Sprint (Kurnia et al., 2018;
Scrum Alliance, 2019; Scrum Guide, 2020). The duration of a Sprint Review
per one week of project duration is one hour.
Some of the Advantages of Sprint reviews at the end of the Product Sprint:
●
●
●
●
●
The Sprint Review illustrates to the team what has already been
figured out due to the fact that Spring Planning focuses on realizing
user stories, which can be presented live in the product. Moreover,
the progress of the development is directly visible for all to see.
There will always be direct feedback based on the Developers and
the Stakeholder. Hence, the Product Owner can take the feedback
received and implement it into the next Sprint.
Preparation is brought down to a minimum because the Sprint
Review helps them adjust to this process.
The Scrum Team’s allocation of work is easily manageable.
New ideas that will improve the software functions can be worked on
together.
Therefore, the Sprint review presents many benefits. Just in case you are
wondering, Sprint Review takes place on the last day of the Sprint. Thus, the
members do not have to worry about this stage until the product is completely
finished, and they just need to confirm what needs changes or improvements.
Hence, this stage sums up the product building process.
Sprint Retrospective
The final stage in the Sprint Events is the Sprint Retrospective. The Sprint
Retrospective is somewhat similar to the Sprint Review, but it focuses on the
process of making the project rather than the end results of the product
(Scrum Alliance, 2019). Meaning that the team looks at the entire process
and reflects on what they did right, wrong, or what they could have done to
make the process a lot smoother.
This does not only include the Developers but the Scrum Master and Product
Owner. The Scrum Team should always include each member in the
retrospective stage so that they can look back on their progress to see how
they want to approach the next project with more experience (Barcelos Bica
& Silva, 2020; McKnight, 2014; Scrum Alliance, 2019
This process can take up to a maximum of three hours for a one-month Sprint
and as little as one hour depending on the length of the Sprint. The main
questions that each member will have to answer include:
1. What worked or what was successful?
2. What tasks caused problems, failed, or did not turn out as well as
expected?
3. What can they learn from the experience so that they can
implement it into the next Sprint?
The Scrum Master at the end of the Sprint Retrospective encourages the
Scrum Team to make improvements to their process of doing things and their
practices concerning their work habits so that it will be more enjoyable and
less stressful on the next Sprint. What’s more, for each Sprint Retrospective,
the Scrum Team must plan ways to increase the product quality by making
adjustments to their work processes or adapting the Definition of Done, if it
is deemed needed, and to also avoid any conflicts with the product or
organization standards.
Basically, the Scrum Team should have found and identified all of their flaws
to improve for the next project. Implementing better qualities into their
working behavior for the next Sprint will be the added adaptation that the
Scrum Team can make beyond inspecting the product. Remember,
improvements can be made at any point in the beginning, middle, or end of a
project, in which the Sprint Retrospective’s main focus is inspection and
adaptation.
Review and Exercises
Scrum Events are not such a difficult process once you get the hang of it.
However, your main focus is passing the exam, so here are some quick points
to remember:
●
●
●
●
●
●
●
The main Scrum Events are Sprint Planning, Daily Scrum, Sprint
Review, and Sprint Retrospective.
The Scrum Events are all about being accurate, on time, and
following the rules of the Scrum process.
The Sprint Planning process can take up to eight hours depending on
the size of the project, based on a monthly Sprint.
The Daily Scrum is considered the perfect part of Scrum Events.
The Sprint Review is the third stage where the team presents their
results.
The Sprint Review takes place on the last day of the Sprint.
The Sprint Retrospective is when the entire team looks at the process
and reflects on improvements for future projects.
PSM1 Exam Example Questions
1. The Developers, Scrum Master, and Product Owner participate in the
Sprint Planning process.
a. True
b. False
2. Which of the following is not true about the Sprint Planning process?
a. The Sprint Planning Process can take up to eight hours in one
month.
b. Sprint planning is the beginning stage of the project.
c. The development team does not have the final decision on the
amount of work they complete.
d. User stories are incorporated into the Sprint during the planning
process.
3. What are the timeboxes for both the Sprint Retrospective and Sprint
Review?
a.
b.
c.
d.
4-hour timebox for each event.
3 and 4 hours, respectively.
4 and 3 hours, respectively.
3-hour timebox for each event.
4. What does the Scrum Master do in the following events of the Daily
Scrum? (Choose all that apply.)
a. When others are present at the Daily Scrum, the Scrum Master
makes sure they do not interrupt the meeting.
b. Ensures that the Developers are having the meeting.
c. Instruct the Developers to always maintain the Daily Scrum
based on the 15-minute timebox.
d. Conducts the meeting for the Daily Scrum.
5. Which are all the formal activities that help teams inspect and adapt?
(Choose all that apply.)
a.
b.
c.
d.
The Sprint Review.
The Daily Scrum.
The Sprint Planning.
The Sprint Retrospective.
6. During the Sprint Retrospective, the Definition of Done can be reviewed
and adapted.
a. True
b. False
Answers
1. A.
2. C.
3. C.
4. A, B, C.
5. A, B, C, & D.
6. A.
Chapter 4
Accountabilities
Value is an essential component of any business. The Scrum Master does
what is necessary to teach the group product team how to execute the Scrum
so that they can create a valuable, high-quality product. The success of the
Scrum is based on the Scrum Master’s ability to guide the team according to
the company’s ideals (Visual Paradigm, 2018). Although the Scrum Master is
not a supervisor, the Scrum Master acts as an advisor helping the team. The
Scrum Master goes about this by getting rid of interventions, safeguarding
the team from erroneous knowledge, and assisting the team in implementing
flexible expansion procedures.
The Scrum Master provides ample opportunities to organize the team agenda
and show the team the best way to apply Scrum. The Scrum Master is good at
helping the team stay focused and overcome hindrances that stop them from
being successful (Agile Alliance, 2017). Nevertheless, working with an illequipped Scrum Master has its drawbacks because issues can come about due
to unsuitable behavior within the job. This happens when trying to make an
upper manager into a Scrum Master, which one would think they’d naturally
do well in since it is about showing leadership. Another way the issue arises
is by casually asking an individual to be the Scrum Master when they have
little knowledge of the Agile development process.
Requiring a Scrum Master to provide the same assignment for each team will
lead to problems because not all teams are the same. Some teams that are
better at acting together to get a project done will not require much assistance
from a Scrum Master. However, when a team is falling behind or isn’t
familiar with where to start, then advice from the Scrum Master will be
needed. Hence, it is vital not to treat each team workload the same and
require the Scrum Master to present this information. The workload on each
team may be different, which is why the Scrum Master cannot provide a onesize-fits-all blueprint. It is the Scrum Master’s job to advise the team, owner,
and organization on the best way to achieve the goal.
Scrum Team
The Scrum Team is a group of individuals with a purpose in mind to create
and make available the demanded and dedicated product additions. It
includes cross-functional associates who are proficient in realizing the Sprint
areas (Visual Paradigm, 2018). The objective of the Scrum Team is to:
● The team’s job is to develop products that the owner can present and
use on an application.
● The team works together successfully by implementing all the tools
and resources they have available to them to develop deliverable
products.
● Independence and determination are what each individual of the team
brings in order to meet goals.
● The Scrum Team has the choice to decide what needs to get worked
on, or who to pass the project on to reach its metrics.
● The team must be cross-practical and self-sorting. Together, they are
responsible for creating, testing, and delivering the product and its
improvements.
Scrum Master
The Scrum Master’s job is to simplify activities by developing a
comprehensible study tool. The Scrum Master acts as a resource for all; they
serve as a guide to help the team and the owner be successful in the
development of the product (Kalweit, 2020). It is the main duty of the Scrum
Master to aid everyone in continually working on ways to better things with
their team and other Scrum Masters.
This results in better production agility for the company and its team. The
common drive behind the Scrum Master is to act as a servant by helping
people in the organization find ways to meet company objectives and create
new opportunities (Kalweit, 2020). When all these things are met, then the
business value and effectiveness fall into place naturally. Moreover, when the
team is doing things effectively and creating great quality, this leaves little to
be done.
Therefore, the Scrum Master aims to attain efficiency by ensuring all goals
are met in the highest quality. However, when the effectiveness of the
company is not being maintained by the owner and the team, the Scrum
Master must first take care of this responsibility until it is met by giving
advice to the team in need and the owner. The Scrum Master has three
priorities to ensure business value: effectiveness, quality, and efficiency.
The Scrum Master must be effective in handling the team by making sure the
Developers are holding the meetings, and that everyone is in attendance,
while at the same time making sure no one interrupts the meeting.
Furthermore, the Scrum Master has to be effective in their own
responsibilities by making sure they are doing their role correctly and that
they are being a benefit to the team rather than someone who imposes rules
but does not follow them (Kalweit, 2020). The Scrum Master is the one who
holds all the knowledge about Scrum; therefore, the Scrum Team will look
for the Scrum Master to keep them aligned with the goals and maintain the
right path.
In other words, the Scrum Master's role is to be influential, observant, and
aware of team members. The Scrum Master will lead various teams,
depending on the type of project they are working on, and they must be able
to motivate, facilitate, and make sure to maximize the potential of each
member of the team. Without the Scrum Master applying these traits, the
team will easily become demotivated and fail to get the projects in on time
due to the Scrum Master’s position as a leader.
The next business value is quality. The Scrum Master has to provide quality
advice, management that makes sure the product is high quality, and to
provide members with quality information (Kalweit, 2020). The role that the
Scrum Master facilitates is of importance just as the Product Manager, The
Development/Scrum Team, and Stakeholders, each of these roles are
important, and they look for the Scrum Master to keep things moving along.
The last value that the Scrum Master has to exemplify is efficiency. The
Scrum Master might apply efficiency to make sure the tasks are completed,
and the Developers providing the Definition of Done for the projects, and that
every task was completed in the Product Backlog (Kalweit, 2020). Moreover,
the Scrum Master may have to collaborate with the Product Owner as well as
the teams, so it’s important that the Scrum Master inform the Product Owner
of what’s happening with the development of the software, and just provide
moral support to everyone involved in the project.
Most important, although it was mentioned before, the Scrum Master has to
be observant of everything. The Scrum Team may have a member that is
having trouble keeping up, or that member clearly does not understand what
is required from him. Therefore, the Scrum Master must make sure that
members get one-on-one time to fully explain what they need to do and to
also encourage the other members to help their teammates out if they see
them struggling to solve a roadblock. This is the main responsibility and
accountability the Scrum Master has to take on with handling obligations or
just attending to each team member to make sure that they are all on the same
path, and heading in the same direction of delivering working high-quality
software.
Product Owner
The Product Owner is liable for amplifying profit from the venture by
distinguishing what items to include, making an interpretation of these into a
focused rundown, concluding which ought to be at the first spot on the list for
the following run, and consistently re-focusing on and refining the rundown
(Visual Paradigm, 2018; Scrum Guide, 2020). The owner has the benefit and
obligation of working with Stakeholders to define the expectations for the
project and thus the features in the Product Backlog.
The Product Owner has an involved role. They must make sure the product
was properly researched and that the concepts were put together and tested. If
the Owner fails to fulfill their job duties, the goals of the Scrum will not be
met and the Scrum Master will have to coach the owner on what needs to be
done immediately for the effectiveness of the company.
The Scrum Master must quickly recognize the error and begin to make
adjustments that will benefit the organization. Although the Product Owner
has less responsibility, they still play a huge role in the outcome of the
company functions. A Product Owner has to recognize growth and make sure
they have the right information to avoid sinking hours into redoing parts of
the product.
Hence, this is why the Product Owner has the following responsibilities:
●
●
●
●
●
The owner is responsible for the product growth and client stories.
They must work with both internal and external Stakeholders to
define the features in the Product Backlog that will add value to the
product.
The owner must make sure everyone understands each item in the
Product Backlog and is also responsible for adding, removing, or
changing the priority of items in the Backlog.
The main objective of the owner is to recognize and accept when
items or features are complete and to ensure that they are highquality.
The owner should have an active role throughout the Sprint. They are
responsible for explaining the scope and value each item in the
Backlog has.
The owner is accountable for the capital from profit, so the owner
can decide whether the company is meeting its objective or more
needs to be done to accomplish this.
Developers
The responsibility or the accountability of the Developers is to deliver highquality, functioning software or products. Developers are generally
accountable for delivering quality usable products after every single Sprint
(KnowledgeHut, 2019; Who is the Scrum developer: role and responsibilities
- QRP International, n.d.). Without the Developers putting in the work to
make good products, the Product Owner cannot maximize value without
anything usable sent to the customers. This role requires the Developers to be
disciplined and have the technical skills to get the work done.
The Developers are not only engineers but can also include experts in
different fields and specializations. For example, the developer team consists
of programmers, software developers, architects, software designers, business
analysts, documentation experts, and software testers (KnowledgeHut, 2019;
Who is the Scrum developer: role and responsibilities - QRP International,
n.d.). The accountability that each of these members takes on in the team
helps keep the project on track and makes it easy to deliver at the end of each
sprint cycle.
The main accountabilities that the Developers must deal with in the Scrum
Process include:
1. The Developers must have an understanding of the business
requirements specified by the Product Owner.
2. The Developers should be able to measure and estimate the user
stories in the Sprint Backlog.
3. The Developers should be able to develop the products or
deliverables.
4. Achieve the goals specified by each Sprint.
5. Collaborate with other team members.
6. Identify any issues and impediments in the process of
developing the product.
The Stakeholders
Stakeholders are not a main part of the Scrum Team. The Scrum Team
generally consists of less than ten members. The reason is that having a
smaller team work on the project makes it more agile for the team to operate
and complete a significant amount of work in little to no time (Scrum Guide,
2020). However, having fewer than three Developers on the team will
decrease the interactiveness and lead to bad results. Furthermore, the project
will likely experience issues and the team will not be able to release in time
after the Sprint has ended. Hence, as stated before, and just to clarify so that
you may remember, the Stakeholders are “Not At All” a part of the Scrum
Team.
Having less than ten individuals on each team helps eliminate bad
coordination, complexity, communication issues, and people stepping over
each other's feet. This count does not include the Scrum Master or the
Product Owner, since they are separate in what they are accountable for in the
Scrum process. Thus, this is why Stakeholders are not counted within this
group. Nonetheless, they are accounted for in the product development
process, so they should be talked about within this section.
The Stakeholders are individuals and organizations who are constantly
interfacing with the Product Owner, Scrum Master, and Scrum Team to
provide them with input and facilitate creating the software or products
(Visual Paradigm, 2020). The Stakeholders also provide input on the product
throughout the project’s development life cycle or Sprint. Stakeholders
include the customers, users, and sponsors of the software.
●
The Customers. These are individuals or organizations who buy the
product or software. Depending on the project, there can be both
internal customers (i.e., within the same organization) or external
customers (i.e., outside of the organization).
● The Users. These are individuals in the organization that directly use
the project’s products and services. They are basically the customers
or organizations, which can also be both internal and external users.
Depending on the project, customers and users may be the same.
● The Sponsors: These are individuals and organizations that provide
resources and support for the project. The sponsor is also the
stakeholder to whom everyone is accountable in the end.
Review and Exercises
Now you understand the roles of the Scrum Team, here are a few things to
review:
● The Scrum Master acts as a caregiver to all, serves as a guide to help
the team, and helps the owner be successful in the development of
the product.
● The Product Owner is liable for amplifying profit from the venture
by distinguishing which items to include in the backlog, interpreting
them into a focused rundown, concluding which ought to be
prioritized first in the next Sprint, and consistently re-focusing on
and refining the rundown.
● The owner should have an active role throughout the Sprint. They are
responsible for explaining the scope and value each item in the
Backlog has.
● The Developers are not only engineers but can also include experts in
different fields and specializations.
●
The responsibility or the accountability of the Developers is to
deliver a high-quality, functioning software or product.
● The Scrum Team generally consists of less than ten but more than
three people.
●
The Stakeholders are individuals and organizations who are
constantly interfacing with the Product Owner, Scrum Master, and
Scrum Team to provide them with input and facilitate creating the
software or products.
PSM1 Exam Example Questions
1. How does the Scrum Master serve the Developers? (Choose all that apply.)
a. By removing impediments to the Developers’ progress.
b. Instructing the Developers in self-management and cross-
functionality.
c. Assisting the Developers by being a leader.
d. Assisting the Developers by creating high-value products.
2. The Developers can change the Product Backlog with collaboration from
the Product Owner.
a. True
b. False
3. What is the recommended size for a Scrum Team?
a.
b.
c.
d.
More than 8 or less than 3.
A minimum of 7 members.
A total of 9 people.
Less than 10 people.
4. The Product Owner should know more about the progress concerning
project objective and release. Furthermore, the PO must be able to come up
with clear and transparent solutions.
a. True
b. False
5. Which statement best describes the accountability of the Product Owner?
a. Managing the project by making sure the work meets the
stakeholder’s commitments.
b. Enhancing the value of the work the Scrum Team does.
c. Allowing Stakeholders to distance themselves from the
Developers.
d. Telling the Developers what to do.
Answers
1.A,B,&D.
2. A.
3. D.
4. A.
5. B.
Chapter 6
Scrum Artifacts
Scrum Artifacts can be described as information that a Scrum Team uses to
outline the development of software. The artifacts provide data and
significant points that highlight the work and value concerning the project
(Scrum Alliance, 2018; Scrum Guide, 2020). The Scrum Artifacts are
important tools for the development process since they give insight into the
performance of the Sprint, which enables transparency, inspection, and
adaption.
Artifacts are created during the main tasks of the Scrum. The purpose of the
Artifacts is to plan and work toward future goals, create activities to meet
these goals, set tasks based on Sprints, take action on the tasks, review and
analyze, and repeat the process. There are a total of three Artifacts, which are
the Product Backlog, Sprint Backlog, and Product Increment. Each of these
artifacts has a commitment to ensure that they provide transparent details that
can be measured.
The Scrum Artifacts are broken down based on the goal they must
accomplish. For example:
● The purpose of the Product Backlog is to meet the Product Goal.
● The purpose of the Sprint Backlog is the Sprint Goal.
● The purpose of the Increment is the Definition of Done.
In other words, the Scrum Artifacts are set as commitment stages that must
be completed by the teams, while also emphasizing the Scrum Values. The
team may use Sprint Burndown Charts to track their progress to see if they
are meeting the goals.
Product Backlog
The Product Backlog is a list of tasks that need to be completed, such as
features, bugs, enhancements, requirements, and fixes (Scrum Alliance, 2018;
Scrum Guide 2020). This information is generally acquired from the
customers’ feedback, competitor and business analysis, and market demands.
Hence, the Product is considered the main Scrum Artifact because of this.
The Product Backlog also has a refinement process where the items are
defined for more transparency. The Artifact is considered live for the simple
reason is that the tasks are always updating on a continuous basis to ensure
the team is busy working rather than procrastinating on getting the work
done. This is a unique aspect of the Artifact because it allows the team
members to see how they are progressing through the project and that they
will complete it in no time.
The Product Backlog is also considered a cross-team. This means that the
artifact is maintained and selected by the Product Owner in the middle of
Sprint cycles where the Owner can choose which person works on what in
the list. So, that is the main breakdown of the Product Backlog.
The commitment that the Product Backlog holds is the Product Goal. The
Product Goal describes an end goal for the software which becomes the aim
for the Scrum Team (Scrum Guide, 2020). You can think of the Product Goal
as a mission statement or objective within the Product Backlog that the Team
must uphold and live by to accomplish the goal.
Sprint Backlog
The Sprint Backlog is basically a list of everything that the team wants to
finish in a Sprint. The Sprint Backlog contains the goal, the Product Backlog
items, and a reasonable plan to deliver on the increment (Scrum Alliance,
2018; Scrum Guide, 2020). Once the Sprint is set up, only the Developers can
add or remove items from the Sprint Backlog.
For example, if the Developers realize the technology they planned to use to
implement a feature doesn’t work, they can revise an item in the Sprint
Backlog to include a different technology. However, they can’t change the
overall Sprint Goal. In addition, if they think changes are needed to the
Product Backlog, they have to discuss it first with the Product Owner. In
working out this issue, the Scrum Master works with the Developers and the
Product Owner to see if they can come up with a solution to drop or add
increments to the project.
The Sprint Backlog updates during the Sprint Planning event. Meaning that if
the team cannot deliver the sprint tasks on time, then the remainder of the
tasks are pushed to standby and allocated to the Sprint Backlog for a future
Sprint (Scrum Alliance, 2018; Scrum Guide, 2020).
The Sprint Backlog is based on the commitment to accomplish the Sprint
Goal. The Sprint Goal is the mission or objective of the Sprint. However, the
goal is for the Developers and the team to maintain their focus and coherence
to achieve the project together rather than separately. The Sprint Goal is
usually set during the Sprint Planning and then added to the Sprint Backlog
as the team works to reach the finish line.
Product Increment
The Product Increments are the customers’ deliverables that were put
together by the teams upon completing the tasks in the backlog. At the end of
each Sprint, the team completes a product increment that can be released onto
the market (Scrum Alliance, 2018; Scrum Guide, 2020). This means that
when the product meets the agreed-upon Definition of Done, then it can be
released.
Each sprint contains an increment as per requirement, and these increments
are decided in the Scrum Planning stage. Product increments are very useful
to the Continuous Integration (CI) and Continuous Delivery (CD) tools,
which using the Scrum tracking software, teams can track their project.
The commitment of the Increment is the Definition of Done. The Definition
of Done clarifies the state of the increment upon meeting the qualifying
measures required for the software. The Developers are required to abide by
the Definition of Done. However, if there are multiple Scrum Teams working
on a product, they must all come to an agreement and abide by a single
Definition of Done.
Burndown Chart
A Burndown Chart is not an official Scrum artifact, but this artifact provides
value and insight into the Scrum cycle. Teams often used it to track and
communicate their progress of the sprint goal (Scrum Alliance, 2018). The
reason is that Burndown Charts allow the team to measure whether or not
they will be able to complete the work of a Sprint.
Furthermore, Burndown Charts also enforce the Scrum values of
commitment, focus, openness, and transparency. This ensures that the team is
applying the Agile Scrum values and not losing sight of their purpose. You
will come to notice that most of the processes in the Agile Scrum framework
reinforce the same values repeatedly to make sure that the team takes on that
mindset.
Sprint Burndown Charts are graphical images to show how much work is
remaining in the Sprint process. These charts base the data off of term hours
and are often updated during the Daily Scrum meetings (Scrum Alliance,
2018). When the amount of work begins to decline, the chart should show a
trend toward expected product completion on the last day. However,
Burndowns that show increasing work or fewer tasks, should be signals to the
ScrumMaster and the team that the Sprint is not on track.
Definition of Done
The term Definition of Done was briefly mentioned in the Product Increment
goal. However, this term needs further elaboration so that you can understand
its relevance to the project. It is imperative that teams have a clear Definition
of Done (DoD) to define the boundaries of an increment and to provide
clarity on a finished project (McKnight, 2014; Scrum Guide, 2020). Defining
the completion of a project eliminates uncertainty as each team member will
know what has been finished and what is still being worked on.
When a Product Backlog item requires the Definition of Done artifact, an
increment is created. This creates transparency by giving everyone on the
team a shared understanding of what work was accomplished as part of the
increment. If, however, a Product Backlog is not able to meet the Definitions
of Done, it cannot be released or presented in the Sprint Review Stage. It
must go back into the Product Backlog until the team decides how they will
plan on handling it.
The Definition of Done must be followed by all members of the Scrum
Team. As stated earlier, the Developers are required to conform to the
Definitions of Done as well, but the Scrum Team is the one responsible for
defining and setting in place the Definition of Done. This means that it is
owned by both the Product Owner and the Developers (McKnight, 2014;
Scrum Guide, 2020). Thus, the Definition of Done holds strict value in the
Scrum Process.
What’s more, relying on whether or not all the tasks are "Done" can lead to
significant conflict, setbacks, and problems with the User or Product Owner.
Thus, this can harm the company's experiences and revenue, and thus doublechecking is always a good step to add to the meetings before the Sprint
begins (McCloskey, 2019). Having a shared concept for the product's result
should be a goal that everyone tries to achieve within the Scrum process.
Furthermore, the Team should agree on the expectations or other features
added to the project before it passes through the Sprint Planning process
(McCloskey, 2019; McKnight, 2014; Scrum Guide, 2020). Therefore,
everyone must reach a consensus of expectations.
Additionally, not providing every item a separate measure of Definition of
Done also saves time and is beneficial. It lets the Scrum Team focus on the
building and innovation process rather than marking every task as done
(McCloskey, 2019). The simple fact is that with the ambiguity removed, each
team member can maintain their focus on the core aspect of the project
development. This will also save Teams from arguing about what needs
fixing to be released. Moreover, sometimes a feature might appear done on
the surface, which if the technical team hasn't coded their the I's and crossed
their T's, then the product may be faulty
Definition of Done can vary because it could refer to finishing coding or
programming, testing, document information, and completing an increment.
However, the term means the same thing in all instances, which is that the
task has been completed and the team can focus on finishing up the
remaining tasks to reach the final goal of the product. The Definition of Done
can be at times challenging to get consensus, but Sprints, Stories, and tasks
need a clear Definition of Done.
Furthermore, when a Product Backlog item or increment is marked as Done,
everyone including the Scrum Team, Product Owner, Scrum Master, and
Stakeholders must understand the project to be done as a whole. In other
words, a meeting of some sort must be held like a Daily Scrum where the
ones who marked a project as Done make sure that everyone knows that they
completed it and that the team does not have to worry about it any longer.
However, this could vary for some Scrum Teams depending on how they
communicate.
During the Sprint planning, the Developers should have an idea of how many
tasks were completed in the Product Backlog items list (McCloskey, 2019;
McKnight, 2014; Scrum Guide, 2020). Once they have done that, then they
can mark the tasks as done if they were left unmarked because a person in the
team forgot to mark it as done or because everyone knew that they had
finished. The Scrum Team has to be very careful as well when it comes to
increments.
The reason is that increments are pieces of the project that have been divided
up into various sections and added to the Product Backlog. The Developers'
main responsibility is to go over those increments and go around the team to
find out which ones can be defined as Done, and which ones they need to
keep in the Sprint process. If by chance a Done for the increment is not a
convention of the organization, then the Developers must provide a Done
definition appropriate for the product at that specific time.
Scrum Teams will grow from this process and gain experience in determining
the definition of done. However, it is expected that definitions of done will
expand to include stricter requirements in order to meet the high-quality
demands of the software (McCloskey, 2019; McKnight, 2014; Scrum Guide,
2020). Nonetheless, the Scrum Team should have a standard Definition of
Done, so that they can refer to it whenever they are working on new projects
or even old ones that require revision.
Users Stories
User stories are initial functionalities that must be developed by the team.
Stories are the functionalities that the Product Owner introduces to the team
during the Sprint Planning meeting (Barcelos Bica & Silva, 2020; Kurnia et
al., 2018; McKnight, 2014; Naik & Jenkins, 2019). This helps the team figure
out how they will get the end result of a product or software by adding these
functionalities.
User stories are often found in the Product Backlog and are based on a set of
fixed features. Generally, everyone on the team will create the Product
Backlog and fully describe the functions they will be working on in the
Sprints based on the User Stories. The stories can sometimes be themed or
longer, which are called epics.
Epics are large user stories that allow Scrum Teams to manage and keep track
of big ideas in the Product Backlog. Epics are so detailed that they cannot be
put into a single Sprint (Barcelos Bica & Silva, 2020; Kurnia et al., 2018;
McKnight, 2014; Naik & Jenkins, 2019). However, they are often split into
small user stories to add the data to a Sprint. Moreover, there is no specific
format to code epics because some Scrum Teams used regular story
formatting, while others format the users’ stories with short phrases.
Epics can present complications because Scrum Teams may overcomplicate
them by seeing them as more than just a large user story (Barcelos Bica &
Silva, 2020; Kurnia et al., 2018; McKnight, 2014; Naik & Jenkins, 2019).
This issue becomes visible when the team creates complex mechanisms to
differentiate between epics and user stories, which leads to Backlog
hierarchies and the usage of more tools. However, user stories are assigned
story points, which represent how much effort is needed to complete the
story.
Good user stories are independent, negotiable, able to be estimated, valuable,
sized appropriately, and testable. Without these fundamental aspects, the
story can be seen as complex or difficult. In fact, one of the challenges of the
user stories is defining the amount of effort that it takes to develop each user
story. Developers might use different techniques to calculate and estimate the
size of the team that will be necessary to develop the user stories (Barcelos
Bica & Silva, 2020). However, it depends on what decision they are able to
arrive at based on the user story doability.
Definition of Done vs. Acceptance
Although the Definition of Done was covered. Understanding how it
compares to the Acceptance Criteria can help you better understand the DoD
and its importance. Acceptance Criteria can help in high-quality software
documentation along with the user stories. The reason is that Acceptance
Criteria (AC) are conditions that a software or product must meet to be
accepted by users, customers, or other systems of organization (Altexsoft,
2018). Well-written acceptance criteria can help the Scrum Team avoid
unexpected outcomes at the end of the development stage.
Moreover, it helps make sure that all Stakeholders and users are satisfied with
what they are getting in the future product. The biggest purpose of the
acceptance criteria is to ensure that the stakeholder’s requirements are clearly
understood (Altexsoft, 2018). However, the Acceptance Criteria can be
broken down into various features that are beneficial to teams.
The first main purpose is feature scope detalization. Acceptance Criteria
helps give meaning to the boundaries of user stories, and it provides accurate
information on functionality to determine if a story is completed. The next
main purpose is to describe negative scenarios. The AC can prevent incorrect
input by alerting the team that bad information was entered into the program,
which the team can then retract and enter the correct data into the system.
The third main purpose is setting communication. The Acceptance Criteria
can synchronize the goal or vision of the client along with the Developers so
that everyone is on the same path of understanding. This allows the
Developers to see the features that must be enabled in the software, and the
Stakeholders and clients are able to see their expectations coming into
existence.
The fourth main purpose is streamlining acceptance testing. The AC can be
tested in different scenarios to see if it meets the user story (Altexsoft, 2018).
Additionally, the AC can validate the story through automated testing, and
each of the acceptance criteria must be tested separately. The final main
purpose is that the acceptance criteria have feature estimation. The
Acceptance Criteria specify what is supposed to be developed by the team.
Once they have a precise requirement, they can then split the user story into
tasks that can be accurately estimated.
There are various types of Acceptance Criteria, which are scenario-oriented
(Given/When/Then), rule-oriented (checklist), and custom formats (Altexsoft,
2018). The first criteria provide a consistent structure that provides testers
with the help they need and helps them define when to begin and end testing
a feature. This criteria also cuts down on the time spent writing the tests.
Each of the statements in this criteria follows this pattern:
1. Scenario - the tag name for the behavior intended to be
described.
2.
3.
4.
5.
Given - the beginning phase of the scenario.
When - the specific action the user will have to take.
Then - the outcome in which the action is “When”.
And - used to follow any of the three statements above.
The second acceptance criteria is Rule-Oriented. This criteria is used when it
becomes hard to implement the first criteria. This criteria has a set of rules
that explains the behavior of a system. Moreover, based on the rules, the
Developers can create specific scenarios. Custom formats or other formats
mean that most user stories can be accomplished with the criteria above.
However, Developers have the choice to invent their own acceptance criteria,
as long as it is clear to read and understand by everyone in the group.
Now, how does the Acceptance Criteria compare to the Definition of Done?
Well, the difference is that the Definition of Done is a common system for all
user stories, compared to the Acceptance Criteria where it only applies to a
specific user story (McCloskey, 2019). Furthermore, The Definition of Done
(DoD) refers to when all conditions have been met. However, where they
both are comparable is when it comes to the idea that DoD and AC both must
be met in order for the feature or item to be considered complete. This means
that the product would need to be available to the user, customer, team, and
consuming system in order to complete a user story.
What’s more, the teams must meet the Definition of Done to give highquality products. By doing this, it lowers rework for the Developers because
they are able to prevent user stories that do not meet the Definition of Done
from being promoted to potential customers and clients (McCloskey, 2019).
The rules of the Definition of Done apply to all work items on the Product
Backlog, even if the user story is large.
The DoD universally applies, with some exceptions, to everything that the
Developers or engineers do to ship the finished product. However, the
Acceptance Criteria are unique to the user story and feature in question. The
criteria should be determined by the Product Owner, and with input from the
technical team before it is considered done. The AC is focused on building a
common ground of understanding with the team so they can complete the
project and provide it with a “Met” or “Done” tag.
Therefore, which is the better choice? Well, the goals of the Definition of
Done are to build a common understanding in the team concerning quality
and completeness (McClosekey, 2019). Moreover, to use a write-off list or
checklist that the user stories or Product Backlog are checked against. Lastly,
it ensures that the increment shipped at the end of the Sprint is understood by
all and is of high-quality internally and externally.
Now, the goals of the Acceptance Criteria are to clarify what the team should
build before starting the project. Moreover, they ensure that everyone on the
team has a common understanding, similar to DoD, and to help the members
know when the story is complete or has been verified through automatic
testing. As you can see, they are both closely related, but one is more userfocused and specific while the other focuses on the whole of the product.
Additionally, when designing the Definition of Done, the team has to ask
questions to arrive at a DoD. The questions are: Code peer-reviewed? Code
Completed? Code checked-in? Unit tests that pass? Functional tests passed?
And, Product Owner reviewed and accepted? The Acceptance Criteria is
different for it looks at the micro-level, such as users completing mandatory
steps to submit a form, storing the information in registered databases,
making payments via credit card, and acknowledging that an email is
received. Hence, are the differences between the Definition of Done and the
Acceptance Criteria.
Review and Exercises
This section touched on the basis of Scrum Artifacts, the goals of the
artifacts, Definition of Done, and the user stories artifact. From this section,
you should have a full understanding of the Scrum Artifacts and be able to
define them without hesitation. However, as always stated, reviewing is key
to retaining the information. Therefore, the key points to remember:
● The purpose of the Artifacts is to plan and work toward future goals,
create activities to meet these goals, set tasks up based on Sprints,
take action on the tasks, review and analyze, and repeat the process.
●
The Product Backlog is also considered a cross-team. This means
that the artifact is maintained and selected by the Product Owner in
the middle of Sprint cycles.
● The Sprint Backlog is based on the commitment to accomplish the
●
●
●
●
Sprint Goal.
Product increments are very useful to the Continuous Integration (CI)
and Continuous Delivery (CD) tools.
Sprint Burndown Charts are graphical images to show how much
work is remaining in the Sprint process.
The Developers are required to conform to the Definitions of Done,
but the Sprint Team including the Product Owner are the ones
responsible for defining and setting in place the Definition of Done.
Stories are the functionalities that the Product Owner introduces to
the team during the Sprint Planning meeting.
PSM1 Exam Example Questions
1. Which of the following are the Scrum Artifacts? (Choose all that apply.)
a.
b.
c.
d.
The Sprint Goal
Increment
Product Backlog
Sprint Backlog
2. How does the Definition of Done help in Sprint Planning? (Choose all that
apply).
a. It helps in estimating the amount of work it will take to fulfill the
Product Backlog.
b. It does not help the Sprint Planning process and slows down the
fulfillment of items in the Backlog.
c. The Developers are able to plan better when completing the
Sprints.
d. It helps the Product Owner make decisions about the Sprint.
3. It is not mandatory for the Product increments to be released at the end of
each Sprint.
a. True
b. False
4. The Product Backlog is ordered by:
a. Size, in which small items are at the top and larger items are at
the bottom.
b. Risk, in which safer items are at the top and riskier items are
below.
c. Whatever the Product Owner feels is most appropriate.
d. Items that are randomly arranged.
5. Who creates the Definition of Done?
a. The Scrum Master because they are accountable for the
productivity of the Developers.
b. If it is not based on organization standards, the Scrum Team
must create the Definition of Done.
c. The Product Owner, since they are accountable for the project’s
success.
d. The Developers must create the Definition of Done.
Answers
1. B, C, & D.
2. A & C.
3. B.
4. C.
5. B.
Chapter 7
Scrum 2017 vs. Scrum 2020
Now that you’re all caught up and have an in-depth understanding of Agile,
Scrum, and the process entailed, it’s time to explore the Scrum Guide. The
Scrum Guide is provided to those who are interested in learning about Scrum
or are taking the PSM1 Exam. This guide discusses Scrum’s roles, events,
artifacts, and values that connect each terminology together. The Scrum
Guide was developed by Ken Schwaber and Jeff Sutherland (Scrum Guide,
2020). Now, most students looking to become a Professional Scrum Master
utilize this guide to brush up for the test.
So, why not learn more about the Scrum Guide and how Schwaber and
Sutherland brought this informative guide into the existence of Professional
Scrum Masters? According to the Scrum Guide, 2020, Schwaber and
Sutherland created the guide to help people globally learn and understand
Scrum. They first published the guide in the year 2010 to put a definition to
the Scrum Framework, since no one really could provide a solid definition
(Corry, 2019). However, after constant adjustments and research, they finally
did it and made it free for everyone to access.
The first edition of the Scrum Guide contained much more information and
recommended practices that have been removed from future editions.
However, Corry (2019), states that the empirical process theory in the first
edition was prominent from the beginning. Moreover, it also included
Release Planning, which was in the same field as Sprint Planning, but which
was removed as well.
After the success of their first release of the guide, the authors felt that they
could improve it even more. Hence, they released a second version in the
later part of 2011. The 2011 version of the Guide was much more refined,
and the authors had more organization to the Guide. This second version
described Scrum as a framework where people could solve complex adaptive
problems, while productively and creatively delivering high-quality products
(Corry, 2019). You can see how the definition of the Scrum Framework has
changed since this period in time. Furthermore, the roles like Scrum Master,
Product Owner, and Developers were more articulated, especially the Scrum
Master section.
Another term that is unfamiliar today is Grooming. The authors had
described grooming as the practice of learning about the method. However,
due to negative associations with the word, the authors removed it in newer
editions (Corry, 2019). What’s more, the Sprint Plan was coined as a
forecast, not a commitment, which was updated in newer versions.
Subsequently, after two years passed, the authors released the third version in
2013.
Basically, the authors added the Refinement and better in-depth questions to
the Daily Scrum. All three of the questions were aimed at the team’s
accomplishments in achieving the Sprint Goal. Additionally, the Product
Backlog was focused on more in the third version (Corry, 2019). However,
after publishing three different versions, it became a habit and a purposeful
idea to publish updated versions of the Scrum Guide so that future
discoveries of Scrum and international learners could continue having access
to this resource.
The fourth edition of the Scrum guide was published in 2016. This guide
dealt mostly with the Scrum Values since they were not in the previous
guides. The Values that were added are Respect, Commitment, Focus,
Openness, and Courage (Corry, 2019). Nowadays, these values are
considered the lifeblood of Scrum and are essential to helping Scrum Teams
deliver on time. As long as Scrum Teams are operating and living by these
values, then they can surely accomplish any project with success and
commitment.
The fifth edition of the Scrum Guide was the 2017 Version. This version
contains lots of revisions to the roles, the Scrum events are better-defined,
and the Sprints are changed as well (Corry, 2019). Therefore, the Scrum
Guide has come a long way, and it has been made more inclusive to other
fields and industries.
Now that you got a jot down of this guide, you will see how it can be helpful
to you. The purpose of this chapter is to understand the changes made from
the 2017 Scrum Guide to the 2020 Scrum Guide so that you can be prepared
when you are taking the exam. One thing to note is that the Scrum Guide has
a pattern of updating from every one, two, or three years. Then, it looks to
repeat this process. Therefore, by understanding this pattern, especially those
of you who may come across this course late, will know you need to review
the changes in the guide to prep for the exam.
Changes Over Time
If you look back at the 2017 Scrum Guide, you will see that the language
concerning the subject has become more prescriptive (Scrum Guide, 2020b).
This means that the 2017 Guide focused on how each word should be used;
for example, changes to the wording concerning the Scrum Master role.
However, the 2020 Guide breaks down this format to make the guide easier
to understand. Specific things that were changed were the removal of Daily
Scrum questions, an easier breakdown of Product Backlog item (PBI)
attributes and Sprint Backlog, and shortening the Sprint cancellation.
Another thing that was changed was the divisiveness in roles concerning the
teams. The 2017 Guide deals with one team, but it separates the people
within that team by classifying teams like Scrum Teams, Developer Teams,
and Product Owner (Scrum Guide, 2020b). Thus, the 2020 Guide classified
these different groups as just one Scrum Team with no other titles. Moreover,
the Product Owner (PO), Scrum Master (SM), and Developers are only
separated in title roles in the accountabilities section of the guide.
The 2020 Guide has also added another section concerning the Product Goal,
which 2017 did not have. This section introduces the idea of the Product Goal
by defining its purpose of providing a focus for the Scrum Team.
Additionally, this section talks about how the Sprint should focus on bringing
the product closer to the Product Goal. Clarification and identification were
also provided on the Sprint Goal and Definition of Done.
The 2017 Guide provides a brief definition of the Sprint Goal and Definition
of Done, without going further into their meaning or purposes in the Scrum
process. These terminologies were considered a part of the artifact in the
2017 guide and did not give any preferences on how the team should value
the Sprint Goal, Definition of Done, and also the Product Goal. However, the
2020 Guide changed this around by adding them as commitments under the
main artifacts. For example, the Product Backlog now has the Product Goal
as its commitment, the Sprint Backlog has the Sprint Goal, and the Increment
has the Definition of Done, which was covered in the previous chapter.
What’s more, the previous Scrum Guide, including past ones, referred to the
Development Team as self-organizing, which means they choose who they
work with and how to work (Scrum Guide, 2020b). Well, the 2020 Guide
focuses more on the team mentality by changing the self-organizing
Development Team to self-managing the Scrum Team as a whole, which
includes every role in the Scrum Process.
The next change made in the 2020 Guide was making the Two Sprint
Planning topics into the Three Sprint planning topics. The reason is that the
2017 version only covered the “What” and “How”, while the third choice
“Why” was added in reference to the Sprint Goal. Another thing that the
2020 guide has done is eliminate redundant and complex statements such as
words relating to IT (Scrum Guide, 2020b). These words include testing,
system, design, requirements, and so on. The Scrum Guide 2020 language is
simpler and it is now less than 13 pages.
2017 vs. 2020 Comparison
In order to fully understand the changes added to the guide. This section
highlights the 26 main changes that have occurred from the 2017 Scrum
Guide to the 2020 Scrum Guide. These changes were provided by Ignacio
Paz (2020) in the breakdown of both guides modifications:
1. Empiricism and Lean. The 2017 Scrum Guide states that Scrum
is founded on empiricism. However, the 2020 Scrum Guide now
states that Scrum is founded on both empiricism and lean
thinking.
2. Development Team to Developers. As stated earlier in this
Chapter, the 2017 Guide had separated the team based on roles.
For example, the 2017 Guide had a Scrum Team which consists
of the Development Team, Scrum Master, and Product Owner.
Well, the 2020 version states that the Scrum Team consists of
the Developers, Scrum Master, and Product Owner.
3. Roles to Accountabilities. The 2017 Guide highlights the term
“Roles”, which has now been replaced with the word
“Accountabilities”. This is to make the Scrum Team one group
instead of subsets of groups within a team.
4. Self-Managing. As mentioned earlier, the self-organizing term
coined in the 2017 guide has been removed from the 2020 guide
and replaced with self-managing.
5. Recommended Size of Team. The 2017 Scrum Guide stated that
the Development Team size was 3-9 people. Now, it has been
replaced with the Scrum Team of 10 or fewer in the 2020
edition.
6. Skills of the Team. In the 2017 Scrum Guide, the Scrum Team
skills are cross-functional and self-organizing. While the
Development Team skills are cross-functional, self-organizing,
and not having any titles or sub-teams. The 2020 Scrum Guide
changes this to Scrum Team skills are cross-functional, selfmanaging, no sub-teams, and no-hierarchies.
7. Scrum Team Responsibilities. The 2017 Guide describes the
responsibilities as incremental deliveries of “Done” products.
While the 2020 Scrum Guide describes the responsibilities as a
cohesive unit. Meaning all product-related activities, while also
creating a valuable and useful increment every Sprint.
8. Product Owner Responsibilities. The 2017 Guide had that the
Scrum Owner responsibilities can be delegated over to the
Development team. Now, the 2020 Guide states that it can be
delegated to others.
9. What is the Scrum Master Accountable for? The 2017 Scrum
Guide says the Scrum Master is accountable for establishing the
Scrum, while the 2020 Scrum guide says the Scrum Master is
accountable for the Scrum and the Scrum Team’s effectiveness.
10. Scrum Masters serve to? In the 2017 version, the Scrum Master
serves the Product Owner, the Development Team, and the
Organization. The 2020 Guide is exactly the same but the
Development team was changed to the Scrum Team.
11. Events held at the same time and place. If you remember from
the previous chapters, this is based on the Daily Scrum Event.
The 2017 Guide described the Daily Scrum as an event that
happens at the same time and place. Now, the 2020 Guide
describes this with all the Events in the Scrum Process.
12. Sprint Planning Invitees. The 2017 Scrum Guide states that the
Sprint Planning invitees are invited by the Development Team.
Under the 2020 Scrum Guide, they are invited by the Scrum
Team.
13. Sprint Planning Topics. The original topics according to the
2017 Guide were “What” and “How”. The topics now include
“Why” in the 2020 Guide.
14. Meet After Daily Scrum. The 2017 Scrum Guide did not classify
when, but the 2020 Scrum Guide provides the information that
Developers often meet throughout the day.
15. Sprint Review Stakeholders. During the Sprint Review, the
Product Owner usually invited the Stakeholders in the 2017
Guide. Now, there is no specification of who invites the
Stakeholders.
16. Sprint Review demo and steps. In the 2017 Guide, the Product
Owner explains the items that were Done in a Demonstration by
the Development Team. Moreover, the PO presents prescribed
steps about who has done what. In the 2020 Guide, the Scrum
Team now presents and the attendees can collaborate on what to
do next.
17. Improvements from the Retro. The Sprint Backlog in the 2017
Guide was described as containing at least one process
improvement. In the 2020 Scrum Guide, the Sprint Backlog is
described as containing process improvements.
18. Sprint Backlog. The 2017 version has a set of Product Backlog
items that was selected for the Sprint under the (what), as well as
an actionable plan for delivering the increment under the (how).
The 2020 Guide includes all of this plus the Sprint Goal under
the (why).
19. Refinement. The 2017 Guide states refinement as per usual
consuming no more than 10% of the capacity of the
Development Team. The 2020 guide puts it as needed for
refinement.
20. Product Goal. The 2017 Scrum Guide did not provide its
purpose clearly because it was not required. Now, the 2020
Scrum Guide provides the Product Goal as a Commitment of the
Product Backlog.
21. Artifact Commitments. The 2017 Guide provided that the
Artifact commitments were based on monitoring progress
toward the goals and Sprint progress, and the Definition of Done
as the artifact transparency. The 2020 Guide replaced this with
commitments by making the Product Backlog commitment the
Product Goal, the Sprint Backlog commitment the Sprint Goal,
and the Product Increment the commitment of the Definition of
Done.
22. 1+ Increments per Sprint. This was not made clear in the 2017
Scrum Guide. The 2020 Scrum Guide explains this as being able
to deliver one or multiple increments per Sprint.
23. Born of Increment. Again, this was another thing not specified in
the 2017 Scrum Guide. However, the 2020 Scrum Guide
specified this as a Product Backlog item which meets the
Definition of Done.
24. Release before the Sprint Review. This was not clarified as well
in the 2017 Guide. The 2020 Guide clarifies the release can be
explicitly allowed before the Sprint Review.
25. Potentially releasable, valuable, and usable. In the 2017 Scrum
Guide, the term potentially releasable increment was used. Now,
the 2020 Scrum Guide replaced “Potentially” with “Valuable”
and “Usable Increment”.
26. Definition of Done. This section in the 2017 Guide talks about
how the Definition of Done can only be defined by the
Development Team. Well, in the 2020 version, the Definition of
Done can be defined by the Scrum Team as a whole.
Review and Exercises
These 26 changes sum up the updates that were made to the 2017 Guide.
Therefore, it is imperative that you have an understanding of the updates in
both guides so that you will know how these changes may have affected the
questions related to the PSM1 Exam. Things to remember:
●
●
●
●
●
●
●
The 2020 Guide has also added another section concerning the
Product Goal, which 2017 did not have.
The Product Backlog now has the Product Goal as its commitment,
the Sprint Backlog has the Sprint Goal, and the Increment has the
Definition of Done, which was covered in the previous chapter.
The 2020 Guide focuses more on the team mentality by changing the
self-organizing Development Team to the self-managing Scrum
Team.
In the 2020 version, the Definition of Done can be defined by the
Scrum Team.
Thus, the 2020 Guide classified the PO, DT, & SM as just one Scrum
Team with no other titles.
The next change made in the 2020 Guide was making the Two Sprint
Planning topics into the Three Sprint planning topics.
Another thing that the 2020 guide has done is eliminate redundant
and complex statements such as words relating to IT.
PSM1 Exam Example Questions
1. Which team creates the increment?
a.
b.
c.
d.
The Product Owner.
The Scrum Team.
The Developers and the Product Owner.
The Developers.
2. What are some of the inputs of Sprint Planning? (Choose all that apply).
a.
b.
c.
d.
The Sprint Backlog.
The projected capacity of the Developers during the Sprint.
The most recent Product Increment.
Feedback from the Stakeholders.
3. Scrum allows additional meetings, especially when they are defined in the
Scrum process.
a. True
b. False
4. Who is generally accountable for the Product Backlog?
a.
b.
c.
d.
The Scrum Master and the Developers.
The Product Owner and the Developers.
The Product Owner is responsible.
The Scrum Master.
5. The Meeting in which the Stakeholders can participate is?
a.
b.
c.
d.
The Retrospective.
The Sprint Review.
The Daily Scrum.
The Sprint Planning.
6. If an item cannot be completed in the Sprint Backlog by the end of the
Sprint, then it must be canceled.
a. True
b. False
7. It is good practice to deliver Increments of potentially releasable functions
that abide by the Scrum Team’s definition of “Done”.
a. True
b. False
Answers
1. D.
2. B & C.
3. B.
4. C.
5. B.
6. B.
7. A.
Chapter 8
How to Pass the PSM1 Exam
PSM1 (Professional Scrum Master) Exam consists of a test with multiplechoice, single answers, and true or false questions to determine if a
participant understands the basics of PSM. Upon completing the PSM1 Exam
with a grade of at least 85%, the participant will receive lifetime certification.
The exam is conducted online at an economical cost by Scrum.org, it has a
total of 80 questions, and the tester has 60-minutes to complete the entire
exam. You might be wondering if you should take the PSM Exam.
The PSM exams are for those who want to work in Agile Scrum and show
that they have mastery and are proficient in their knowledge, the PSM
Certification would look good on your resume and increase your likelihood
of getting hired. The PSM Exam is also effective for individuals who are
currently functioning in an agile environment and desire to enhance their
technique. If this sounds like you, then continue reading to find out how you
can achieve an 85% or higher on your PSM1 Exam.
How to Pass the Exam
With all the information on the Internet about how to pass the Professional
Scrum Master 1 Exam, it can be overwhelming to figure out where to begin.
That is why this course was designed to alleviate the stress of passing your
exam and being your one source to getting passing results. The PSM1 Exam
is not difficult to pass when you are fully prepped and have put your attention
on the core components of the exam.
It is important for you to consistently do practice tests and refer to the lessons
in this course until you can achieve a high grade on the practice tests. Practice
makes progress. This course has plenty of practice quizzes and lessons for
you to utilize to strengthen your ability to solve and comprehend the
questions about the Scrum Framework. There are also free Open Assessments
you can take online to assess your knowledge of Scrum, but this course goes
in-depth.
Even though the level of difficulty and questions on the Open Assessment is
not the same as the certification exam, it serves as a great guideline and
practice for you to understand what the Professional Scrum Certification
exam will require. If you missed a question on the open assessment, you will
need to revisit those sections of the course to ensure you are comprehending
the lessons taught.
The review questions and exercises should not be skipped and are set up to
help you think in an Agile Environment. If you find it hard to complete the
end-of-chapter review questions and exercises, repeat the chapter and take
notes of the applicable areas in which you struggle.
Exam Structure
The hardest part of the exam is the limited time given, as you need to be
aware of the terminologies so that when taking the exam, you don’t have to
spend extra time thinking through it. It is recommended to go through the
course at least three times before attempting to take the exam. In order to get
a score of 85% you need to get 68 questions right, so be sure to answer all
eighty questions and to read them carefully to avoid making any mistakes
during your exam.
Timing is everything, and you want to select the best time to take the exam.
The great thing is that the exam is online and you can take it anywhere there
is a stable internet connection. Be sure to clear your surroundings of any
distractions for the entire hour-long duration of the PSM Certification
Assessment so you can focus and get the best results. Pay attention to the
wording used in each question, as one misinterpreted word could cost you
points. Frequent misinterpretation occurs between the words “should” and
“could”, as well as with the words “attend” and “participating”.
If you struggle with a question, jot the number down so you can come back to
it later and move on to the next question. Remember, the hardest part of the
PSM exam is the time restriction, therefore, have a timer in close corners to
keep track of the number of minutes you have remaining. If you dedicate
most of your time to practicing the questions for the exam, it will make it
simple for you to identify the correct options for most of the questions on the
exam.
As a result, you will have more time to solve the few intricate questions. It
can also be effective to make notes of the subjects and questions that you
found to be the most challenging so you can have them handy when it's time
to take the real exam. Be aware that you may have multiple choice questions
with 8-10 options to choose from, do not let this overwhelm you, and
remember the concepts in the course. You can then begin to subtract the
options that are obviously incorrect to narrow it down to the correct one.
There are also a couple of questions with long scenarios that will take up
some time with you reading the scenarios and comprehending, don’t let them
stress you out and you will have no problems. You can expect to come across
questions on the concept on Scaled Scrum, Burn-down charts. The exam does
allow for open-book and any additional forms of research, however, stay
from Googling answers on the test as you will most likely not find the exact
answers and waste precious time looking through Google page results.
Review and Exercises
The PSM1 Exam is lengthy and will test you on every component studied in
this course. The key to acing the exam is being prepared and pacing yourself
throughout the 60-minute duration. The review and exercises section contains
a review of the most important information:
●
●
●
●
●
Scaled Scrum - Scaled Scrum is when taking a single product or
process and expanding so it can be implemented and done by a team
to reduce the workload and increase efficiency (Scrum.org, 2021).
Burn-down Charts – A Burndown Chart is an agile tool that displays
a graphic of what tasks need to be done and how much time is left to
complete the tasks (Blackburn, 2019).
When taking the PSM Exam, make sure to distinguish between
“should” and “could”, as well as the words “attend” and
“participating”.
A score of 85% is needed to pass, meaning you need to answer 68
out of 80 questions correctly.
Always review the questions you missed on the open assessment and
revisit those sections of the course.
●
Use the process of elimination when you have multiple choice
questions with 8-10 options to select from.
●
The hardest part about the PSM1 exam is limited time, you can
counter this by going through the course three times and being aware
of the terminology and concepts.
PSM1 Exam Example Questions
1. What does the Burndown Chart show?
a.
b.
c.
d.
The change and amount of uncertainty during a project.
Dependencies start times and stop times.
How much work remains until the end of the Sprint.
The hierarchy of tasks.
2. What is the set order of items in the Product Backlog?
a. From A-Z.
b. The unclear items at the top.
c. Less valuable items at the bottom. Most unclear items at the
bottom.
d. New items at the top.
3. The CEO requests that the Developers add an important item to a Sprint.
What must the Developers do?
a.
b.
c.
d.
Add the item during the next Sprint.
Add the item to the current Sprint and remove another item.
Add the item to any section of the Sprint.
Inform the other team members to decide what to do.
4. The Burndown and Gantt Chart are the same.
a. True
b. False
5. Developers on a Scrum Team should be replaced as needed.
a. True
b. False
6. If the Developers determine that the items cannot be completed in the
forecast. The Product Owner and Developers must review and make the
proper adjustments.
a. True
b. False
Answers
1. C.
2. C.
3. D.
4. B.
5. A.
6. A.
Chapter 9
Conclusion
You are now prepared to take the PSM1 Certification Exam. It has been a
tough and difficult journey getting to this last chapter in this intensive course.
However, the information you learned here has prepared you for the PSM1
examination and made you more knowledgeable about the subject of Scrum
than you were when you first started this course. Some of you might have
already learned about Scrum and Agile, and just needed a refresher. Well,
this course provided you with that plus more.
To recap on what was learned throughout this course:
● The Agile Methodology is based on the idea of delivering increments
that bring business value at a very regular pace. Software that does
not have quality or value will not be shipped, but improved and
targeted for a future iteration (Barcelos & Silva, 2020; Kurnia et al.,
2018). This approach increases the trust customers have in the
deliveries.
●
The Waterfall is actually the traditional method that developers used
to use in the software development process (Barcelos & Silva, 2020;
Kurnia et al., 2018). It is a project management approach where the
project is completed at a specific point in time and moved step-bystep toward ultimate release to consumers.
● The Agile Scrum methodology is based on the idea that a project can
be completed quickly with high quality. Each iteration in Scrum
consists of two- to four-week Sprints (Barcelos & Silva, 2020;
Kurnia et al., 2018; Scrum Guide, 2020). This allows the Scrum
Team to meet the Sprint’s goals and develop a potentially deliverable
product.
●
Scrum Events are meetings that the Team Members attend to keep
the flow of the project going. The meetings include the Sprint
Planning, Daily Scrum, Sprint Review, and Sprint Retrospective,
which are all based on a timeboxed schedule. Moreover, each Event
includes tasks and activities that must be completed and followed
whenever the Scrum Team meets.
●
Scrum Artifacts are based on work and value to provide clear ideas
for inspection and adaptation. Artifacts are meant to maximize
transparency based on key information so that everyone can have the
same understanding of the artifact. The artifacts consist of Product
Backlog, Product Increment, Refinement, and Sprint Goals.
Furthermore, these artifacts have commitments attached to them,
such as Product Goal, Sprint Goal, and Definition of Done.
● Also, the user stories that are used to represent small and epic stories
show the various aspects of the solution Scrum Teams need to
deliver, or the number of options they have to satisfy.
It is recommended that if you do not feel that you remember 100% of the
information you study, then you should go back and review the review
sections, practice questions, and give this course a second or tenth readthrough to mentally provide yourself with the confidence you need to take the
exam. Remember, the goal of this course is not for you to barely pass at the
85% level. No, the goal is for you to pass with a 90-100%, knowing that you
did your best on the first try.
Also, even though some of you may be taking the test again, this time around,
the main purpose is for you to become a certified Professional Scrum Master
when you take that test. This is the main goal of this course. Furthermore,
keep in mind that the Scrum Guide has been updated since 2020 as discussed
in the previous chapters, so the exam questions you practiced in this course
may differ from others you can find online, but they will definitely prepare
you for the examination.
Resources
The best resource that can be recommended is this book. It will prepare you
and provide you with the practice you need to succeed. You can also check
out the 2020 Scrum Guide which will be helpful as well, and the 2017 Guide
to reflect on and analyze everything you have learned throughout this course.
Going through these two guides will also let you see how the Scrum
Methodology has changed, and by doing so you will be prepared for when
the next change comes because you are already familiar with the guide.
It is also recommended that if you want to know fully about Agile, Scrum,
and the Waterfall method, plus any other hybrid methods, you can find the
original papers published or copies online and review them for yourself. This
will give you a deeper understanding of how the Scrum Framework came to
be, and you might discover new frameworks and methodologies that are
racing to become the top methodology for working in the technology
industry, or in any industry.
Furthermore, you can also find the Agile Manifesto that was published by the
17 software professionals and add it to your collection of studies. Although
you are preparing for the Scrum exam, it is always better to be familiar with
the field of Scrum and to know all the methodologies. This includes the
current methodologies and the ones that have come before, or to put it in
better terms, the ones that paved the way for these new methodologies.
However, just to reassure you, the Scrum Framework is still in the growing
process and it will be a long while before any new methodologies take its
place. The same thing could be said about the Waterfall methodology. No
one predicted that a new system would replace it or even compete with it
(Varhol, 2015). Developers were complaining about the difficulty of the
method and how they needed something better to work more efficiently and
quickly for developing software. Well, out of nowhere a few experts decided
to tackle the issue and introduce a new system that was already being talked
about, but it did not have a form or setup.
They took all the information they had in articles and books, and from their
experiences, and implemented the information to form a new process. Well,
this same methodology can apply to you as well. You do not know what new
system you will create based on the experience and information you learned
throughout this course. You could even create the next working software
development system that is easier and faster to learn. That is why it is
important to study the methodologies that have existed over the years.
You decided to pursue becoming a Professional Scrum Master because this
field interested you, and you were fascinated by the jargon and terms
concerning these methodologies. You do not have to run out and buy every
book or article on all the methods, but you can make this a daily habit where
you read one or two articles, 3-5 pages, or just set time aside that you will use
to learn about the history of software development and work-related
methodologies.
Hence, depending on the career choice you are pursuing pertaining to being a
Scrum Master, people in your workplace will come to you for advice and
insight because you will have an edge over those who are only studying for
the Scrum methodology for certification. Lastly, the best advice one can give
you is that preparation is 10% while mental toughness is 90% when it comes
to taking the exam. If you are mentally prepared based on the confidence you
gained from doing a few rereads in this course, then you will be 100% ready
to pass the exam and call yourself a Professional Scrum Master.
If you enjoyed this book and found some benefit in reading this, I’d like to
hear from you and hope that you could take some time to post a review on
Amazon. Your feedback and support will help this author to greatly improve
his writing craft for future projects and make this book even better.
I wish you all the best in your future success!
References
Altexsoft. (2018). Acceptance criteria: Purposes, Formats, and Best
Practices.
https://www.altexsoft.com/blog/business/acceptance-criteriapurposes-formats-and-best-practices/.
Agile
Alliance.
(2017).
What
is
a
Scrum
https://www.agilealliance.org/glossary/Scrum-master/#q=~
(infinite~false~filters~(postType~(~.
Master?
Alexander, M. (2018). Agile Project management: 12 key principles, 4 big
hurdles. https://www.cio.com/article/3156998/agile-project-management-abeginnersguide.html#:~:text=Although%20incremental%20software%20development%20methods%
Barcelos Bica, D. A. & Silva, C. A. G. d. (2020). Learning process of agile
scrum methodology with lego blocks in interactive academic games:
Viewpoint of students. IEEE Revista Iberoamericana De Tecnologías
Del Aprendizaje, 15(2), 95-104. doi: 10.1109/RITA.2020.2987721.
Blackburn, M. (2019). Burndown chart: What is it & How do I use it?
https://www.projectmanager.com/blog/burndown-chart-what-is-it.
Corry, P. (2019). The evolution of the scrum guide - ‘10 to ‘19.
https://medium.com/serious-scrum/the-evolution-of-the-scrum-guide10-to-19-f3ac4d82cfcb.
Eby,
K. (2016). Comprehensive guide to the agile manifesto.
https://www.smartsheet.com/comprehensive-guide-values-principlesagile-manifesto.
Firdaus, M.B., Patualak, I. M., Tejawati, A., Bryantama, A., Putra, G. M., &
Pakpahan, H. S. (2019). Agile-scrum software development
monitoring system. International Conference on Electrical, Electronics
and
Information
Engineering
(ICEEIE),
288.293.
doi:
10.1109/ICEEIE47180.2019.8981471.
Hering, M. (2015). Waterfall or Agile - Reflections on Winston Royce’s
original paper. https://notafactoryanymore.com/tag/winston-royce/.
Jalote, P. (2004). The timeboxing process model for iterative software
development.
Advances
in
Computers,
62,
67-103.
https://doi.org/10.1016/S0065-2458(03)62002-4.
Kalweit, R. (2020). How to scale responsibilities from scrum team to C-level.
https://medium.com/quandoo/how-to-scale-responsibilities-fromscrum-team-to-c-level-68b44084fb1a.
KnowledgeHut.
(2019).
Who
is
a
Scrum
Developer.
https://www.knowledgehut.com/blog/agile/who-is-a-scrum-developer.
Kurnia, R., Ferdiana, R., & Wibirama, S. (2018). Software metrics
classification for agile scrum process: A literature review.
International Seminar on Research of Information Technology and
Intelligent
Systems
(ISRITI),
174-179.
doi:
10.1109/ISRITI.2018.8864244.
Lamelas, A. (2018). Top 5 main agile methodologies: Advantages and
disadvantages.
https://www.xpand-it.com/2018/10/11/top-5-agilemethodologies/.
Lotz, M. (2018). Waterfall vs. Agile: Which is the right development
methodology for your project. https://www.seguetech.com/waterfallvs-agile-methodology/.
McCloskey, H. (2019). The definition of Dine: What product managers need
to
know.
https://www.productplan.com/agile-definition-ofdone/#:~:text=Defining%20the%20definition%20of%20done,story%20can%20be%
McKnight, W. (2014). Chapter sexiteen - agile practices for information
management. Information Management, pp. 168-178. Boston.
https://doi.org/10.1016/B978-0-12-408056-0.00016-3.
Mersino, A. (2019). What is agile and why is it important?
https://vitalitychicago.com/blog/what-is-agile-and-why-is-itimportant/.
Naik, N. & Jenkins, P. (2019). Relax, it’s a game: Utilising gamification in
learning agile scrum software development. IEEE Conference on
Games (CoG), 1-4. doi: 10.1109/CIG.2019.8848104.
Paz, Ignacio. (2020). Scrum guide 2020 vs scrum guide 2017.
https://docs.google.com/document/d/1xcD9NfoIVyN5ba7WR6QRSX47QC7gWvIzEkUTBib-SQ/edit?
fbclid=IwAR3tQNVsxHPqDoLuLHN24O4gf6_3tq8G1dyvT3QJGHc7NAd5cRmpposXZE#.
Saha, D. (2019). Why agile is important in software development.
https://www.c-sharpcorner.com/article/why-agile-is-important-insoftware-development/.
Scrum.org.
(2020).
Become
a
professional
Scrum
https://www.scrum.org/become-professional-scrum-trainer.
Scrum
Guide.
(2020).
The
2020
https://www.scrumguides.org/scrum-guide.html.
scrum
Trainer.
guide.
Scrum Guide. (2020b). Changes between 2017 and 2020 Scrum Guides.
https://www.scrumguides.org/revisions.html.
Scrum
Alliance.
(2019).
Overview:
What
is
https://www.scrumalliance.org/about-scrum/overview.
scrum.
Varhol, P. (2015). To agility and beyond: The history - and legacy - of agile
development. https://techbeacon.com/app-dev-testing/agility-beyondhistory-legacy-agile-development.
Visual
Paradigm. (2018). What Are The Three Scrum Roles?
https://www.visual-paradigm.com/scrum/what-are-the-three-scrumroles/
Visual Paradigm. (2020). Agile tutorial: How to identify scrum project
stakeholders.
https://www.visual-paradigm.com/tutorials/agiletutorial/how-to-identify-scrum-projectstakeholders/#:~:text=scrum%20project%20stakeholders,What%20is%20stakeholder%20in%20scrum%3F,project%20throughout%20the%
Who is the Scrum developer: role and responsibilities - QRP International.
(n.d.).
Belgium.
Retrieved
February
27,
2021,
from
https://www.qrpinternational.be/blog/glossary/who-is-the-scrumdeveloper-role-andresponsabilities/#:~:text=Scrum%20Developer%20responsibilities&text=Achieve%