Basic concepts

This section provides basic concepts that help to share a common understanding of Scrum, agility and what we expect to get out of them, how to use it, and its value for the company.

Recalling Scrum Process

Let´s take a deeper look on how a Scrum process looks:

The product backlog contains all the change requirements, bug-fixing, improvements, items to be worked out coming from retrospectives, tech-debt related items, and whatever is meaningful to describe something that must be done regarding the product (or project) we are involved with. Every sprint, from 1 to 4 weeks long, the team will be pulling a sub-set of the items in the product backlog, to be worked out within the sprint duration. These items will be picked up in an ordered way, which is defined by the priority property. Once a day, during the sprint execution, a daily meeting is carried on to keep everybody in the team focused on the sprint goal. By the end of the sprint, the Developers must prepare a demo of the increment for the entire team, customer, and perhaps some other stakeholders. The sprint ends up with an activity called retrospective, where the team is going to talk about its performance, what could be improved for the next sprint, what went wrong and must be changed, and what they've proven to be good and should be kept to be repeated in upcoming sprints.

Some aspects to highlight:

• PO is the customer’s eyes during the development process. He is the solely person in charge of managing the product backlog.
• Sprint planning meeting prepares the upcoming sprint, giving the team, with PO assistance, enough information to work without interruptions up to the end of the sprint
• Every 3 weeks, as an outcome of this process, a new increment of the product adding value is provided
• Daily meetings must be focusing the team on how they are performing, keeping the eyes on the committed backlog and due date. The sprint backlog is allowed to be changed by the team during sprint execution, not the product backlog.
• Sprint review helps the team to keep in sync with customer’s (and stakeholders’) expectations, providing sufficient feedback to make necessary adjustments
• Retrospective leverages the team capacity to perform better in upcoming sprints by removing roadblocks, enhancing the process and tools
• Scrum master facilitates the process by removing all the time impediments the team would be facing

Scrum fundamental aspects

It is founded in three fundamental aspects:

• Transparency > we can all see what is going on, reaching the same conclusions
• Inspection > we must be able to observe the process at every step
• Adaptability > make decisions based on what we are seeing

Scrum Values

Scrum promotes five values:

• Focus > we must have it to get things done, provide environment to let them focus on the job at hand.
• Respect > act professionally, respectfully of each other
• Trust > this aspect must be earned, it’s something that develops over time. Without trust, transparency cannot be achieved and good decisions about products are likely to be mislead
• Commitment > to the goal, to each other, to the mission of the organization and to quality
• Transparency (or openness) > Without trust, openness cannot exist. Act with professionalism, be transparent to make the right decisions

Artifacts

Scrum has only three artifacts: product backlog, sprint backlog and increment:

Product backlog

It is a single source of truth. Contains a prioritized list of items to be constructed, with the top-most adding value items at the head of the list (those with higher priority)

• It might be comprised of: Features, functions, defects, requirements, enhancements, bugs, change requests, etc.
• Minimum required attributes for backlog items are description, priority, and effort estimation.
• It is owned by the Product Owner; it is his solely responsibility
• It is constantly changed and “alive”
• Next items to be taken next by the team are those with the higher priority in the list.

It can be noticed that most prioritized items in the list need to be “ready” to be taken, thus they need to be refined and well-understood, while those at the end of the list can be less polished. This guarantees that conversations are always focused on what really matters or adds value to the business.

Sprint backlog

It is a plan with enough details that the team uses throughout the Sprint to guide their decisions towards creating the increment of that Sprint. It is created by the Developers, and it is used by the Developers.

It can be defined more formally as: the set of product backlog items selected for the sprint in conjunction with a plan for turning them into a product increment, to be delivered by the end of the current sprint.

The sprint must be able to show the remaining work in the sprint, because we will focus on the amount of work remaining to meet the sprint goal when reaching the due date. This remaining time must be summarized at least once a day to be able to make the right decisions on time and to keep the team focused on the goal.

The sprint backlog helps the team to make visible all the work necessary to meet the sprint goal all the time. It belongs to the Developers, no one else.

This artifact is a plan for the Developers, so as soon as it starts to work items out, the plan would be changed, and it likely will, because the team understanding about what it has to get done will become clearer day after day, during development. It can be considered as a to-do item, if they considered that an item is no longer necessary, it has simply to throw it away. The sprint backlog must be a real-time picture of the work being done by the team.

It is also advisable to define a Sprint goal, something that the team can remember during the sprint, and wrap up in a short phrase why are they building that increment. The goal must be set during the sprint planning by the Developers and product owner, and it is very often extracted from the list of items going to be considered for the team to be part of the sprint. It cannot arise earlier because we have to wait until the sprint backlog is completely defined, and that is going to happen by the end of the planning meeting.

Increment

This is the result or outcome of every successful sprint. It sums to the previous increments already done in previous sprints. The product owner can decide to ship this increment to the customer or not.

Note

All the increments must meet the the team´s “definitions of done” statement.

Scrum Team

When talking about Scrum Team, we must say that Scrum recognizes only three roles: Product Owner, Scrum Master and Developers.

Product owner

Product owner is the single point of accountability for the product. The way he manages the product is through the product backlog. He is also responsible of defining what item in the product backlog is going to be the next to be pulled out by the team to work it out, ensuring that item to be pulled has the higher value for the business among the other items on the list. It cannot be accomplished without strong customer participation.

Product owner must think about the team as it has a fixed capacity, this capacity will be continuously measured and be more accurate as time goes on, because each sprint performed gives us team’s speed information for this purpose. The product owner must be a single person, he can speak on behalf of a set of internal and/or external users or customers, but his voice is the only one listened by the team.

Developers

The Developers are the people who create the increment of the sprint. Ideally, every member of the team is a developer, not to say that they are all coders, they are part of the team that creates the product. Scrum does not distinguish among special skills such as UI developer, back-end developer, etc. Everybody that participates creating the product is going to be considered a “developer”, regardless of its skills.

The Developers are self-organized, they must be able to choose the work, and to define how to do it. They work with the product owner together to pull out always the most valued items in the product backlog. Throughout the sprint they choose the best way to do it. No one other than the product owner provides information about items in the backlog to the Developers.

The team is set to be cross-functional, it has (or must have) the skill set necessary to develop the product and to provide an increment by the end of the sprint.

The ideal amount of Developers is 6 ± 3 people, product owner and scrum master roles are not considered in this count. The Developers are accountable as a team unit, as a group to deliver increment. It means that accountability is shared between all developers. “That is not my problem” is a phrase that never has to be heard in a scrum team, regardless of the specialty, everyone is responsible for the committed sprint goal.

Scrum master and product owner can often be Developers too, but be careful to avoid conflict of interests.

Scrum master

Scrum master must ensure that the Developers adhere to the rules, theories, and practices of Scrum. He acts in a management position as a servant leader to remove impediments the team would be facing.

Scrum master is responsible for training, coaching, and mentoring those who need to understand Scrum better, to get the most out of it. He facilitates events, he should have facilitation skills, indeed.

Scrum master also helps those who are outside of the scrum team to know how to interact with those who are in the scrum team, in ways that help to maintain the focus on the sprint goal. Scrum master helps product owner to manage the product backlog in a better way. He also helps the Developers facilitating primarily Scrum events. He is responsible for the Developers to be able todo their job well using Scrum.

If impediments arise down the road, and these impediments cannot be removed by the Developers by themselves, it is the Scrum Master who jumps into the scene to help them get over them. It is also a responsibility of the Scrum Master to coach the entire organization in the adoption of scrum practices.

Events (meetings or ceremonies)

Being Scrum based on empirical process control model, inspection and adaptation are needed throughout all the process. If these events does not occur, we are not doing Scrum well. Let´s see which events are considered in Scrum, not before talking about timeboxing.

Timeboxing

Timeboxing is a crucial concept and habit for Scrum. It allows us to focus on important things, and to use the time efficiently, considering that events are occurring very often, and even in a daily basis for some of them. Timeboxing means that if a meeting was arranged for two hours long duration, and the time is over, the meeting must finish, even if there are more things to do. Some highlighting aspects about timeboxing are:

• Provides maximum duration. Not minimum.
• Act as a container for self-organization and collaboration
• Focuses participants on the best result possible in the allowed time frame
• Capitalizes on “The art of the possible” (best possible result achieved with defined constraints: input / expected result / time available)

Note

Sprint is a container that reminds us when we must be finishing committed tasks defined in the sprint goal. Within sprint time, a set of Scrum activities must occur:

Sprint (not as event, but as timeboxed activity)

Sprint is not a real scrum event, but is truly important when we talk about timeboxing, so it is worth to talk about and describe its importance for the framework. The limit in duration of the sprint focuses everybody on the most important things to do regarding the committed sprint goal. It allows us to limit the overall project risk, because we have a chance to inspect and adapt in short periods. If something went wrong, there will be as much as one sprint of wasted effort.

Sprint duration also encourages the team to be planning very often, which produces planning activities more realistic and manner, more tied to actual organization and environmental conditions. Also, team velocity is going to be considered on each sprint planning, thus any changes on these conditions will be reflected as time goes on in upcoming sprint, building every time a more realistic planning horizon.

When talking about Sprint we must be considering the team velocity. Team velocity is a measure of how much work a team can do in a period of time (sprint-duration). This value is recorded for each sprint and is fundamental when forecasting and planning.

An important thing to note is that by keeping sprint duration consistent over time, and by starting the sprint each time on same days, a company cadence will be set up, and velocity measurements are going to be more stable.

An important thing to note is that once a sprint is started, it's scope and team membership must be kept unchanged. This means that no new requirements must be added or removed, nor team members must come in or get out. If something important arises that must be attended, the sprint would stop and then a fresh sprint start would be needed.

Sprint planning

The objective of this event is to setup everything the team needs to work in isolation for a few a weeks (sprint duration). Sprint planning duration varies depending on several factors, but the recommended duration is two hours for each sprint’s week duration. For example, for a sprint duration of 3 weeks long, planning would require six hours duration. All the Scrum Team must attend, and perhaps some other people necessary to build up the sprint plan would be present as well.

A prioritized backlog is needed to start the planning session. The team must define which of the items in the backlog can be pulled to be part of the sprint backlog. This definition must require further analysis of each of the items, and even some break-down would be done. A clear understanding is needed on scope and effort of each sprint committed item. The team must elaborate sprint backlog out of the item committed for the sprint, and also must come up with a sprint goal definition.

By the end of the meeting the Developers should be able to explain to the Product Owner and Scrum muster how they are going to get the work done. They must be able to describe how does the plan look like for having the working software by the end of the sprint.

Daily meetings

The daily meetings are a tactical check for the team focused on the collective result needed to finish the committed work by the end of the sprint. It is a review of how the collective effort is performing, and how individual effort collaborates to achieve the overall team result. These meetings are for and by the Developers.

What people do here is create the plan for the next days of the sprint, taking into account what has happened so far in the sprint up to that time, by inspecting and adapting the sprint backlog. The team must be reasoning about the effort needed to come up with the committed working software by the end of the sprint. They should be asking themselves “are we making a good progress towards the sprint goal”? if not, then change what is needed to reach the goal. This meeting is of fifteen minutes duration, same time, same place, each day. The timebox is narrowed to keep everyone focused, avoiding to let people spend a lot of time designing or explaining some tech details that are not part of the review.

Sprint review

This is an opportunity for the team to share the work they got done with a broader audience, including stakeholders, if needed.

The timebox for this event is one hour for every week of work, so for example for sprints of three weeks duration the sprint review would take up to three hours, at maximum. Sometimes meetings of one hour duration are scheduled regardless of the sprint duration, because that way is more likely to have the stakeholders participation and other interested people with congested agenda. But be aware that one hour may be limiting the room for discussions that are truly valuable during this meeting.

A demo must be prepared by the Developers (not slides, working software) to show the work done, the increment. This is the right place for the team to ask the audience “what do you think?”, not expecting the people argue on what they have done, but with the hope of getting important feedback about what to do next. The feedback received must be added to the product backlog, to later be prioritized accordingly. This is another activity of the inspect and adapt set of activities promoted by Scrum.

Sprint retrospective

The whole Scrum team attends, no one external to the team can attend. This is an inspect and adapt opportunity for the team to reflect on what has happened on the most recent sprint, how they are doing scrum, how they are performing as a team.

The objective of this event is to let the team create a plan to improve its capacity, by observing those elements that can be considered impediments, and identifying some aspects that can be changed to perform better on next sprints.

The outcome of this meeting can be a backlog of things that must be changed, improved, or removed, and some of these things must be included in next sprint planning meetings to be worked out or overcome. Expand the definition of done is one of the things that takes places here and is the best place to think about how to improve, how to go beyond next time.

Definition of done

Even though this is not part of the framework, it is an important concept that must be written down and publicly available for every team practicing scrum.

The definition of done is a check-list that can be used to determine if an item can be considered “done” by the team, if it meets the requirements stated by the team for an item to be considered finished. We can imagine this definition as quality standard, and everyone must understand what “done” means.

Does it mean that documentation exists? Does it mean that it is deployed in production? All the team must be on the same page and agree with it.

It is considered “healthy” if scrum team expands this definition over time. As the definition of done increases, so does the quality of the product being created. Definition of done must never change in the middle of a sprint. Change requirements comes from the inspect and adapt actions, such as sprint review meetings.