Agile Scrum for Beginners + Scrum Master Certification Prep

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

The Scrum Guide defines three Scrum artifacts:

• Product Backlog

• Sprint Backlog

• Increment

In Scrum, the Product Backlog is an artifact, designed to 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. It a list of requirements that can be new features or 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.

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 are simply referred to as stories.

The Scrum Guide does not impose a specific way of managing the Product Backlog, in terms of how the Product Backlog Items should be written.

It is common for organizations nowadays to use a digital Product Backlog and a Scrum Board. While there are many tools out there, many companies use Jira, created by Atlassian to manage their Agile projects, including Scrum and Kanban.

This video shows how to create a Product Backlog in Jira.

Now the Stories (Product Backlog Items) have a description, a test description, and an order. As you can notice, the Story is not complete yet. The next step would be to take this Product Backlog Item written as a User Story and discuss it with the Team to clarify the details, add order, and to get an estimate.

This collaboration between the Product Owner and the Developers happens during the Product Backlog Refinement meeting.

After the Development Team has estimated a Story, the Product Owner can enter that estimation in the software tool used for managing the Product Backlog, in our case Jira.

The Sprint Backlog makes transparent all the work that the Developers deems as necessary to reach the Sprint Goal.

You can view the Sprint Backlog as a temporary artifact that exists only during the Sprint. The Sprint Backlog is the responsibility of the Developers.

The Developers will modify the Sprint Backlog throughout the Sprint. It is a decomposition of each Product Backlog Item in smaller units of work that allow the Team to build the increment.

The Sprint Backlog is created during the Sprint Planning meeting. The Development Team will pull Product Backlog Items from the Product Backlog into the Sprint Backlog.

This video shows how to create a Sprint Backlog in Jira.

The Increment (or Product Increment) is represented by all the Product Backlog Items completed during a Sprint and integrated with all previous Increments.

It is solely the decision of the Product Owner if and when to release the Increment, but it needs to be in useable condition.

When a Product Backlog Item is considered complete or "done", everyone must understand what done means.

In order to make it easier for everybody to understand that, the Scrum Team should create a Definition of Done which can be used to assess if the work performed is in accordance with the definition.

So each Sprint will create a Product Increment that needs to adhere to the Definition of Done.

As the Scrum Team gains more experience, it is expected that the Definition of Done will contain more strict criteria that ensure higher quality.

By the end of each Sprint, the Increment must be "done", according to the Definition of Done.

This is an example of a Definition of Done for a software product. Each Scrum Team or development organization may formulate the Definition of Done in a different may.

A common topic of confusion is regarding the Definition of Done vs. Acceptance criteria. Let's fix this.

This is the end of this section, and it is time to recap some of the most important aspects in regards to the Scrum artifacts.

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

At the heart of Scrum is the Sprint, which acts as a container for all the events. All events inside Scrum are time-boxed.

Scrum defined the following events:

• Sprint Planning (where the work to be performed in the Sprint is planned)

• Daily Scrum (which is held every day of the Sprint)

• Sprint Review (which is held at the end of the Sprint to review the Increment)

• Sprint Retrospective (which is an opportunity improve the process)

All events that are a formal opportunity to inspect and adapt.

In Scrum, the time-box indicates the maximum duration of an event.

A Sprint has a time-box of one month or less in which a potentially shippable Product Increment is created. A Sprint will contain all the prescribed Scrum events, a flexible plan on how to build the Product Increment and, of course, the development work needed.

A new Scrum Sprint starts immediately after the previous Sprint has ended. There is no gap between Sprints and nothing happens between the Sprints.

The Sprint Planning meeting is time-boxed to a maximum of eight hours for a one-month Sprint.

During this event, the Scrum will agree on a Sprint Goal and discuss which Product Backlog Items from the Product Backlog will be added to the Sprint Backlog.

Once the Sprint Goal has been defined and the Product Backlog Items for the Sprint selected, the Developers discuss how the functionality will be built into a Product Increment.

Work planned for the first days of the Sprint is decomposed by the end of this meeting, often to units of one day or less. Because work emerges during the Sprint, this meeting cannot identify all the work that needs to be done in advance. It is just a plan with enough detail so that the development work can begin.

The Developers should be able to explain to the Product Owner and Scrum Master how they plan to accomplish the Sprint Goal and to create the forecasted Product Increment.

The Daily Scrum is a timeboxed event, held at the same time and place each day to reduce complexity. The Daily Scrum is held every day during the Sprint and it is an event intended for the Development Team.

The Daily Scrum helps the Developers inspect progress toward completing the work in the Sprint Backlog and reaching the Sprint Goal.

Regardless of the size of the team, the Daily Scrum is a 15-minute time-boxed event.

During the Daily Scrum the Product Owner, the Scrum Master, or other parties are not present. This is an internal meeting for the Developers.

A Scrum Board is a tool that helps the Developers make Sprint Backlog items transparent.

The board can be a simple whiteboard with post-its for each task or digital board. Please note that the Scrum Guide does not mention the term "Scrum Board" in the Scrum Guide.

The Scrum Board is constantly updated by the Developers and shows all the work in typically three columns: TODO, In Progress, Done.

By the end of the Sprint, the Scrum Team should have created a potentially shippable Product Increment.

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 Scrum Master's role is to facilitate this meeting and to make sure it is held within the timebox.

The Sprint Review is an informal meeting, not a formal status meeting. The demonstration of the Increment is done in order to obtain feedback and encourage collaboration on what needs to be done next.

What happens with incomplete Product Backlog Items?

So what happens with Product Backlog items that have not been done yet or that are not fully done (for example some functionality has been built but more is needed or testing is not completed yet)? First of all, they will not be demonstrated during this meeting and they should not be part of the Product Increment. They will be put back in the Product Backlog.

The Sprint Retrospective is the very last event in the Sprint, right after the Sprint Review but prior to the next Sprint Planning. The goal of the Sprint Retrospective is to inspect and adapt the development process.

The Sprint Retrospective is an internal Scrum Team event where no external parties are involved.

The Sprint Retrospective is, as implied, a time-boxed event. For a one month sprint, the maximum duration is of 3 hours.

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.

Typically retrospectives made use of post-it notes and pens, and there should be plenty of them available.

The Sprint Retrospective meeting will usually start with an icebreaker or warmup exercise. This step is to kick off the meeting, helps with team building, and to get the group interaction started.

Next, the Retrospective meeting can smoothly proceed with a simple check-in to see how everybody is feeling. One exercise is to draw a smiley face on a post-it and to put it somewhere on the board. This can express, for example, how the last Sprint went.

Next comes the core part of the event. The idea behind the next activity is to gather data about the Sprint. Typically a timebox is set in which each Scrum Team member reflects back on the Sprint and writes down ideas.

Next, the team will try to discuss the most important topics within a timebox. The goal of the meeting is to identify improvements. So the team will discuss the issues that they encountered during the Sprint and will think about possible solutions.

The Retrospective may include a final activity in which the improvements, decisions, or action points identified are clarified.

Canceling a Sprint before the time-box expires is a very very rare occurrence. I actually never encountered this. But you need to be aware of this possibility as well.

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

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

How big should the Scrum Team be?

If the Scrum Team is too small it may encounter skill constraints during the Sprint. Having too many team members is also not a good idea.

Is the Product Owner the Project Manager? The main responsibility of the Product Owner is to maximize the value of the product resulting from the work of the Scrum Team.

So the Product Owner is the sole person accountable for managing the Product Backlog.

The Developers are specialists who have all the skills in order to do the work needed. Their goal is to create a potentially releasable Product Increment at the end of each Sprint.

The Scrum Master assists the Scrum Team 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.

How is the Scrum Master serving the Scrum Team?

The Scrum Master has to defend the empowerment that the Scrum Team has and to coach it regarding self-management and cross-functionality.

The Scrum Master is successful if the Scrum Team is successful.

Not every issue that the Scrum Team encounters is an Impediment. But what is an impediment that the Scrum Master needs to handle?

How is the Scrum Master serving the Product Owner?

The Scrum Master coaches the Product Owner to better understand and practice agility and Scrum. This means that the Scrum Master should coach the Product Owner to understand and apply the benefits and best practices of Agile and Scrum.

How the Scrum Master is serving the Organization

The Scrum Master is leading and coaching the organization in its Scrum adoption and is planning Scum implementations.

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.

Scrum is widely adopted in the software development industry but Scrum is not only used for developing software.

Scrum is based on empiricism (the empirical process control theory). This means that knowledge comes from the past experience and decisions are made based on what is known. Scrum is never about knowing or planning everything in advance.

The Scrum Values are commitment, courage, focus, openness, and respect. Scrum is based on three pillars: transparency, inspection, and adaptation.

Scrum.org provides another framework for dealing with how to scale the Scrum framework. This additional framework is called the Nexus Framework and is described within the Nexus Guide.

Remember that the content of the Nexus Guide is not part of the exam. The Nexus Guide introduces many other terms that will confuse you, so for that reason, I don’t necessarily recommend it.

In this section, we will go over the most important aspects that are relevant for the exam and explain to you all the rules you need to know.

The most important rule you need to remember when multiple teams work on the same Product.

1 Product = 1 Product Backlog = 1 Product Owner

It is important to remember that there is only one Product Backlog. There will not be separate Backlogs for each team.

When multiple Scrum Teams start working on the same Product, different challenges arise.

The key concern, in this case, is to reduce as much as possible dependencies between the teams.

Scrum Teams working on the same Product must integrate their work to produce working and releasable Increments.

Scrum Teams must define a common Definition of Done that all teams must respect.

Scrum does not have a requirement that states that the Scrum Sprints be aligned. The only requirement is that the work should be integrated by the end of the Sprint. If all teams have the same Sprint duration and start/end dates, this is a bit easier to manage.

If the Scrum Teams have different Sprint lengths (so the Sprints are not aligned), this process will be harder but still within the Scrum rules.

It is important to have a single person responsible for the end results.

If one person is involved, it is clear which person is responsible for the results. When multiple persons are involved and things don't work well, it can be an elaborate process figuring out what did not work.

There are no Chief Product Owners (CPO) or Proxy Product Owners (PPO) in Scrum.

The exam may include questions that talk about Feature teams and Component teams. As with many other terms the exam tries to test some practical knowledge but, the Scrum Guide does not mention them.

The Velocity of the Scrum Team (or simply Velocity) is a measure of the amount of work the Scrum Team can handle during a typical Sprint.

Any product regardless of whether it is a software product or not will have technical debt at one point. While technical debt is a term that does not appear in the Scrum Guide it is mentioned in the Scrum Glossary.

In this lecture, we discuss functional requirements (FRs) and non-functional requirements (NFRs).

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

This chart is used to estimate when all of the work in a Sprint will be completed. While burndown charts can be used in agile projects, they can also be applied to any project containing measurable progress over time.

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

It is quite similar to the Burn-down chart with the difference that any added work will be visible in a change of the scope.

The term Cone of Uncertainty is used in software development where the technical and business environments are constantly evolving.

Some exam questions may reference the term sustainable pace. When doing development work, it is important to be able to have a constant output.

Who creates the Definition of Done?

There are two possible options:

• The development organization

• The Scrum Team