Scrum Product Owner Certification Prep & 160+ Prep Questions

In this section, we will discuss the Scrum artifacts.

The Scrum Guide defines three artifacts:

• Product Backlog

• Sprint Backlog

• Increment

Artifacts in Scrum represent work or value. They provide transparency and opportunities for inspection and adaptation.

The Product Backlog is made up of an ordered list of everything that is needed in the Product. The Product Backlog is a list of requirements that contains new features, improvements, fixes, or any other changes that need to be done on the Product. As long as the Product exists, so will its Product Backlog.

The items in the Product Backlog are referred to as Product Backlog Items, which have a few characteristics such as description, order, estimate, and value. Product Backlog Items could also include a description of what will help test if the work performed is completed.

How a Product Backlog Item is described, it is left to the Scrum Team. The Scrum Guide does not offer any templates or make any recommendations regarding the format itself. In practice, it is quite common for Scrum Teams to use the User Stories. It is actually so common that the Product Backlog items written as User Stories are simply referred to as stories.

User Stories are short descriptions of a feature explained from the perspective of the person who desires the new feature, usually a user or customer of the product.

The template for a user story looks more or less like this:

As a < kind of user >, I want < some objective > so that < some reason >.

Remember that the Scrum Guide makes no references to User Stories, and they are by no means mandatory in Scrum.

Depending on how Scrum is used, User Stories may or may not be a good way to express that is needed in the Product.

The Product Backlog is continuously changing and evolving, and managing the Product Backlog is something that the Product Owner can not do without getting input from the rest of the Scrum Team.

During the Product Backlog Refinement meeting, the Product Owner and the Development Team, work on making sure that the items are small enough to fit in one Sprint and add details, estimates, and order to the Product Backlog.

During the Product Backlog Refinement meeting, the Product Owner and the Development Team collaborate and try to make the User Stories (Product Backlog Items) as clear as possible.

If the Development Team thinks a User Story is too large, the best approach is to work with the Product Owner and to try to reduce the size but at the same time preserve the value.

An "estimate" in the usual sense is the best guess of the effort necessary to carry out a given task, for example, one Product Backlog item. But as I said, it is the best guess, not a commitment. There is always some uncertainty, and that is fine.

Most teams use an estimation technique called "Planning Poker". The Development Team members will write down a number, without the others seeing it, and they will show their "cards" at the same time. This ensures that they don’t influence each other.

Once a consensus is reached, the Product Owner will write down the estimation.

The Sprint Backlog is created during the Sprint Planning meeting by pulling Product Backlog Items from the Product Backlog into the Sprint Backlog.

In this video, I will show you how you can use Jira to create a Sprint Backlog and how to start a new Sprint.

The increment is represented by all the Product Backlog Items completed during a Sprint and plus the value of all Increments from all previous Sprints. You can view it like a building block that is placed on top of all the previous work completed.

The development team works to deliver a new product increment with each sprint. Each new increment is an improved and usable version of the product.

Before attempting this quiz, please read at least once the following section from the Scrum Guide:

- Increment

- Definition of "Done"

Scrum uses prescribed events (or call them meetings or ceremonies if you prefer) to create a routine and to reduce the need for other meetings that are not defined in Scrum.

A Sprint has a time-box of one month or less in which a potentially shippable product Increment is created. If the duration of the Sprint is too long, the complexity and risk may increase. Having these relatively short horizons is easier to plan what is being built and to get early feedback. It is common for Sprints to be 2 or 3 weeks long.

Canceling a Sprint before the time-box expires is a very very rare occurrence. Only the Product Owner has the authority to cancel the Sprint.

A Sprint can be canceled if the Sprint Goal becomes obsolete or if there are some significant and sudden changes on the market or if the company decides to change direction. In other words, the Sprint can be canceled if the work that the Development Team produces is no longer needed.

Before attempting this quiz, please read at least once the following section from the Scrum Guide:

- The Sprint

- Cancelling a Sprint

The work that will be done in the Sprint will be decided during the Sprint Planning meeting.

This meeting ensures two outcomes: to understand WHAT can be delivered in the Sprint and HOW to make this happen by creating a plan.

The Daily Scrum is held every day during the Sprint, and it is an event intended for the Development Team. During this event, the Development Team plans what work will be performed in the next 24 hours.

This is a key "inspect and adapt" meeting in Scrum. The Daily Scrum helps the Development Team check progress toward completing the work in the Sprint Backlog and reaching the Sprint Goal.

The Sprint Review is held at the end of the Sprint to inspect the Product Increment and adapt the Product Backlog if needed.

The Product Owner owns this meeting and will invite the key Stakeholders to this event. Also taking part are the Development Team and the Scrum Master.

The demonstration of the Increment is done to obtain feedback and encourage collaboration on what needs to happen next.

Before attempting this quiz, please read at least once the following section from the Scrum Guide:

- Sprint Review

The goal of the Sprint Retrospective is to inspect and adapt the process. The Sprint Retrospective is an internal Scrum Team event where no external parties are involved.

So the purpose is to: look into how the Sprint went with regards to people, relationships, processes, and tools.

By the end of the meeting, the Scrum Team should have identified improvements that it will implement in the next Sprint. Once the most significant improvements are identified, it is time to create a plan for achieving those improvements in the next Sprint.

The Scrum Guide does not go into many details when it comes to the Sprint Retrospective and only explains the rules, purpose, and desired outcome.

While the Scrum Guide does not make it explicit, the Scrum Master is typically the one who can plan and organize this meeting.

There are many resources available to help the Scrum Master find such activities. One of the websites I particularly like is called funretrospectives.com

Before attempting this quiz, please read at least once the following section from the Scrum Guide:

- Scrum Events

- Sprint Retrospective

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.

What is important to remember is that Scrum Teams are self-organizing and cross-functional.

The primary responsibility of the Product Owner is to maximize the value of the product resulting from the work of the Development Team.

The Product Owner is one person, not a committee, a group of people, or anything else. The Product Owner may represent the desires of a committee, the CEO, or the Stakeholders in the Product Backlog. Still, those wanting to change a Product Backlog item's priority must make it through the Product Owner.

The Development Team consists of specialists who have all the skills required to do the work needed. Their goal is to create a potentially releasable Increment at the end of each Sprint. It is worth mentioning that only the Development Team members can work on the product Increment.

The Development Team is structured and empowered by the organization to plan and manage their work. In this way, the efficiency and effectiveness of the Development Team are optimized.

How big should the Development Team be?

If a development team is too small, it may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a Product Increment.

Having more than nine members requires too much coordination between them, so the entire process becomes too complicated.

The Scrum Master assists the Development Team and the Product Owner and is responsible for promoting and supporting Scrum within the organization.

You can see the Scrum Master as a "Scrum coach". The Scrum Master is doing this by helping everyone understand the Scrum theory, practices, rules, and values.

The Scrum Master has to defend the empowerment that the Development Team has. The Scrum Master will continually coach the team on self-organization and cross-functionality.

One important focus is to help the Development Team create high-value products. The Scrum Master is successful if the team is successful.

The Scrum Master is also facilitating Scrum events as requested or needed.

The Scrum Master coaches the Product Owner to understand better and practice agility and Scrum. The Product Owner needs to understand and apply the benefits and best-practices of Agile and Scrum.

It also ensures that goals, scope, and product domains are understood by everyone on the Scrum Team as well as possible.

It is also imperative that the Development Team and Product Owner understand the need for clear and concise Product Backlog Items, and the Scrum Master is there to help with this as well.

To maximize value, the Scrum Master will mentor the Product Owner on how to manage the Product Backlog to ensure it is ordered and in a healthy state.

The Scrum Master is leading the change process within the organization and is responsible for the Scrum adoption and planning Scum implementations.

For example, the Scrum Master can interact and collaborate with different departments that are in the process of adopting Scrum in order to succeed. The Scrum Master has to explain why change is necessary and to lead the organization in that direction.

The Scrum Master can collaboratively work with other Scrum Masters within the organization to achieve these goals.

What does the term Agile mean and what where does it come from?

Agile, especially in software development, describes a way under which business requirements and potential solutions emerge through the joint effort of cross-functional, self-organizing teams and their customers or end-users.

The term Agile, used in this context, comes from the Manifesto for Agile Software Development.

Scrum is a process framework used to manage work on complex products, not only in software development.

Using the framework helps people address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

To better understand where Scrum is coming from, it is important to understand what has happened before Scrum was introduced. A lot of software development in the past has been done and is still done using the Waterfall model.

The Waterfall Model originated in the manufacturing and construction industries but since the 1950s it has been used for software development as well. It is also referred to as a linear-sequential life cycle model. It is very simple to understand and use but it does not always produce the desired outcome.

In a Waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in the phases. Similarly to the way water flows the process goes only in one direction.

Scrum helps with the development of products and enhancements. It can also help sustain and renew existing products. But Scrum can also be used to research and identify viable markets, technologies, and product capabilities.

So Scrum is not only used for software development but, along with the Agile mindset, is one of the most common approaches to software development nowadays.

Scrum is founded on empiricism. In case you are not familiar with the term, empiricism asserts that knowledge comes from experience. The three pillars of the empirical process control: transparency, inspection, and adaptation.

The Scrum Guide defines a few values on which the Scrum Teams should be built on: Commitment, Courage, Focus, Openness, Respect. When these values are followed, there is trust.

One important part of the exam is understanding the EBM Guide.

Please read it a few times and understand the key aspects.

https://www.scrum.org/resources/evidence-based-management-guide

Organizations that have adopted the Scrum framework and Agile principles have already significantly increased the value they offer to their customers and end-users.

Having already some success behind them, some organizations fall into the risk of assuming that everything they do is valuable, merely by using Scrum, and this is rarely the case.

Some organizations focus more on optimizing the output of their Development Teams and want to make sure they are constantly busy with work, but more output from the Development Team does not necessarily equal more business value being created.

As you remember, the Product Owner orders the Product Backlog to maximize the value of the Product. New features are regularly added to the Product, but without completing the feedback loop and validating the assumptions made initially, it is easy to lose track of what is going on.

Just because the Product is doing well on the market, it does not mean that what has been built into the Product has directly contributed to the success.

Evidence-based management is all about measuring the impact that the changes made to the Product have on the value delivered. It is all about measuring results and making improvements in the form of a continuous loop.

EBM consists of four Key Value Areas (KVAs):

• Current Value (CV)

• Time-to-Market (T2M)

• Ability to Innovate (A2I)

• Unrealized Value (UV)

In this section, we look at the most important terms used in the Scrum Guide and which you can often encounter in the exam questions.

One or two questions in the real exam could contain a reference to the term technical debt. While technical debt is a term does not appear in the Scrum Guide it is mentioned in the Glossary.

Generally speaking, technical debt is something that should be constantly dealt with and not postponed. It is part of the development process and it is a continuous process (similar to the architecture of the product which is constantly being worked on and improved).

It is tightly coupled with the quality of the product and the Development Team should constantly work together with the Product Owner to keep the technical debt manageable.

One of the charts that Agile projects can use is a Burn-Down chart.

A burndown chart is a graphical representation of work (usually represented in estimated time or story points) left to do versus the remaining time of the Sprint. The remaining work is generally on the vertical axis, with time along the horizontal axis.

In Scrum, this chart can be used to estimate when all of the work in a Sprint will be completed and especially if it will be completed on time.

JIRA offers multiple reporting options, including the Burn-Down chart.

The Burn-up Chart provides a visual representation of a Sprint's completed work related to its total scope, which is represented by the number of selected Product Backlog Items (or Stories).

Velocity is a measure of the amount of work a Development Team can handle during a typical Sprint.

This is calculated by averaging the amount of work performed in the previous Sprints.

Remember that this is an optional metric and intended only for the Scrum Team.

Another term that you may encounter during the exam is related to Feature teams and Component teams and, again, unfortunately, the Scrum Guide does not mention them.

A Feature Team works through all the layers of the application to fulfill a customer or a user need. A Feature team is cross-functional and cross-component because it has all the skills needed to complete a feature and does that by working through all the layers or components of the application.

A Component team (sometimes called a layer team) is focused on a single or multiple components of the system. A component team alone will typically not be able to deliver a new functionality that alone will fulfill a customer need.

A functional requirement describes a function of the Product: for example the possibility of changing the payment information within the app.

Non-functional requirements describe qualities, behaviors, attributes, and constraints of the Product and can be placed into multiple categories: performance, security, availability, and usability, to name just a few examples.

Many Scrum exam questions may include references to both functional and non-functional requirements.

One of the confusing parts in Scrum is how can the Development Team collaborate with the Product Owner to change the Sprint Backlog without affecting the Sprint Goal.