Introduction Agile & Scrum for Product Owner Certification

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.

Scrum does not have a section dedicated to how the first Sprint should start, but initially, just a simple Product Backlog with some ideas is enough to get started.

Remember, the Product Owner is responsible for the Product Backlog.

The Product Owner will talk to the stakeholders and possibly to the customers as well to understand what is needed from a business standpoint.

For the Product Backlog, the Product Owner can use a simple whiteboard, post-its, or anything else to write the Product Backlog, most companies nowadays prefer to work with a software tool. It is important to remember that the Scrum Guide does not impose any specific tool or way of handling the Product Backlog.

There are many options available on the market, a very popular tool is Jira, created by Atlassian.

So any other features or simple ideas regarding the product will land in the Product Backlog.

As you can observe, right from the start, anyone who is involved with building the app, can view the Product Backlog in Jira and its current state. So the Product Backlog is now transparent.

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 Developers, 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 rest of the Scrum Team collaborate and try to make the User Stories (Product Backlog Items) as clear as possible.

If the Developers think a User Story is too large, the best approach is to work with the Product Owner and 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 Developers 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 makes transparent all the work that the Developers deem as necessary to reach the Sprint Goal.

You can view the Sprint Backlog as a temporary artifact that exists only during the Sprint. In Scrum, we say that the Developers "own" the Sprint Backlog. Nobody else can make changes to it.

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 all Increments from all previous Sprints.

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

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.

The Sprint can be canceled if the work that the Scrum Team produces is no longer needed.

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 Developers and the Scrum Master.

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.

By the end of the meeting, the Scrum Team should have identified improvements that it will implement 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

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

Scrum Teams are self-managing and cross-functional.

How big should the Scrum Team be?

If a Scrum Team is too small, they may encounter skill constraints during the Sprint.

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

The Product Owner is one person not a group of people.

The Developers are 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.

The Scrum Master assists the Developers 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 Scrum Team has. The Scrum Master will continually coach the team on self-management and cross-functionality.

One important focus is to help the Scrum 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 Scrum 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.

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.

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.

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.

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 Scrum Team should 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 Scrum Team can handle during a typical Sprint.

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 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)

It is essential to know the ability of the organization to deliver new features, services, or products in a timely manner.

So the focus here is to minimize the Time-to-Market (T2M or TTM).

The ability to innovate (A2I) tries to measure the capability of the organization to come up with new and innovative solutions to customer problems.

Reveals the potential value that the Product could deliver to customers in the future. The goal is to identify the unrealized value and to convert it to Current value.

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

Here are a few tips for dealing with exam question:

- don't confuse the meetings between them

- don't confuse the Product Backlog with the Sprint Backlog

- look for words that can change the meaning: may vs must or NOT

- when unsure, work by eliminating the wrong answers