Most Applicable Software Development

Methodologies

Definition & Quick Practicing Guide

Diponegoro University
Contents
Introduction ............................................................................................................................................ 2
1. Software Development Methodologies ........................................................................................ 3
1.1 Types of Software Development Methodologies ....................................................................... 4
1.1.1 Waterfall Model .................................................................................................................... 5
1.1.2 V-model ................................................................................................................................. 6
1.1.3 The Scrum Methodology ....................................................................................................... 7
1.1.4 Extreme Programming (XP) .................................................................................................. 9
2. The Scrum Guide .......................................................................................................................... 10
2.1 Scrum Values ............................................................................................................................. 11
2.2 Scrum Process ............................................................................................................................ 12
2.3 Scrum Events ............................................................................................................................. 13
2.4 Scrum Artifacts .......................................................................................................................... 13
2.4.1 Product Backlog .................................................................................................................. 13
2.4.2 Sprint Backlog ..................................................................................................................... 14
2.4.3 Product Increment.............................................................................................................. 15
2.5 The Scrum Team ......................................................................................................................... 16
2.4.1 Product Owner .................................................................................................................... 16
2.4.2 Scrum Master ...................................................................................................................... 17
2.4.3 Development Team ............................................................................................................. 18
2.6 Scrum Meetings .......................................................................................................................... 18
2.6.1 Sprint Planning Meeting ..................................................................................................... 18
2.6.2 Daily Scrum Meeting ........................................................................................................... 22
2.6.3 Sprint Review Meeting ........................................................................................................ 23
2.6.4 Sprint Retrospective ............................................................................................................ 24
2.6.5 Backlog Refinement Meeting.............................................................................................. 26
References ............................................................................................................................................ 28

1
Introduction

The goal of most software development companies and their clients is software production at the
lowest cost, with the best quality, in the shortest time. Proper planning and management of the
development process with the right methodology are important to achieve such a goal.

Without structured guidance, developers can suffer from customers’ ever-changing requests, and
even more so when there are miscommunications. This leads to frequent revision in the software
without considering the overall implications of the project.

The result? Wastage in time, money, and effort with the risk of producing a subpar application that
doesn’t bring much to the table.

Software development methodologies are developed to benefit both the development team and
customers. Choosing the right one ensures that discussions are conducted on proper channels, and
decisions are made after evaluating all factors.

Using a software development methodology allows the team to cut down on inefficiency and provide
a more accurate delivery timeline. It prevents the team from reacting to every input, but instead,
allows them to be more organized and structured when dealing with spontaneous changes.

2
1. Software Development Methodologies
A software development methodology is a way of managing a software development project. It will
address issues like selecting features for inclusion in the current version when the software will be
released, who works on what, and what testing is done.

A software development methodology can also be called a map of how an organization creates
software. It generally takes the form of defined phases, created to describe a piece of software's
“how” and the life cycle.

In short, a software development methodology is a series of steps needed to produce a certain piece
of software. Typically, it includes research, planning, design, and development phases that all
constitute the life cycle of the software we are working on.

Figure 1-1: Life Cycle of Software Development Methodology

Many software development methodologies propose different ways to achieve the desired result at
a fair cost and short delivery time. These methodologies set up the framework that structures
planning, controlling, and developing information systems.

No one methodology is best for all situations. Even the much-maligned waterfall method is
appropriate for some organizations. In practice, every organization implements their software
development project management in a different way, which is often slightly different from one project
to the next.

What drives the choice of a software development methodology? This choice is always relative to the
requirements of a project. In addition to this, project type and size, the skills of team members,
financial resources and preferences are also valuable considerations.

3
1.1 Types of Software Development Methodologies
Many types of software development methodologies are used in the project management field. Every
software development methodology framework acts as a basis for applying specific approaches to
develop and maintain software.

There are lots of different software development processes or methods in use today,e.g:

• Waterfall model

• V-model

• Scrum

• eXtreme Programming (XP)

• TDD (Test Driven Development)

• Kanban

• etc.

These processes or models may be divided into 2 main categories: Plan-driven models and Agile
methods. The Waterfall model, V-model and Spiral model are so-called plan-driven models, while
Scrum and eXtreme Programming are so-called Agile methods.

Traditionally plan-driven methods were used in software development, while today Agile methods
such as Scrum have become very popular, especially in smaller development teams. Plan-driven
models (e.g., Waterfall) generally produce more documentation than Agile models.

(Halvorsen, 2020, p.54)

In Figure 1-2 we see an overview of some of the most used methods.

Figure 1-2: Types of Software Development Methods

In Figure 1-3 we see the main difference between Agile development and ordinary plan-driven
development.

4
 Figure 1-3: Plan-driven vs. Agile Development

1.1.1 Waterfall Model

The Waterfall model is a sequential development approach, in which development is seen as
flowing steadily downwards (like a waterfall) through the phases of requirements analysis,
software design, implementation, testing (or validation), deployment (or installation) and
maintenance.

With its introduction in 1970 by Dr. Winston W. Royce, the waterfall is the most traditional
methodology in the IT industry. It is a classic approach and a very popular version of the system
development life cycle in software engineering. The goals are pre-defined for each development
phase.

Traditionally with the Waterfall model, we can only start on the next phase when the previous
phase is finished. Therefore, it is called the Waterfall method, see Figure 1-4.

Figure 1-4: Waterfall model

The waterfall development methodology is easily understood, which makes it popular for
teams with lesser design experience. Each stage must be completed before moving on to the

5
 next. For example, all the requirements must be established before design can commence. Just
like how a waterfall flows in one direction, there’s no going back in this approach. This makes
waterfall a non-flexible method and to be avoided for projects with rapidly-changing
requirements. Each phase must be 100% complete before the next phase can start.

The advantage of this is that the project is well planned, minimizing mid-project costs for
changing requirements and that these projects tend to be well documented. On the other side,
the disadvantage is that it is very hard to adjust the feature set in the middle of development,
which often happens as problems are uncovered in development or changing business
environments change what is needed in the software.

Suitable For

Use waterfall only when you have a project with clearly-defined scope. It is not suitable for
development that involves many unknowns. The waterfall is ideal for projects with predictable
outcomes and when you have a team of inexperienced developers.

1.1.2 V-model
The V-model is derived from the more traditional Waterfall model. It is an extension of the
waterfall model wherein software development and testing are executed in a sequential way.
The V-model is a software development process that describes the relationship between each
phase of the development life cycle and its corresponding testing phase.

Figure 1-5: V-model

• The left side of the model is Software Development Life Cycle – SDLC
• The right side of the model is Software Test Life Cycle – STLC
• The entire figure looks like a V, hence the name V – model

As we see in Figure 1-5, the left side is about requirements and design, while the right side of
the model is about testing and validating. V-Model is a highly disciplined SDLC model which
has a testing phase parallel to each development phase. It is known as the Validation or
Verification Model.

6
 Suitable For

We prefer to use a V-model in situations wherein the requirements and understanding of the
software’s functionality are well-defined from the beginning. In cases where the project scope
is clear, and the development team has a solid understanding of the requirements, the V-
model can be an effective tool for delivering high-quality software.

1.1.3 The Scrum Methodology

Scrum is the most famous framework that is based on Agile methodology. The method is
more flexible and more informal than plan-driven methods. It is empirical in nature and can be
applied to any fast-changing or priority-emerging requirements.

Figure 1-6: Scrum Overview

In short, Scrum is a Framework for Software Development as follows:

• Agile Software Development method

• Simple to understand
• Flexible
• Extremely difficult to master!
• Self-organizing Teams (3-9 persons)
• Scrum Team:
o Product Owner
o Scrum Master
o Development Team

In Scrum, the features are added in short sprints (usually 7-30 days), and short frequent
meetings keep people focused. Tasks are usually tracked on a scrum board. The group is self-
organizing and collaboratively managed, although there is a scrum master tasked with enforcing
the rules and buffering the team from outside distractions.

7
 Figure 1-7: Sprints flow

As we can see in Figure 1-7, the scrum method has iterations named sprints. It kicks off with
brief planning for each sprint, followed by daily scrum meetings that highlight the progress, and
ends with a final review.

Scrum methodology is ideal for managing projects with not well-defined requirements and
feedback from the client. Teamwork, transparency, and regular status updates to speed up the
development. Figure 1-8 shows us the illustration of the Scrum Framework.

Figure 1-8: Scrum Framework

With Scrum Framework, we can receive and incorporate customer feedback at the end of every
small development cycle, which means our results get shaped by real-world use, not our
assumptions. This makes it much easier to keep customers and key stakeholders closely
involved and engaged.

Some important Scrum Events are:

✓ The Sprint (duration between 14-30 days)

✓ Sprint Planning Meeting ( 8 hours if 30 days sprint)
✓ Daily Scrum Meeting (Max 15 min, every day at the same time) (also called a Standup
Meeting)
✓ Sprint Review ( 4 hours if 30 days sprint)
✓ Retrospective (3 hours if 30 days’sprint)

8
 The Scrum method is intended to break the long waterfall process delivery into smaller cycles,
which enables product teams and the end customer to frequently review working software and
ensure that it meets their business requirements. This ensures that the end product also meets
the final requirements of the customer.

Suitable For

The Scrum methodology is ideal for projects with fast-changing requirements. It works best to
implement the additional ideas as we learn more about the market needs. If our ally is unclear
about its software need and the project is being crafted using different technologies, we must
use this software development method.

1.1.4 Extreme Programming (XP)

It is a frequent-release development methodology in which developers work in pairs for
continuous code review. This gives very robust, high-quality software, at the expense of twice
the development cost. There is a strong emphasis on test-driven development. Typical features
in XP are as follows:

• Pair Programming
• Code Reviews
• Refactoring
• Unit Testing - In XP you start by writing Unit Tests before you start coding
• Standup Meetings

In Figure 1-9 we can see how XP works in practice.

Figure 1-9: eXtreme Programming

In XP, they practice so-called “Pair Programming”, which means 2 developers working
together.

9
 There are benefits with XP:

• Collective Ownership for the code created and the results of the project.
• Continuous informal Review process because each code line is looked at by at least 2
people
• It supports Refactoring, which is a continuous process of software improvement
• Less time is spent on repairing bugs.
• Improved Code Quality
• It reduces the overall risk

2. The Scrum Guide

Scrum is a framework that can be used to manage the complex product. The Scrum Guide
explains the definition of the Scrum framework, the Scrum Team and their associate’s roles, Scrum
events and the artifatcs. Scrum is based on the empirical process. Empiricism means working in a fact-
based, experience-based, and evidence-based manner. Therefore the progress of the scrum team is
based on observations of reality, not fictitious plans.

Scrum is an iterative way of developing software in a Sprint (a time-box of one month or less),
incrementally delivering working software every Sprint, incorporating customer feedback on the
working software, and ensuring that the right business value is delivered in each Sprint. (Doshi, 2016)

There are three pillars in Scrum Implementation: transparency, inspection, and adaptation.

Figure 2-1: Three pillars of Scrum

▪ Transparency: All aspects of the process must be visible to those who are responsible for
the outcome. All people involved—the scum team, the customer, the CEO, and individual
contributors—are transparent in their day-to-day dealings with others. They all trust each
other, and no one has any hidden agenda.
▪ Inspection: The inspection is needed to keep the progress toward a Sprint Goal. However,
the inspection should not be so frequent because it can distract the development activity.
Inspection in this context is not an inspection by an inspector or an auditor but an inspection
by every- one on the Scrum Team. The inspection can be done for the product, processes,
people aspects, practices, and continuous improvements.

10
 ▪ Adaptation: The adaptation should be performed when a process is deviate outside the
acceptable limit or the customer request to change the requirement. If the customer
changes the requirements during inspection, the team are not allowed to complain but
rather adapts by using this as an opportunity to collaborate with the customer to clarify the
requirements.

Source: The Scrum Guide 2020.

2.1 Scrum Values

The Scrum values are courage, focus, commitment, respect, and openness. Successful use of
Scrum depends on people becoming more proficient in adapting their behaviour to these five Scrum
values. In Scrum methodology, these values serve as a guide for individual and team behaviour,
intending to boost collaboration and increase the odds of project success.

Figure 2-2: Scrum Values

▪ Courage
The Scrum Team members should have the courage to do the right thing and collaborate on
difficult problems. They show courage in being transparent and sharing risks and benefits as
they are. For example, if we as the scrum team encounter things that we don’t understand or
identify a problem, we won’t be afraid to ask tough questions. Our ability to speak honestly
and question the status quo may be the key to driving improvement during a particular sprint.
▪ Focus
Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The time-boxes
of Scrum allow a Scrum Team to focus on delivering valuable working software at a sustainable
pace. To help team members focus, Scrum masters should talk openly about individual
workloads to ensure they only assign an achievable number of tasks. Take on too many
objectives, and everyone will feel overwhelmed.
▪ Commitment
People personally commit to achieving the goals of the Scrum Team. The Scrum Team commits
to building working software, to quality, to collaborating, to learning, to self-organizing, to
building the right thing for its customers.

11
 ▪ Respect
Respect means that teammates should appreciate each other for their strengths in terms of
hard and soft skills. It also means respecting others’ decisions and opinions even if we disagree
with them.
The Scrum Guide emphasizes the need to trust others on our team once roles are assigned.
We shouldn’t micromanage what everyone else is doing or constantly undermine someone
else’s skills by trying to take over their role. Scrum Team members should respect each other
to be capable and independent people. They show respect for people. They respect diversity.
They respect the Scrum roles, rules, and principles.
▪ Openness
The Scrum Team and its stakeholders agree to be open about all the work and the challenges
with performing the work. They are open to collaborating within the team and with the
organization. Openness means being open-minded in terms of communication between
members of different disciplines. Being open as an individual also means being honest about
what you can achieve and how your work will affect other team members.

2.2 Scrum Process

At the beginning of the sprint, the Product Owner (PO) will create an ordered list of product
backlogs which prioritizes the features desired Customer. Then the PO discuss with the Developer
Team to select the item from the Product Backlog to be carried out in the sprint. Those sets of Product
Backlog items selected for the Sprint are named Sprint Backlog. In other words, the sprint backlog is
a list of everything that the team commits to achieve in a given sprint. Once created, no one can add
to the sprint backlog except the development team.

The development team, which is formed with from 3 to 9 people, must detail all technical needs based
on the Sprint Backlog to deliver the product, the service or the functionality. They will be guided
directly by the Scrum Master, but they will not be directly managed. They must be self-organized,
versatile, and responsible enough to complete all required tasks.

The development team is responsible for delivering potential product increments every sprint from
analysis, design, development, testing, and technical writing, etc.

The Scrum Master will be the leader of the Scrum Team to perform the Scrum events from Planning
Meetings, Standup meetings (Daily Scum), Reviews, and Retrospectives.

The Daily meetings were held in the same place, same time and the duration is about 10 – 15 minutes.
Each team member would share their current progress. Basically, during the daily meeting, the
Development Team members answer the three questions below:

1. What did I do yesterday that helped the Development Team meet the Sprint Goal?
2. What will I do today to help the Development Team meet the Sprint Goal?
3. Do I see any impediment that prevents me from meeting the Sprint Goal?

12
2.3 Scrum Events
Events are used in Scrum to create regularity and to minimize the need for meetings not defined
in Scrum. Optimally, all events are held at the same time and place to reduce complexity. There
are five official events in the Scrum Method:

1) Sprint ( Duration between 14-30 days)

2) Sprint Planning(8 hours if 30 days’ sprint)
3) Daily Scrum(Max 15 min, every day at the same time)
4) Sprint Review (4 hours if 30 days’ sprint)
5) Sprint Retrospective (3 hours if 30 days’ sprint)

A Sprint in Scum is a fixed-length event of 1 month or less where work is performed to achieve
the Sprint Goal. This Sprint Goal is a concrete step toward the Product Goal.

So, Sprint is a defined period of time in which the Scrum Team performs work required to fulfil
the Sprint Goal.

The duration of the Sprint is defined according to the teams’ process and needs, but should not
exceed 4 weeks. This is the maximum recommended time for the Sprint duration and while there
are exceptions to this rule, most teams do best when staying within this limit.

2.4 Scrum Artifacts

Scrum’s artifacts represent work or value in various ways that are useful in providing
transparency and opportunities for inspection and adaptation. A scrum artifact is a collection of
information used by a scrum team to define the product or service being developed, the stages
necessary to generate it, and the actions required during its development.

Scrum artifact provides information on the performance of a sprint. Scrum artifacts are essential
for scrum teams because they enable core scrum qualities such as transparency, inspection, and
adaptability. This is important, especially for remote teams who may work from home because it
gives a platform for them to monitor how they’re performing on a certain sprint. Scrum artifacts
keep everyone on the team on track as they work toward the sprint goal.

There are many more artifacts, for example, User stories, Release backlog, Burn-down & Burn-up
charts etc. But there are three cores of Scrum’s artifacts:

• Product Backlog
• Sprint Backlog
• Increment

Now, let me explain the scrum artifacts one by one in detail:

2.4.1 Product Backlog

The product backlog is a collection of user stories which present functionality which is
required/wanted by the product team. Usually, the product owner takes responsibility for
this list.

The Product Backlog is an ordered list of what is needed to improve the product. It is the single
source of work undertaken by the Scrum Team. It is an ordered list of everything that will go

13
into the product. It includes features and changes, bugs, and knowledge that the team
members and stakeholders have about the product.

Product Backlog items that can be done by the Scrum Team within one Sprint are considered
ready for selection in a Sprint Planning event. They usually acquire this degree of transparency
after refining activities. Product Backlog refinement is the act of breaking down and further
defining Product Backlog items into smaller more precise items. This is an ongoing activity to
add details, such as a description, order, and size.

The Developers who will be doing the work are responsible for the sizing. The Product Owner
may influence the Developers by helping them understand and select trade-offs.

2.4.2 Sprint Backlog

Sprint backlogs contain a collection of stories which could be included in the current sprint.
Two important points to note about the relationship between the sprint backlog and the
inclusion of items into the sprint.

• The team decides what gets added to the sprint. The team, therefore, takes ownership
and responsibility for the delivery of those items.
• Before an item can be removed from the sprint backlog and added to the sprint, the team
must ensure they have all the information needed within the backlog. Usually, a team defines
a checklist of items which must be present before the item can be added.

Scrum teams use the Product Backlog to create the Sprint Backlog. The Sprint Backlog is a list
of all the work the team members will do during the current sprint. It’s created from a
selection of items from the Product Backlog. The team members decide which work items go
into the Sprint Backlog. A Scrum team creates their Sprint Backlog at the start of each sprint.
They use the Product Backlog as a source of material.

Product Backlog vs Sprint Backlog

The sprint backlog is a list of tasks identified by the Scrum Team to be completed during
the Scrum sprint. During the sprint planning meeting, the team selects some number of
product backlog items, usually in the form of user stories, and identifies the tasks necessary
to complete each user story as shown in Figure 2-4 below:

Figure 2-3: Product Backlog vs Sprint Backlog

14
2.4.3 Product Increment
The Product Increment is the sum of all the Product Backlog items completed during a Sprint
and the value of the increments of all previous Sprints. At the end of a Sprint, the new
Increment must be “Done,” which means it must be in useable condition and meet the Scrum
Team’s definition of “Done.” It must be in useable condition regardless of whether the
Product Owner decides to release it.

Burn-down chart

A burn-down chart is a graphical representation of work left to do versus time. The

outstanding work (or backlog) is often on the vertical axis, with time along the horizontal.
That is, it is a run chart of outstanding work. It is useful for predicting when all of the work
will be completed. It is often used in agile software development methodologies such as
Scrum. However, burn-down charts can be applied to any project containing measurable
progress over time. Outstanding work can be represented in terms of either time or story
points.

Figure 2-4: Example Burndown Chart

Definition of “Done” (DoD)

The Definition of Done (DOD) specifies that all elements of a user story in a sprint backlog
have been completed. A user story is an informal explanation of a software system’s features
and characteristics. It is basically the user or client’s requirements of what they want to do
with the software product.

Each artifact contains a commitment to ensure it provides information in terms of

transparency and focuses on the progress :

✓ For the Product Backlog, the commitment is the Product Goal.

✓ For the Sprint Backlog, the commitment is the Sprint Goal.
✓ For the Increment, the commitment is the Definition of Done.

A Definition of Done is a clear and concise list of requirements that software must adhere to
for the team to call it complete. There are 3 levels of Definition of Done:
1. Story
• Acceptance criteria met

15
 • Unit tests are passed
• Code checked in and merged into the main line
• Code peer-reviewed
2. Sprint
• Product Owner acceptance
• No compile warnings in the code
• No blocker defects introduced
• Feature documentation complete
3. Release
• Release note updated
• Deployment document updated
• Stakeholder approval
• Full regression testing done

2.5 The Scrum Team

The Scrum Team have the following members:

• Product Owner

• Scrum Master

• Development Team

In addition, we have the Stakeholders, but they are not part of the Scrum team itself.

2.4.1 Product Owner

The product owner is a person who represents the business needs and responsible for
working with the user group to determine what features will be in the product release.

The Product Owner is accountable for maximizing the value of the product resulting from
the work of the Scrum Team. The primary way to achieve this goal as a PO is to manage the
Product Backlog effectively. Thus, the Product Owner is responsible for the Product Backlog.

According to the Scrum Guide, the PO is responsible for:

• Developing and explicitly communicating the Product Goal;

• Creating and clearly communicating Product Backlog items;

• Ordering Product Backlog items; and,

• Ensuring that the Product Backlog is transparent, visible and understood.

Source: Scrum Guide 2020.

16
2.4.2 Scrum Master
A scrum master is a facilitator for an agile development team. The Scrum Master is
accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping
everyone understand Scrum theory and practice, both within the Scrum Team and the
organization.

The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by
enabling the Scrum Team to improve its practices, within the Scrum framework.

According to the Scrum Guide, The Scrum Master serves The Scrum Team as follows:

● Coaching the team members in self-management and cross-functionality;

● Helping the Scrum Team focus on creating high-value Increments that meet the
Definition of Done;

● Causing the removal of impediments to the Scrum Team’s progress; and,

● Ensuring that all Scrum events take place and are positive, productive, and kept within
the timebox.

The Scrum Master serves the Product Owner in several ways, including:

● Helping find techniques for effective Product Goal definition and Product Backlog
management;

● Helping the Scrum Team understand the need for clear and concise Product Backlog
items;

● Helping establish empirical product planning for a complex environment; and,

● Facilitating stakeholder collaboration as requested or needed.

The Scrum Master serves the organization in several ways, including:

● Leading, training, and coaching the organization in its Scrum adoption;

● Planning and advising Scrum implementations within the organization;

● Helping employees and stakeholders understand and enact an empirical approach for
complex work; and,

● Removing barriers between stakeholders and Scrum Teams.

Source: Scrum Guide 2020.

In summary, The Scrum Master helps the group members work together efficiently and
effectively as well as educates and assist them in doing their job properly. They also assist
them in understanding and implementing the Scrum guide.

The scrum master ensures that team members have everything they need to perform their
job well. They remove any barriers to their team members’ work.

17
2.4.3 Development Team
A development team is formed with from 3 to 9 people who must fulfil all technical needs
to deliver the product or the service. They will be guided directly by the Scrum Master, but
they will not be directly managed. They must be self-organized, versatile, and responsible
enough to complete all required tasks.

The development team is responsible for delivering potentially shippable product

increments every sprint from analysis, design, development, testing, to technical writing,
etc.

According to the Scrum Gide, the Development Team are accountable for:
● Creating a plan for the Sprint, the Sprint Backlog;
● Instilling quality by adhering to a Definition of Done;
● Adapting their plan each day toward the Sprint Goal; and,
● Holding each other accountable as professionals

Source: Scrum Guide 2020.

In summary, The Development Team are responsible for creating the product. They bring
ideas to reality by creating the product’s parts and putting them together. The team members
know their part of the product and the work they need to do. They decide what work they will
do.

2.6 Scrum Meetings

If we summarize, we have 5 meetings in Scrum Development Methodology:

• Sprint Planning Meeting

• Daily Scrum Meeting

• Sprint Review Meeting

• Retrospective Meeting

• Backlog Refinement Meeting (Sprint Grooming)

2.6.1 Sprint Planning Meeting

The Purpose of Sprint Planning is to align the Developers and the Product Owner on what to
build next, delivering the highest possible value to customers. First, the Product Owner
points to the team’s Product Goal and introduces the business objective of the upcoming
Sprint.

The Scrum Team then collaboratively creates a Sprint Goal, considering who is available and
the target the team shall accomplish. Next, the Developers forecast the work required to
achieve the Sprint Goal by picking the right items from the Product Backlog and transferring
them to the Sprint Backlog. Also, the Developers need to create a plan on how to accomplish
their forecast.

The Product Owner ensures that attendees are prepared to discuss the most important
Product Backlog items and how they map to the Product Goal.

18
Sprint Planning is the first event of each Sprint. Here the Scrum Team decides what work will
be completed during the Sprint and what is the Sprint Goal. Basically, Sprint Planning
answers three questions:

1. Why is this Sprint valuable? (The Product Owner proposes how the product could
increase its value and utility in the current Sprint. The whole Scrum Team then collaborates
to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The
Sprint Goal must be finalized before the end of Sprint Planning.)

2. What can be Done in this Sprint? (Through discussion with the Product Owner, the
Developers select items from the Product Backlog to include in the current Sprint. The Scrum
Team may refine these items during this process, which increases understanding and
confidence).

3. How will the chosen work get done? (For each selected Product Backlog item, the
Developers plan the work necessary to create an Increment that meets the Definition of
Done. This is often done by decomposing Product Backlog items into smaller work items of
one day or less. The Sprint Goal, the Product Backlog items selected for the Sprint, plus the
plan for delivering them are together referred to as the Sprint Backlog.)

Source: Scrum Guide 2020

All sprints begin with planning. The team needs to identify and commit to which items are
going to be delivered as part of the sprint. The possible items are always taken from the
Sprint Backlog as shown in the image below.

Figure 2-5: Sprint Planning Meeting

In summary, during the Sprint planning meeting, the Product Owner identifies aspects they
need from a business/customer point of view. Then the SCRUM team identify which items
they think they can deliver and the SCRUM master accommodates all and ensures the best
of both worlds are met.

Velocity vs Capacity Planning

Velocity refers to the number of story points a Scrum team can deliver in an iteration. It’s
the rate at which developers can offer value per iteration. For example, if the team planned
30 story points (Business value) worth of user stories in a sprint and able to deliver as
planned then the team's velocity is 30.

Days, story points, ideal days, and hours are all ways to assess Scrum velocity.

19
The Scrum velocity of a team is 30 if it can deliver 30 story points in a Sprint. In other words,
Scrum Velocity is an approximation of how much the team has accomplished in the past.

When we use our past performance to plan our future sprints, we use the ‘velocity’ of the
team. We usually express velocity in terms of story points. Story points are units of measure
that consider a task’s complexity and size.

Capacity, on the other hand, is a measure of the amount of time in hours that team members
can dedicate to a project within a single sprint. So, the total number of available hours for a
sprint is called Team's Capacity. Available hours are Calculated based on resources planned
holidays and company holidays if any.

In short, velocity is measured in the user story and the capacity is usually calculated by
working hours.

Velocity
Sprint velocity comes down to a simple formula:

Velocity = Total Number of Story Points Completed Across Sprints/Number of Sprints

So, if we were to estimate our team’s average velocity across three consecutive sprints, the
answer would be the total number of story points completed across 3 sprints divided by the
actual number of sprints in the data set.

Capacity
Capacity measures the amount of time your team has available to work on sprint tasks. We
usually measure it in hours. Using this method, the team members choose the highest
priority User Story and break it into smaller tasks.

We often use the capacity to estimate how much future work a team can take on.
Additionally, this metric can help us determine whether the team is overloaded or has
enough capacity to meet its goals. We typically express capacity in terms of hours or days
per sprint.

To calculate capacity, add up the hours or days your developers are available during a sprint.

Each task estimates how many hours it will take to complete in the Scrum capacity. If there
is any capacity left, we select the next priority and add it to the sprint. We have to choose
the task so that the Scrum capacity is fully utilized and no additional capacity is available.

Let’s take an example.

Suppose we have ten members in our team for the two-week sprint. Each member works 50
hours a week.

Thus, the team’s maximum capacity would be 10 * 2 * 50 = 1000 hours.

However, 2 team members will be taking a leave for one week. That would make our capacity
loss 50 * 2 = 100 hours. So, our adjusted capacity is 1000 minus 100 = 900 hours.

Now, the ratio of your adjusted capacity to maximum capacity = 900:1000, which is 0.9.

Apply this figure to a hypothetical velocity of, say, 30 story points. We get the capacity as 0.9
* 30 = 27.

20
Make sure that we use the hours or days available for development work. Don’t include the
times when your developers are taking time off! Otherwise, this will be detrimental to your
culture.

Definition of Ready

In the Scrum agile framework, the Definition of Ready describes the requirements that must
be for a story to move from the backlog to development.

The definition of Ready means that stories must be immediately actionable. The Team must
be able to determine what needs to be done and the amount of work required to complete
the User Story or Product Backlog Item.

The Team must understand the "done" criteria and what tests will be performed to
demonstrate that the story is complete. "Ready" stories should be clear, concise, and most
importantly, actionable.

The Definition of Ready is a set of agreements that lets everyone know when something is
ready to begin, e.g., when a user story is ready to be taken into a sprint, or when all necessary
conditions are right for a team to start a sprint. An appropriate definition of ready will
substantially improve the Scrum team’s chance of successfully meeting its sprint goal. Here
is a list of benefits that a properly structured DoR can bring to teams:

• Measure a backlog item’s “ready” state

• Ensure that product backlog items have been thought through “just enough”
• Help the team identify when the product owner or another team member becomes
overwhelmed
• Keep the team accountable to each other
• Reduce pressure on the team to commit to estimates before stories are “Ready”
• Reduce “requirements churn” in development

Different teams will have different Dentition of Ready, and some require less. i.e., some
teams just describe the value to the user, prioritize, and write how-to demos. Other
estimates and communication are in the sprint planning meeting, etc. Here are the sample
items to be considered for developing DORs for our team:

• The Sprint Backlog is prioritized

• The Spring Backlog contains all defects, User Stories and other work that the team is
committing to
• No hidden work
• All team members have calculated their capacity for the Sprint
• Fulltime on project = X hours per day
• All User Stories meet the Definition of Ready

Example – Definition of Ready for a User Story

Below are some sample Definition of Ready for a user story, and a sample Definition of Ready
for a Sprint. We can adopt some of these as baselines or starting points:

• The value of the Story to the user is clearly indicated.

• The acceptance criteria for Story have been clearly described.
• User Story dependencies identified

21
 • User Story sized by Delivery Team
• Scrum Team accepts User Experience artifacts
• Performance criteria identified, where appropriate
• Person who will accept the User Story is identified
• The team knows how to demo the story.

In short, A definition of ready (DoR) is used to determine whether work on a task is ready to
be started. Before teams assign a task or user story in a sprint, it must be sufficiently well
described and understood by team members.

2.6.2 Daily Scrum Meeting

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the
Sprint Backlog as necessary and adjust the upcoming planned work. The Daily Scrum is a
15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at
the same time and place every working day of the Sprint. If the Product Owner or Scrum
Master is actively working on items in the Sprint Backlog, they participate as Developers.

Daily Scrums improve communications, identify impediments, promote quick decision-

making, and consequently eliminate the need for other meetings.

Once the team have identified the items, they are committed to delivering as part of the
sprint. The team will have a daily stand-up meeting. The core aim of this meeting is to
ensure everyone within the team (and possible observers) has full visibility of the status of
the tasks being done and progress:
✓ What they have done since the last meeting?
✓ What they are going to do today?
✓ What are the obstacles stopping them?

This daily update provides instant feedback to the team and provides. These meetings are
meant to be short and snappy no longer than 3 minutes per person.
Contrary to popular belief, its 15-minute timebox is not intended to solve all the issues
addressed during the Daily Scrum. It is about creating transparency, thus triggering the
inspection.
If an adaption of the plan or the Sprint Backlog, for example, is required, the Developers
are free to handle the resulting issues at any time. In my experience, most Daily Scrum is
intended to solve the current issue too.

In my observations, some questions that are not implemented in Daily Scrum:

✓ Orientation lost: The Daily Scrum serves one purpose as it answers a simple question:
Are we still on track to meet the Sprint Goal? Or do we need to adapt the plan or the Sprint
Backlog or both? Sometimes though, the Developers cannot answer that question
immediately. In that respect, visualizing the progress towards the Sprint Goal is useful.
✓ Planning meeting: The Developers sometimes utilize the Daily Scrum to discuss new
requirements, refine user stories, or have a sort of (Sprint) Planning Meeting, probably
collaborating with the Product Owner.
✓ Problem-solving: Discussions are triggered to solve problems, instead of parking
those so they can be addressed after the Daily Scrum.

22
 ✓ Monologs: Team members violate the timebox, pending the meeting and starting
monologues. Sometimes, the meeting should delay for 2-3 minutes monologues to wait
for the other scrum team to attend the meeting.
✓ Ticket numbers only: Updates are generic with little or no value to others.
(“Yesterday, I worked on X-123. Today, I will work on X-129.”)
✓ No impediments: No one reports any obstacles; no one needs any help or support
from their teammates. (However, maybe, Developers do not feel safe to address issues,
challenges, or problems?)
✓ Not enforcing the time-box: Sometimes, The Developers extend the Daily Scrum
regularly beyond the 15-minute time-box. (This is unfortunate, as the extension of the
time-box invites problem-solving and other activities into the Daily Scrum, thus distracting
from answering the critical question: are we still on track to accomplish the Sprint Goal?

Participants – Developers.
Recommended maximum duration – up to 15 minutes.

2.6.3 Sprint Review Meeting

Are we still on track to accomplish the Product Goal? Moreover, how did the previous
Sprint contribute to our Scrum team’s mission? Answering these questions and adapting
the Product Backlog in a collaborative effort of the Scrum Team with internal and external
stakeholders is the purpose of the Sprint Review.

Sprint Review is a meeting held at the end of the Sprint to inspect the Increment. The
Team demonstrates the Increment with a focus on the Sprint Goal according to the
Definition of Done. The Product Owner reviews and accepts the delivered Increment.

According to the Scrum Guide, the Sprint Review serves the following purpose:
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine
future adaptations. The Scrum Team presents the results of their work to key stakeholders
and progress toward the Product Goal is discussed.

During the event, the Scrum Team and stakeholders review what was accomplished in the
Sprint and what has changed in their environment. Based on this information, attendees
collaborate on what to do next. The Product Backlog may also be adjusted to meet new
opportunities. The Sprint Review is a working session and the Scrum Team should avoid
limiting it to a presentation.

The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum
of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

Source: Scrum Guide 2020.

The Sprint Review inspect the Product Increment and adapt the Product Backlog. The
Developers, the Product Owner, the Scrum Master, and the stakeholders need to figure
out whether the Scrum team is still on track to accomplishing its Product Goal.

The Sprint Review is held at the end of each Sprint in Scrum. Its goal is to inspect the
outcome of the Sprint with the key stakeholders (clients, partners, etc.). This allows the

23
 Scrum Team to check whether their work is what the stakeholders required and adjust
the Product Backlog if something needs to be changed.

Participants – the Scrum Team and key stakeholders.

Recommended maximum duration – up to 4 hours.

2.6.4 Sprint Retrospective

The fourth and last event in each Sprint is the Retrospective. This meeting is held to review
the team’s process and plan ways of increasing quality and effectiveness in the future.

According to the Scrum Guide, the Sprint Retrospective serves the following purpose:

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
The Scrum Team inspects how the last Sprint went with regard to individuals, interactions,
processes, tools, and their Definition of Done. Inspected elements often vary with the
domain of work. Assumptions that led them astray are identified and their origins explored.
The Scrum Team discusses what went well during the Sprint, what problems it encountered,
and how those problems were (or were not) solved.

The Scrum Team identifies the most helpful changes to improve its effectiveness. The most
impactful improvements are addressed as soon as possible. They may even be added to the
Sprint Backlog for the next Sprint.

The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours
for a one-month Sprint. For shorter Sprints, the event is usually shorter.

Source: Scrum Guide 2020.

The sprint retrospective is the last thing done in a sprint. Many teams will do it immediately
after the sprint review. The entire team, including both the Scrum Master and the product
owner, should participate. You can schedule a scrum retrospective for up to an hour, which
is usually quite sufficient.

To foster the discussion, the Scrum team usually tries to answer 4 key questions:

✓ What went well?

✓ What problems did we encounter?
✓ How did we solve/didn’t solve these problems?
✓ How to improve in the future?

Some teams use Agile-inspired task boards to write down the answers and then turn them
into actionable tasks for the coming Sprint backlog.

In short, this sprint retrospective aims to continually improve the team’s efficiency.

24
 Figure 2-6: The example Retrospective Board

Participants – the Scrum Team.

Recommended maximum duration – up to 3 hours.

Note:

1) No Accountability
At the last Retrospective, the team members accepted action items. However, no
one took responsibility for the delivery.
2) What improvement
The team does not check the status of the action items from the previous
Retrospective.
3) Waste of time
The Scrum team does not collectively value the Retrospective. The Retrospective
Meeting is held in the same procedure every time, ritualized and boring. I think the
meeting should perform in a different way to motivate the Scrum Team to be better
in the next sprint.
The Sprint Retrospective never changes in composition, venue, or length. There is a
tendency in this case that the Scrum team might revisit the same issues repeatedly.
4) No Documentation
No one is taking minutes for later use. (A Retrospective is a substantial investment
and should be taken seriously. Maybe the member can take notes and photos to
support this process).

25
2.6.5 Backlog Refinement Meeting
Besides the official Scrum Events, there is also an activity that many Scrum Teams do, which
is called Product Backlog Refinement (used to be called Grooming).

Product Backlog refinement is the act of breaking down and further defining Product
Backlog items into smaller, more precise items. This is an ongoing activity to add details,
such as a description, order, and size. Attributes often vary with the domain of work."

Source: The Scrum Guide 2020

As the team collaborates to create a list of everything that needs to be built or done for
project completion, this list can be modified and added throughout the project to ensure
that all of the necessary needs of the project are met. Therefore, before the Sprint
Planning, the Product Owner will invite the Development Team to attend the Sprint
Grooming ( Backlog Refinement Meeting). The Product Owner will ask the Development
Team whether the Scum Team need to add or modify the product backlog.

The items in the product backlog are prioritized and selected into the sprint backlog. A
sprint contains only a few large items, the impact of underestimating the work on even a
single item will have a profound impact on the sprint. And since larger items tend to be
harder to estimate and understand, the potential for a failed sprint increases further.
Experienced Scrum Teams will spend more time and effort to break down the complex and
larger items (i.e. user features or epics) into smaller user stories (or subsequenbreakking
down into tasks or subtasks).

Epic

An epic capture is a large body of work. It is essentially a “large user story” that can be
broken down into several smaller stories. It may take several sprints to complete an epic.
So when we take epic for development, it must be decomposed into smaller user stories.

Early in the project cycle, we come up with Epics. These are very high-level, almost
marketing-centric, bullet points of functionality.

We call large stories “epics” to communicate something about them. I like to think of this
about movies. If I tell you a particular movie was an “action-adventure movie” that tells
you something about the movie. There are probably some car chases some shootings, and
so on. Similarly, calling a story an “epic” can sometimes convey additional meaning.

User Story

A Story is a brief statement of a product requirement or a business case. Typically, stories

are expressed in plain language to help the reader understand what the software should
accomplish. Product owners create stories. A scrum user then divides the stories into one
or more scrum tasks.

A user story is typically a functionality that will be visible to end users. A user story follows
the format “I as WHO wants to do WHAT, so that WHY. A user story delivers value to the
customer/user. It’s a product requirement from the customer/user.

e.g. “As a customer, I want to be able to create an account so that I can see the purchases
I made in the last year to help me budget for next year.”

26
 Tasks

A task, on the other hand, is more technical in nature, Task is typically something like
coding this, designing that, creating test data for such-and-such, automating that, and so
on. These tend to be things done by one person. A task is not written in the user story
format. A task has more of a technical nature.

e.g. “Evaluate Angular material design for user interface” or “Submit app to app store”.

On the other hand, for ensuring the two other pillars have already been implemented. The
meeting should consider the Inspection and adaptation as shown in the Table below:

Events Inspection Adaptation

Sprint Planning Product Backlog Sprint goal
Commitments Retrospective Forecast
Definition of Done Sprint backlog
Daily Scrum Progress toward the sprint goal Sprint backlog
Daily plan
Sprint Review Product increment Product Backlog
Product backlog(release)
Market-business conditions
Sprint Retrospective Team & Collaboration Actionable
Technology & Engineering Improvement
Definition of Done

Table 1-1: Inspection and Adaptation

27
References
1. K. Schwaber, J. Sutherland, "The Scrum Guide, Definitive Guide to Scrum: The Rules of the
Game", November 2020, Available from: https://scrumguides.org
2. D. Young,”Software Development Methodologies”, GDIT & Alabama Supercomputer Center,
August 2013, Available from: https://www.researchgate.net/publication/255710396
3. H. Doshi, “Scrum Insights for Practitioners, The Scum Guide Companion”, 2016, ISBN: 978-06-
928071-7-0.
4. H.P. Halvorsen, “Software Development. A Practical Approach”, 2014, ISBN: 978-82-691106-0-9.
5. V. Mahnic, S. Drnovscek, “Agile Software Project Management with Scrum”, Research Gate,
2014, Available from: https://www.researchgate.net/publication/228967959
6. D. Turk, R. France, and B. Rumpe, "Limitations of Agile Software Processes," in Proceedings of
the 3rd International Conference on Extreme Programming and Flexible Processes in Software
Engineering (XP2002), May 2002, pp. 43—46.
7. Visual Paradigm. (n.d.). “Comprehensive Scrum Guide”.2022. https://www.visual-
paradigm.com/scrum/what-is-scrum.

28