Scrum Theory

To summarize all of this, Scrum makes more sense if there are lots of unknowns. It is also more appropriate if projects are more complex, and difficult to define and estimate at the start.

Applying Scrum is not always easy, and you need to be careful to ensure an organization is ready to implement this kind of workflow. An organization is not ready for Scrum if team members have not received training in the appropriate Scrum roles; this also holds true if people are not open to learning new practices. It is very common to see environments where the Scrum team is trained but the project owner is not. I recommend that you don’t start using Scrum until everyone has received proper training and is on the same page.

SCRUM THEORY

Welcome to the Scrum theory section where I will go deeper into the details and you will learn more specifics about this framework.

Scrum is based on empiricism: that is knowledge acquired from experience. Making decisions with empiricism is based on what is known, not assumed. Scrum uses an iterative and incremental approach to improve predictability and reduce risk. In this environment, we rely on transparency, inspection, and adaptation. Do you recall that I have been mentioning inspection and adaptation throughout the course?

In Scrum, transparency is an important value because the team improves by experimenting and doing. Without transparency, a team would not be able to inspect and adapt. In order to practice this transparency, a Scrum team needs a common language, shared by all participants. Moreover, a common definition of what it means for a project to be done needs to be agreed upon and shared; this way, the entire team has a common goal. Definition of done is the criteria to be met before a product increment is actually considered done. If the criteria are not met by end of a sprint, the work cannot be classified as done. This product increment, by the way, is often called a user story. I will talk about user stories in a later chapter.

The Scrum Master needs to take care to ensure that the artifacts are completely transparent. Artifacts are used to provide key information to the whole team about the health of the project. This key information is about the product under development, any planned activities, and completed activities.

During this course, I have also talked about inspection. The Scrum Master and skilled inspectors need to inspect both the scrum artifacts and progress towards the sprint goal. When inspecting the scrum artifacts, the skilled inspectors can easily identify undesirable variances.

Once an inspector finds an undesirable variance, the process or the material being developed needs to be adjusted. A fix needs to be made as soon as possible to minimize further deviation. This approach can be easily accomplished within the Scrum framework. The traditional workflow method would require a longer time to make adjustments because the project has been planned using some assumptions that can be difficult to modify.

We use scrum events, also called scrum ceremonies, to implement inspection and adaptation. The scrum events are sprint planning, daily scrum, sprint review, and sprint retrospective. I will talk about scrum events later in a chapter dedicated solely to this topic.

To apply transparency, inspection, and adaptation, the scrum team needs commitment, courage, focus, openness, and respect. The Scrum Master needs to be watchful that the team is living and practicing these values. Without them, transparency, inspection and adaptation will be difficult to achieve.

Scrum supports a continuous collaboration between the customer and the team. The customer is even involved in the sprint demo, where the team shows what was completed in that particular sprint. Scrum also needs to be executed in a timeboxed approach where the product owner provides continuous feedback; this way, the final product doesn´t deviate from the business's original needs.

As I just mentioned, one important advantage of Scrum is customer involvement during each sprint of the project. Sprints have short durations so the team must plan prioritized user stories within each sprint. The product owner understands, of

course, the customer's priorities; the owner can prioritize the user stories in the backlog, based on the business's needs. The backlog is a list of all user stories that need to be developed. In Scrum, you can find two kinds of backlogs. The Sprint Backlog is a list of user stories that will be developed in that specific sprint. The Product Backlog is a list of all user stories that can be developed for that specific product.

Please be aware that, at the beginning of each sprint, the team decides what user stories will be developed in that sprint. The team will choose the prioritized user stories from the product backlog. Meanwhile, the product backlog may be altered if the business needs change. Alterations in the product backlog will not impact the development team because they are focused on the sprint backlog.

It could also happen that the customer needs an urgent change request that needs to be developed in the current sprint. In this case, the Scrum Master and the development team will determine if this change can be absorbed into the current sprint; they will consider what impact it may have on the sprint. Another option would be to prioritize the change request to include it in the next sprint. In the scrum environment, the development team can quickly adapt and respond to the customer´s requirements.

Employing the scrum framework helps an organization to reduce overhead and avoid redoing completed work; this, because the team focuses on developing the prioritized user stories. As a result, an organization will enjoy increased efficiency of the development team, and the customer will be more satisfied. All of this will increase the market potential of the organization.

In Scrum, product managers are known as product owners. As I will explain later in this audio course, the product owner is responsible for customer satisfaction. This is easier to achieve in Scrum because the team can respond faster to new requests from the customer.

Many project managers take on the role of Scrum Master when the organization starts working under Scrum. The role of Scrum Master is slightly different from the role of Project Manager, and you will learn about those differences in this course.

Scrum is a collaborative framework that facilitates planning and tracking for the project manager. Some tools used to track a project’s progress are the burndown chart and the daily scrum meetings. The burndown chart is a graphic that indicates how much work remains for the rest of the sprint. With this information, the Scrum Master can easily forecast if all work will be completed on time. The daily scrum meetings are short daily meetings; team members discuss what has been done, what they will be doing, and what obstacles they have encountered. From there, they can request support to help them eliminate any roadblocks. I will explain more about these daily meetings in the Scrum Events chapter.

In Scrum, the work delivered at the end of a sprint can be used immediately. That tends to make the development team more enthusiastic about completing individual sprints. Work can be used immediately because the sprints are time boxed and because the development team delivers product increments. This collaborative spirit promotes job satisfaction and enjoyment among team members. As the requirements for every sprint are based on customer priorities, the team understands the value of their work.

I will now list the main activities that you, as Scrum Master, might handle in a project. This is just an introduction. I will give more details in a later chapter dedicated to the scrum ceremonies.

Imagine that you have reached an agreement with a company's representative to undertake a project for the organization. Now, you need to create a vision statement and define the product map. In other words, you must outline parameters and goals for the completed project.

Note that the vision statement and product roadmap are critical parts of the project management process. They are well represented in other Agile frameworks, including DSDM Atern. However, these do not belong in the Scrum model.

I will now describe, step by step, all the events that occur before the sprint.

1. The vision statement highlights a clear description of the project goals. This enables the team to remain focused on the organization’s critical point of view. Please be aware that the vision statement is not part of the scrum

guide. However, this is a critical part of a project that needs to be considered.

2. The product roadmap serves as an initial visual timeline of significant product deliverables. It’s ideally created by the product owner an important scrum role that I will explain in a later chapter. The roadmap is another element not described in the scrum guide. However, it needs to be considered in any project to have a global vision.

3. Curate user requirements and change them into deliverable features that are tagged stories. The product owner is responsible for writing these stories while the elements of the stories come from the customer.

4. The product backlog is formed by the entire set of user stories. It’s not necessary to wait until the product backlog is complete before commencing the sprints. You can start a sprint the moment you notice that the product backlog is sufficiently ready for implementation. Also, regarding the product backlog, be sure to update the backlog throughout the project.

Next, let me discuss what takes place just before and during the sprint:

1. The sprint planning meeting. The purpose of this meeting is to determine the components that will make up the sprint. In this meeting, the product owner prioritizes these components. Consequently, the product owner indirectly determines the content of the sprint backlog. As I mentioned earlier, the development team will decide how to deliver this content.

The sprint backlog consists of all user stories that will be developed during that sprint. Please note that the team can break down these stories into smaller tasks. The team will then deliver an agreed upon number of stories at the end of the sprint.

2. The daily scrum meeting. This meeting will be held by the team for fifteen minutes per day to discuss progress and the way forward on the project.