I don’t know how to write an introduction for this one. Without further ado, let’s talk about Scrum.

About Agile

Before talking about scrum, we need to mention agile. Agile, the word, is the ability to create and respond to change. Agile, the software development approach, pretty much lives up to its name. The authors of the Agile Manifesto chose this word because it represented the adaptiveness and response to change¹.

Manifesto

It was created by seventeen people in February 2001, called the Agile Alliance. The manifesto encaptures the values, principles, and essence of agile methodologies. Here’s the essence of the agile manifesto.

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan.

The manifesto also said that, while there is value to the items on the right, we value the items on the left more². Meaning the word in bold is more valued in agile methodologies.

Principles

The agile manifesto defined 12 principles that consist of:

1. Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity — the art of maximizing the amount of work not done — is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

In other words, agile software development is all about collaboration and communication between the developer team and the client to create a product that really caters to the client’s needs.

About Scrum

Scrum is a framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems³. According to the scrum guide, the scrum framework is actually incomplete. It’s built upon by the people using it.

As a framework, scrum doesn’t really provide detailed instructions on how to do the software development process. Instead, it provides guidelines on relationships and interactions between the characters (we’ll get to know who they are in a minute).

It is built on empiricism and lean thinking. Empiricism means that we base our decisions on what is observed. This reflects on one of Scrum’s plot points (again, we’ll get back to this in a minute), the sprint retrospective, to look back and see what worked and what didn’t and plan for the next sprint accordingly. On the other hand, lean thinking means we reduce waste and focus on the essentials.

✅ Values

These values need to be kept in mind when going for success using scrum.

• Commitment – scrum team commits to achieving its goals and to supporting each other.
• Focus – everyone’s primary focus is to make the best possible progress towards the goals.
• Openness – scrum team and its stakeholders are open about the work and challenges.
• Respect – team members respect each other to be capable and independent.
• Courage – scrum team members dare to do the right thing and to work on tough problems.

👨‍💼 Character Introduction

There are several characters involved within a scrum framework. Other guides call them the scrum team—the fundamental unit of Scrum. But, I’ll call them characters because my brain works that way.

Every character has the skills necessary to deliver value in each sprint. Everyone works as a unit and focuses on one objective at a time, the product goal. This unit is also self-managing, they decide who does what, when, and how by themselves.

Here are the characters in a scrum team.

• Developers – they’re the worker bees of the unit. Developers are those committed to making increments of a working product by the end of each sprint.
• Product Owner – they’re the one (singular) responsible for creating and managing product backlog items and making sure everyone in the team understands what needs to be done. A product owner is one person, not a committee.
• Scrum Master – they’re responsible for establishing scrum and keeping everyone stay effective.

🤝 Plot Points (Scrum Artifacts)

Scrum artifacts are pieces of information that the scrum team and other stakeholders use to detail the products being developed, the actions to produce them, and the actions performed during the project⁴.

For the sake of continuing the analogy, I’ll call them plot points. Plot points are basically points within the storyline that eventually need to happen and be written. A group of plot points can make up an outline of where your story is going. Scrum artifacts work more or less the same way. They provide points that give insight into the performance of a sprint.

Product Backlog

This is a list of new features, bug fixes, enhancements, tasks, or requirements needed to build a product. A product backlog is a live artifact that’s updated on-demand as new info is available.

Sprint Backlog

Put simply, the sprint backlogs are product backlogs that have been promoted. They're selected product backlogs that will be developed during the next product increment.

Sprint backlog acts as a deliverable for the development team. They are updated during the spring planning phase of Scrum. If the scrum team couldn’t finish every sprint backlog during a sprint, they will be migrated to future sprints.

Product Increment

A product increment is a deliverable that’s produced by completing a series of product backlogs. There’s always one increment for each sprint and this is decided during the scrum planning phase.

Extended Artifacts

There are additional artifacts that the scrum team can use to further enhance the scrum process. They provide additional values and insight into a scrum cycle.

• Burndown Chart – it’s used to communicate and track progress toward the sprint goal during the sprint.
• DoD (Definition of Done) – this helps define the boundaries of an increment, as well as when tasks are completed and can be closed out for burndown tracking.

Our Process

Now on to the good parts. Here’s how my team El Pepe applies scrum for our project’s development. Here’s a glimpse of how we do our scrum ceremonies~

Sprint Planning

Attendees: Development team, scrum master, product owner When: At the beginning of a sprint

Sprint planning is simply what its name entails. It’s when we plan for the sprint by assigning points to each backlog and backlogs to each dev team member. This ceremony involves a lot of discussions about the sprint backlog to estimate the effort involved.

For our sprint planning, we utilized the GitLab issues board for the sprint backlog tracking, and scrum poker for estimating the effort for each backlog item.

Daily Stand-up

Attendees: Development team, scrum master, product owner When: Once a day, but in our case, twice a week

This ceremony takes place for no longer than 15 minutes. The entire point of this ceremony is to keep it short, that’s why you’re not even required to sit down to hold the meeting. The daily stand-up serves to inform everyone of what’s going on across the team. Each member will report on these things:

• What I did
• What I’m going to do today
• What’s blocking me

After everyone takes their turn, the meeting is dismissed so everyone can go back to work. Nice~

Sprint Review

Attendees: Development team, scrum master, product owner, and project stakeholders (optional) When: At the end of a sprint

This is the time to showcase the work of the team. We created a User Acceptance Test (UAT) document beforehand to help us walk through the latest deliverable and conducted the demo using the UAT as a guide.

This helps us make sure the product we’re delivering works properly and satisfies the Definition of Done defined beforehand.

The demo serves the team to get feedback from the product owner and project stakeholders. The team will take notes on this feedback and act upon it in the following sprint.

Sprint Retrospective

Attendees: Development team, scrum master, product owner When: At the end of a sprint

My team usually holds this ceremony right after the sprint review so we don’t have to schedule a different meeting time. In the sprint retrospective, we find out what’s working and what’s not, and use this time to find solutions and develop an action plan. At least that’s what the scrum guide says.

We use the tool metroretro for this occasion. We use the template that has four boards and sticky notes where each member can convey what they feel was good or bad from the sprint and what the team needs to start or stop doing on the following sprint.

The Good, The Bad, and The Confetti 🎉

Each member’s sticky notes are initially hidden from the others. After several minutes, we take turns talking about what we wrote down. While listening to everyone, my fellow team members usually play around with the confetti.

Heartfelt Thank You’s

We also show our gratitude to our members for helping and finishing their tasks beautifully. We tend to use excessive words to convey our overflowing gratitude, and everyone gets a thank you! Yay~

Reflection

After saying thank yous and playing around with the confetti, our scrum master will then look back to the ending sprint and see how we did. During our three sprints together so far, I’ve never been a scrum master, so these are the data that my teammates Hocky and Joni gathered.

Team Velocity

Team velocity says how much work our team can accomplish during a given time, or how much availability our team has. This can help us predict the volume of work our team can perform for future sprints.

So far, we’ve completed two sprints. In each sprint, we’ve managed to clear 43 story points with 100% completion.

According to this, our current team velocity is 43. This may be a coincidence at first, but it serves as a good rule of thumb for preparing for the next sprints that we can complete around 43 story points worth of backlog items.

Sprint Burn Down

A sprint burn-down chart tracks the completion of work throughout a sprint. It does so by comparing the time and effort to complete, in our case measured by story points.

Unfortunately, the tool we’re using (GitLab issue board) doesn’t really provide us with a clean-looking burn-down chart view. We clear our PBI by submitting a merge request, and when it’s merged, the issue would be closed and the backlog item completed. Since I don’t have an actual burn-down chart of El Pepe to show you, here’s a generic illustration of it instead.

If the red line doesn’t meet the grey line by the end of the sprint, it means that there are backlog items leftover that needs to be migrated to the following sprint. If the red line is way higher than the grey line by the end of the sprint, it means that your team is a deadliner. Or, in a more affectionate term, a late starter 😏.

TL;DR

• Scrum is a framework that applies agile methodologies. It is not the same as agile.
• In the scrum framework, there are three major characters involved: the development team, the product owner, and the scrum master.
• The scrum process involves recurring ceremonies such as sprint planning, daily stand-up, sprint review, and sprint retrospective.
• Throughout the scrum iteration, the team will make progress towards the sprint goal by completing sprint backlogs and delivering (an iteration of) a working product.
• The team (with feedback from external stakeholders) will then evaluate itself, self-manage, and repeat the iterations until they have a product that meets their definition of done.

---

In all honesty, I am not proficient in the scrum language. This article took so long for me to write cuz I had to read a bunch of references and gather source materials. There were a lot of technical terms, and I’ll just cross my fingers that I didn’t make any mistakes on them 🤞.

Thank you for your time. See you on the next one~

Footnotes

1. https://www.agilealliance.org/agile101/ ↩

2. https://agilemanifesto.org/ ↩

3. https://scrumguides.org/scrum-guide.html ↩

4. https://www.atlassian.com/agile/scrum ↩