Scrum is one of the implementations of Agile.
The term “scrum” comes from a rugby term that consists of teammates interlocking their arms and pushing forward into opponents.
In the technology world, Scrum is a method of project management that consists of tightly coordinated teamwork, strong organization and completing projects according to client demands. Most software development projects use Scrum nowadays. There are a set of terms and techniques that are used in Scrum but it all centers around teamwork.
Whereas Agile is a methodology, Scrum is a framework. This is only mentioned here so that you know there is technically a difference between the two terms.
A methodology is a set of rules, methods and tools that can be used to achieve a particular goal. A framework is an overview of how guidelines should be implemented. Frameworks are typically considered a “looser” and more flexible structure that allows for other tools to be included. Methodologies are considered more rigid, while frameworks allow more leeway.
Even though frameworks are usually considered to be less strict than methodologies, Scrum has evolved to a point where it has very precise procedures. There are even certifications that can be obtained.
All of the Agile terms and concepts covered in this book so far are used in Scrum, including:
● Sprints (fixed amount of times of work, such as 1 week, 2 weeks, etc.).
● Backlogs (list of work needing to be done).
● Standups (daily meetings of the development team)
In Scrum, these terms are either used as listed above or sometimes referred to with the word “Scrum” added – like Scrum Sprints or Daily Scrum Meeting. Again, they mean the same thing as in Agile because Scrum is Agile.
One way to look at Scrum’s relationship to Agile is this picture:
Now that you know what Scrum is, let’s go over some more Scrum-related words and topics.
PRODUCT OWNER
In Agile and Scrum, the Product Owner is the person who has final authority in representing the customer’s interests.
The Product Owner is available to the project’s team at any time (even though they are not involved in the actual creation of the project) and is present at most meetings. They are the “boss” of the project but they allow the members to set their own targets and manage themselves.
The Product Owner is typically the person who meets regularly with the client.
Some of their duties include:
● Clearly expressing backlog tasks
● Ensuring that the backlog is visible and clear to everyone
● Ensuring that everyone knows what the priorities are and what to work on next
As these duties show, the Product Owner is ultimately responsible for the product backlog.
The word “owner” refers to responsibility – the Product Owner owns that the product will be accurately developed.
The Product Owner views projects from the client’s perspective and works to ensure that their vision is accomplished.
There is another person involved in running the day-to-day activities of Scrum.
SCRUM MASTER
The Scrum Master is the person actually involved in the computer programming/software development, who coordinates the group activities and runs them. The Scrum Master is there, on the ground, performing work and helping their fellow teammates. The same person need not be the Scrum Master over a long period of time; some teams have each team member take on this role in turn over time.
The Scrum Master typically oversees daily standups.
Some of their duties include:
● Removing obstacles during development
● Ensuring the development environment is set up so that the project can be completed
● Training team members in Scrum and making sure it’s being accurately applied
● Maintaining a good relationship between the developers and Product Owner – as well as others outside of the team
● Protecting the development team from external interruptions and distractions
The term “master” isn’t used to denote someone who has others working for them. It’s used in the sense of “a specialist of a particular subject” in that the Scrum Master should have the best (or at least a very strong) grasp of Scrum compared to others involved in the project. They should be a master of the Scrum framework.
Okay, so we’ve covered project managers, Product Owners and Scrum Masters – what are the differences between these?
TITLES
The terms “Scrum Master”, “project manager” and “Product Owner” can occasionally be confused. They are each different things.
The Scrum Master is the development team member who coordinates the work of their fellow team members. They ensure that Scrum is understood and applied by all involved.
A Product Owner is the person who has final authority in representing the customer’s interests and they interact directly with the client.
A project manager is the individual ultimately responsible for the entirety of a project. There is technically no project manager title in Scrum – those duties are instead shared by the Product Owner and Scrum Master.
Scrum Master is a Scrum term. Product Owner is an Agile term that is also used in Scrum. And project manager is a general term used in many professions and industries.
An impediment is something that blocks or slows progress.
In a literal sense, a tree that falls over and blocks a road is an impediment.
In Scrum, an impediment is anything that prevents the team from meeting their potential. This includes issues that could prevent a project from being completed on time or on budget. It is the Scrum Master’s job to handle and remove impediments.
BURNDOWN CHART
A burndown chart shows how many hours of work are left on the project day by day during a sprint. The days are displayed left to right at the bottom of the graph and the hours are displayed bottom to top on the left side of the graph.
A “product backlog” is the same thing as a backlog: products that need to be gotten; tasks that need to be completed.
A “product backlog item” (also called PBI, backlog item or item) is a single task that is to be completed. It is simply breaking a backlog down into items. PBIs are all the small things that need to happen for production to be completed.
For example, in creating a website composed of ten web pages, each web page could be considered a PBI.
A “sprint backlog” is the task or tasks that a team hopes to complete during a particular sprint.
At the start of each sprint, a planning session occurs with the team.
During sprint planning, the sprint backlog is planned out – i.e. the team decides which product backlog items (PBIs) will be completed within the next sprint. Some teams may choose to assign specific tasks to specific developers, but this is not required - many teams decide on the sprint backlog, and let team members choose what task to work on as the sprint proceeds.
A major element of Agile and Scrum is the end users – the people who will actually be using the product when it’s done. Let’s discuss this.
USER STORIES
A user story is an Agile and Scrum tool that attempts to describe software from the user’s perspective.
They are written from the user’s viewpoint and are used to document tasks for developers to complete by describing particular features.
User stories include the type of user, what they want, and why.
They are written like: “As a (type of user), I want (some goal) so that (some reason).”
For example, “As a user, I want to log into my account using a username and password so I can access my account information.”
Agile and Scrum typically have developers work on tasks in the form of user stories.
In Agile and Scrum, epic refers to a larger body of work (big tasks) that can be broken down into user stories (smaller tasks .
Both epics and stories are examples of Product Backlog Items (PBIs).
Criteria are the standards against which something is judged – they’re the requirements.
Acceptance criteria are the details that provide a clear description of what is considered to be “done” in terms of a user story. For example:
User story: As a user of this website, I want images to expand when I hover the mouse over them so that I am impressed by the interactivity of the site.
Acceptance criteria: All images expand 25% in size when hovered over by a mouse.
A Scrum Board is a physical surface that can be used to visualize information and manage the sprint backlog. This is also referred to as the taskboard.
In Agile and Scrum, there is a backlog meeting where tasks are gone over. Let’s go over this.
STORY TIME
Story time is a meeting during a sprint when items on the backlog are discussed and clarified. Attempts are made to estimate how long each PBI (Product Backlog Item) will take to complete and tasks are prioritized.
Story time is also referred to as “backlog grooming” or “backlog refinement”.
One aspect of this that you should know about is the estimation of task difficulty. There are a number of different methods used in Agile, but the two most common are “T-shirt size” and “Fibonacci sequence”. These are methods to indicate how much work is involved in a specific task.
The “T-shirt size” practice involves assigning each task a size of tshirt that indicates its difficulty. The usual sizes are small, medium, large and extra-large.
The “Fibonacci sequence” practice involves assigning each task a number that indicates its difficulty. These numbers are taken from a popular mathematical sequence of numbers, so named because they were popularized centuries ago by an Italian mathematician named Fibonacci. It is a sequence of numbers where each number is the sum (combined total) of the previous two numbers. It looks like this: 1, 1, 2, 3, 5, 8, 13, etc.
The higher the number assigned, the more difficult the task is.
If a particular task is difficult enough that its t-shirt size or Fibonacci number is outside the ones given above, it often means the task should be examined to see if it can be further broken down into less difficult individual tasks.
Velocity is the speed at which teams complete work. Specifically, it refers to how much of the product backlog can be handled in one sprint.
Once velocity is reliably established over a period of time, it can be used to plan projects and predict completion dates.
Agile and Scrum projects are run through sprints and regular meetings. Let’s look at the meeting that takes place at the end of each sprint.
RETROSPECTIVE
Retrospect means to review or survey past events or a period of time.
A sprint retrospective is the meeting at the end of a sprint where the team determines what could be changed that might make the next sprint more productive. Sprint retrospectives gather feedback and provide info on how a project is progressing.
The meeting can be overseen by the Product Owner (person responsible for defining user stories and prioritizing the backlog), but it need not be – sometimes, this meeting involves only the members of the development team.
Here are some examples of great questions that can be asked during a sprint retrospective:
● What were our successful actions during this sprint?
● What did we learn from this sprint?
● In future sprints, what should we do the same?
● In future sprints, what could we do better?
● Are there any bugs?
● Does anyone have any questions?
● Does anyone have any confusion?
The sprint retrospective usually includes the Product Owner, Scrum Master and the entire development team.
ROLES IN SCRUM
The three main roles in Scrum are:
Product Owner.
This person is responsible for laying out the work that needs to be done and prioritizing that work. They are knowledgeable in the project expectations and act as a guide to the team carrying out the project.
Product Owners remain involved with the project throughout its entirety. This is as opposed to a boss who is only involved at the beginning, during initial planning. The Product Owner ensures that the project is adjusted and reprioritized as needed, based on feedback.
With all those duties, the Product Owner does not direct or control the development team’s activities – that is handled by the Scrum Master.
Scrum Master
There are two primary duties of a Scrum Master:
1) They protect the development team and make sure that everyone can focus on their work with minimal distractions. This includes isolating and handling impediments that come up.
2) They protect the Scrum process itself and ensure that it is correctly applied. Therefore, the Scrum Master must be knowledgeable in Agile and Scrum. An element of this is acting as a trainer and coach for all other team members.
Development team.
These are the individuals that write the code.
The development team includes architects, testers, developers, and designers.
The team acts together to figure out how to achieve their goals. The specific features they work on are based on the priority laid out by the Product Owner.
SAMPLE AGILE/SCRUM PROJECT
Let’s bring Agile and Scrum together by running through an example project.
Let’s say Mark has an idea for a new app for his high school basketball fans. Using crowd-sourced (produced by a large number of people) data, parents and friends could get up-to-date scores and standings for any high school basketball team in the country using only their smartphone.
One major problem, Mark doesn’t know how to make apps. But Mark does know about Agile.
He gets his friend Samantha, who is a trained developer, to be the Product Owner. Mark is the client. They are both stakeholders.
Samantha creates a product backlog based on Mark’s vision and breaks these up into user stories.
Samantha gets a couple of her developer friends to help with coding the app. They conduct daily standups and start each week with a sprint planning meeting. Their daily standups take 15 minutes or less and each person is asked:
● What did you accomplish yesterday?
● What will you accomplish today?
● What obstacles are you facing?
They keep each sprint to 7 days and conclude each week with a sprint retrospective. Each of the members of the dev team are assigned user stories as tasks to complete during sprints. As a note, not all dev teams operate this way - some don’t assign tasks at all; instead, they let developers choose what tasks to work on from the sprint backlog as the sprint proceeds.
These sprints force a team to develop under short iteration times to ensure that they remain constantly focused. For example, the end result of an iteration could be a new feature or a large bug fix. Either way, it’s something that can be presented to a stakeholder as an accomplishment.
Mark and Samantha meet regularly to go over how the project is coming along.
To help the team coordinate their efforts, they might use the project management application called “Trello”. Trello is a collaborative application allowing everyone, Mark, Samantha, and her entire team, to stay in sync across all of their devices and to collaborate from anywhere in the world. This allows real-time coordination affording Samantha’s team the ability to meet Mark’s product wishes better.
After a few weeks, they deliver an MVP – an app that can be launched in the App Store that will continue to have functionality and features added to it as time goes on.
Let’s say Mark finds out that users are barely utilizing the app for basketball scores and standings as originally intended. Instead, he sees that people are mostly ignoring the scores altogether and simply using the application to talk amongst each other via the built-in chat feature. This is not what Mark expected at all but since he is using the Agile methodology, he can quickly change the direction of his app.
Mark holds a meeting with Samantha, where they create a new product backlog list that focuses on enhancing the messaging system. The point is, Agile allows for major shifts and transitions in the middle of the project – it’s very fluid.
The Agile software development methodology assumes every project comes with its own special needs and requirements and may need to be adjusted accordingly to complete it. Agile anticipates that the client’s needs may change throughout the project and therefore a hardcoded (data that cannot be altered) or planned approach will not suffice; instead, the project will need to adapt quickly to address the evolving requirements.
In Agile, tasks are divided evenly into smaller pieces to deliver specific features for a release. The functional software is expounded upon (added to) in incremental iterations, each adding in new features, with the final product including all the features required by the client. The core principle of the Agile model is that it should be both flexible and adaptable.
