Scrum: An Overview & How It’s Used In Practice

10 min readMay 1, 2021

Scrum is all about being adaptive and deliver value for each iteration.

When you are involved in the tech industry or software development stuffs where the pace is quick & very dynamic, “change” is just an everyday thing. This kind of thing also is known as a common enemy especially for the development team. Agile methodologies serve as the answer for this issue on the development flow which is scrum is one of those methodologies. There’s a common misconception where scrum=agile. Now let’s talk about scrum & agile to fix that kind of misconception.

What Is Agile?

Taken from Merriam-webster, agile can be defined as

“Marked by ready ability to move with quick easy grace”-Merriam Webster

So basically being agile means being quickly adaptive & resilient in every situation. Aligned with that definition, this term is coined by 17 people in 2001 as a new software development paradigm. Those people also declared an infamous manifesto called Agile Manifesto. This manifesto embodies the spirit of agile methodologies in software development. Here are those four points with the explanation:

Individuals and interactions over processes and tools

Interaction and communication are highly encouraged in agile. By utilizing these two, we ensure that we know what’s the customer really needs so, therefore, we can be more adaptive to changes.

Working software over comprehensive documentation

Creating documentation is really takes a lotta time. Therefore in the agile paradigm, the focus is shifted to finish working software. Yet, documentation is still important especially for future developers but the portion is reduced to save time for delivering the product. Therefore, it’s better to deliver not only working software but also intuitive so we don’t delve down too much into documentation creation. The key takeaway is to focus on delivering a working & intuitive product and create documentation only if it’s really necessary.

Customer collaboration over contract negotiation

This means involving the customer/client not just on the specification definition, but also in the development process. That means the client can be involved in meeting with the development team to discuss what’s good & bad about the delivered product. The client can also do brainstorm with the development team how the product is gonna be in the future.

Responding to change over following a plan

In traditional software methodologies, “change” is taboo in the software development process once the requirement is set. While in agile, “change” is something that we must deal with it.

That manifesto laid out 12 agile principles that consist of:

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

The key points from those 12 principles are:

Collaboration
Self-Management & Highly-Motivating Team
Communication
Focus on good quality product/software
Effectiveness & Efficiency
People as Focus

So in short, agile in the software development context is all about delivering a product that’s really centered on collaboration between the client & the development team to make sure that the product is something that client really needs. Being adaptable & communicative is crucial to keep that collaboration going well.

Scrum As An Agile Methodology

source: https://d112uwirao0vo9.cloudfront.net/wp-content/uploads/2019/09/Scrum-Method-1024x751.jpg

Scrum is one methodology or framework that utilizes agile principles. So it’s really not the same as agile. The goal that this framework wants to reach is to deliver value(s) within a short time span. The value defined here is defined as the solution to a problem. So the main goal for each iteration is “does this product solve the problem(s)?” instead of creating the product itself. This framework is really well-suited for requirements that may not well defined enough and the project isn’t mature enough where delivering values are more likely to happen than doing maintenance stuff. We use Scrum as a software development methodology in the software engineering project course. I think we use Scrum as a methodology for those two reasons. Another reason to consider is the client is proactively involved in the project.

Scrum Values

Commitment: Scrum team must commit to achieving the goal for each iteration
Focus: Scrum team just focusing on doing the jobs of the sprint to achieve the goal
Openness/Transparency: Scrum team & stakeholder must be open to the progress and problems that happened along the way
Respect: Scrum team must respect each other
Courage: Scrum team must have the willingness to do a tough job

Scrum Roles

A scrum team consists of 3 roles:

Product Owner: Managing & organizing the product backlog items. Communicating with stakeholders to ensure that the product backlog is aligned with what the stakeholder really wants & feasible to be implemented.
Scrum master: Ensure that the scrum team follows the scrum principles and making sure that the team keeps productive doing sprint tasks within the time span.
Development: Self-managing/Autonomous group of developers that focus on creating the product.

Scrum Artifacts

Artifacts consist of something that provides key information for the scrum process. These artifacts consist of:

Product backlog: List of features that must be implemented in the future
Sprint backlog: List of features that must be done on certain iteration
Increment: Concrete stepping stone/milestone toward the goal.

To make things clear, the above image is an example of the product backlog and sprint backlog. All those PBIs are called product backlogs (PBI 1–28). While PBI for each sprint is called sprint backlog(PBI1–5, PBI22–28, and so on).

Scrum Flow & Its Implementation in PPL

Sprint

In scrum methodology, one sprint can be defined as iteration/cycle. This iteration is started with sprint planning and the followed by a development phase. During this development phase, there is daily that conducted regularly. Once the development phase is finished, the next step is doing the sprint review. After the sprint review is done, the iteration is ended with a sprint retrospective before proceeds to the next sprint. In PPL, one sprint takes about 2 weeks. Meanwhile, in reality, the sprint duration can be varied depends on the feasibility of the goal but that it doesn’t take longer than a month because we want to add a new feature as quickly as possible.

2. Sprint Planning

In this step, the scrum team conducts a meeting to discuss the tasks for the sprint. In PPL, the scrum master arranges the day when we want to conduct this meeting on Google Meet. Our team itself does sprint planning every Monday on evening or night. The flow of this planning consists of these steps

Scrum master explains the sprint backlog
The scrum master asks the development team which backlogs wanna be taken from those sprint backlogs.
Once the development team has chosen the backlogs for the sprint, the scrum master asks the development team to vote the story point for each chosen backlog. In this session, the development team usually discusses the feasibility of the backlog to estimate the story point. We use scrum poker as a platform for this kind of stuff. If one or more members of the development team choose story points that really far different from others, those members must explain the reason why do they vote for that point. The scrum master then tries to assign a story point that kind of middle point/median between those voted points.
After the story points have been assigned to all chosen backlogs, the final step is the scrum master asks the development what tasks need to be done to fulfill all of the chosen backlogs. The tasks of the sprint are listed using GitLab issues.
After the scrum master has broken down the tasks, the next step is for each member of the development team to choose several tasks from all of the sprint tasks. The scrum master task is to assign the task who’s in charge of the task in GitLab issues.
Sprint planning finished

3. Daily Sprint/Standup

To monitor the progress, the scrum master conducts daily standup regularly. In practice, the daily standup is a meeting that conducts daily and usually doesn’t really take long. But because we are students and we have our routines/schedule in a week, the daily meeting is conducted twice a week. The daily standup is conducted every Tuesday evening & Thursday evening in our group. In this standup, each member tells the progress that has been done, some obstacles/blockers, and what he/she’s gonna do next.

4. Sprint Review

The moment of truth in the sprint. Here we present our deliverable of the sprint in front of stakeholders. The stakeholder gives feedback on what is good, what can be improved, etc. The stakeholder & product owner also conduct user acceptance tests to whether the minimum viable product can be considered as done or not. Because the condition is on the pandemic, we conduct this sprint review by using google meet instead of doing it onsite.

5. Sprint Retrospective

In the last step of the sprint, the scrum master conducted a session to reflect or review how the sprint really went using google meet. In this session, development writes down what went well, what didn’t go well, what’s needed to start doing, what’s needs to be stopped in a retrospective board. The goal of this session to know something that needs to improve for the next sprint.

When Not to Use Scrum

Scrum is a great software methodology. However, several situations make you consider not to use this methodology.

Stakeholder/Client Doesn’t Want Proactively Involve in Your Project

We know that scrum implements the agile principle. Therefore, a collaboration between the developers and the client is an integral part of it. Imagine your client is being laid off but you need him/her for continuous feedback on sprint review. This will make the scrum process becoming pointless.

Scrum Team Doesn’t Embrace The Change

Scrum is one of the agile methodologies. And that means we must always embrace change. If we don’t ready to embrace it, better yet to change your methodology to non-agile methodology.

Scrum Team That’s Reactive Instead of Proactive

The scrum team should be consists of highly motivated & proactive individuals. If a scrum team mostly consists of passive individuals & slacking-off individuals, better yet not to use scrum because you’ll often not finishing your sprint goal just in time.

Agile In Practice

I talked about several agile principles since it’s gonna take too long to give example for all of the principles.

Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software & deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.

In PPL we have five sprints where each sprint spans about 2 weeks on average. At the end of the sprint, we as a team need to report the deliverable of the sprint. By doing that, we inform the client early and continuously so the client doesn’t need to wait until the project is finished for checking the progress.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

In PPL, there is often happened requirement changing even in the midst of the development phase. There are even some improvement suggestions of the completed features from the client even the sprint has already ended. That just shows how flexible an agile really is.

left(before revision): right(after revision)

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

I think the point cant be taken too literally since right now is a pandemic situation. To get rid of this problem, we sometimes conduct conversations via google meet especially when someone needs help on coding or asking for help. By doing this, we ensure that no one can’t face the burden by him/herself. After all, collaboration is one of the key points of agile right?

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

At the end of the sprint, we conducted the retrospective session. In this section, we discuss what are the goods & the bad that occurred in a sprint. We also discuss what can be improved & what can be stopped in order to become a better team for the next sprint.

Closing Notes

Scrum is a great framework to gain agility on software development flow and focusing on delivering value for each iteration. Agile itself is a great paradigm for software development where change is something that must be encountered often and the client wants to involve in the development process. However, this stuff ain’t a silver bullet. Knowing the characteristics of the client, product, and development team are important before deciding which software methodology & paradigm should be used.