Scrum in Software Development – Guide for App Owners

If you read this article, you’re probably going to develop your mobile app with an external development team.

At the very beginning of this journey, you should know that the software development world speaks its own language.

And if you don’t want to get lost, learn it!

This article series will help you to understand Agile and its most popular frameworks (according to stateofagile.com)  which are:

• Scrum,
• Kanban,
• Scrumban.

In this post, I will focus on the first one.

Agile basics

First, let’s explore the concept that gave rise to many others, which is Agile.

Many software companies now promise that the product they supply will be delivered in an Agile way.

You can also read in many articles that the Waterfall is a thing of the past and that Agile is a much better way to deliver the product thanks to its flexibility.

But what does Agile mean in practice?

What is Agile?

In a few words, Agile is an iterative and flexible approach to delivering products.

• Iterative – because the work will run in cycles and the product will be delivered piece by piece, instead of delivering everything at once.
• Flexible – because the development process will adjust to your changing requirements.

Agile Manifesto

The actual term “Agile” (at least regarding software development) was first used within the Agile Manifesto.

This word should bring about thoughts of flexibility, agility, and responsiveness to changes.

What Agile means to you as a Product Owner

• The development team will communicate with you directly.
• The team will be open to changes and will encourage you to be the same.
• The work will be adjusted to your needs, which may change over time.
• Your satisfaction, as well as that of your stakeholders, will be the top priority.

Agile frameworks

Underneath the Agile coat, there is far more to discover.

Over time, several work skeletons – so-called frameworks – have been developed and successfully used.

Nowadays, the most commonly used Agile frameworks are Scrum, Kanban, and Scrumban.

Scrum is very widespread, it has a solid theoretical background and constitutes a good basis for other frameworks. This is why I will focus on it in this article.

Read also: Agile Roles and Responsibilities – From Theory to Practice

What is Scrum?

Scrum definition

Scrum is mostly used when it comes to software development but, in fact, it has a much wider range of uses.

It was created to solve complex problems and reach deadlines at once, so it is useful in many sectors.

All of the basic rules for Scrum are described in the Scrum Guide.

The name may sound mysteriously – Scrum took it from a formation used by rugby teams. It is how the team gathers in a circle to start the game.

You may be thinking – ok, but how does it relate to work on my product?

It does! In Scrum, a well-organized team is a priority. Without a team, Scrum simply doesn’t exist.

Opposite of Waterfall

Scrum is the opposite of the Waterfall method.

Scrum	Waterfall
It assumes work in cycles with an iterative approach	No iterations
Scrum assumes that requirements may change frequently during the project	Project requirements are set once, and only once, at the very beginning of the project
We can potentially release a product after each iteration	We can release the product only in the last phase of the project

In Scrum, the cycle mentioned above is called a Sprint. It can take 1-4 weeks – you will agree it’s length with the team.

Once the Sprint is coming to an end, you can expect that particular piece of work – the increment – is completed and potentially ready for release (to be put on the App Store / Google Play). Why potentially? Because the team will ask you, at anytime, if we are ready to release the product.

Key pillars of Scrum in software development

Scrum is based on empiricism and lean methodology. Due to this, decisions made during the development process are based on experience and thinking about the simplest solution that won’t cause wastage of time or resources.

The solid basics of Scrum in software development are transparency, inspection, and adaptation. They are connected with each other.

• Transparency – because everything in the process of work should be clear to you (PO) and to any team member. Once any case is discussed – the Scrum Master will make sure that all of the team members understand it in the same way.
• Inspection – because we should inspect our process of work to check if there is no wastage.
• Adaptation – because we should immediately adapt the improvements to the process if waste was found.

Are there any roles in the process?  What is your role?

As was already mentioned – a well-organized and cooperative team is the basis for Scrum and is called The Scrum Team.

The Scrum Team is cross-functional – it means that this group of people have all of the skills needed to create our application.

The Scrum Team has three accountabilities:

• the Product Owner,
• Developers,
• the Scrum Master.

Each team member has their special role and established responsibilities.

Scrum Team: Product Owner

Let’s start with the person who is the originator of the product/the application – you.

In Scrum, such a person is called a Product Owner.

Your main accountabilities as a PO are:

• To maximize the value of the Scrum Team’s work. In other words, you will be responsible for setting up priorities during work and plan the work for the next period of time (for the next Sprint) with the team.
• To set up a Product Goal that describes the future state of your product. Based on this, the team will plan its work in the future.
• To create the Product Backlog: a set of all of the tasks/items that have to be done by the team.

So, to sum up, you are responsible for the ‘WHAT’ part of the development.
You will not be alone in that activity. The cross-functional team will be happy to help you at each step.

Scrum Team: Developers

Developers are the second cell of the team in Scrum. However, it’s interesting (and important!) to that under this name are hidden not only developers but also Quality Assurance Engineers (the testers) and Designers.

This group is responsible for the ‘HOW’ part of development. They have all the necessary skills to help you create your dream app, so I encourage you to trust their knowledge and experience.

The key accountabilities of Developers are:

• To create a plan for the Sprint Backlog by choosing particular tasks that will meet the Sprint Goal (the goal of a particular period of time),
• To adapt their daily plan of work to the Sprint Goal,
• To be professionals in their work area.

During the development process, there might be many questions coming to your mind. All of them are important and may bring a lot of value to the project.

So, do not hesitate to reach out for answers to the Developers directly. In Scrum, you can contact them on a daily basis.

Scrum Team: Scrum Master

Last but not least is the Scrum Master. This role is crucial for ensuring the Scrum Team understands and applies Scrum well on a daily basis. This person is responsible for the PROCESS.

The key accountabilities of the SM are:

• To make sure that all of the team understands and uses the principles of Scrum well.
• To take care for the team’s effectiveness by removing impediments and creating good conditions for work.
• To support you in the creation of product backlog items (tasks for the Development Team), or setting up the Product Goal.

What is important here, is that the Scrum Master is not a proxy between you and the Developers.

Remember that you, as a PO, can rely on your team at any time. Confront your vision with them as often as it will be needed.

I encourage you to keep in contact with the team on a daily basis but, if that is not possible, remember that Scrum offers special events to meet and discuss any topic together.

When will the team need you?

In the Scrum cycle, there are five (and refinements, but more on that later) important events.

Your team will invite and expect you at all of them. Learning how they are connected will hopefully make it clear why!

Sprint

The first of these is the Sprint, which is a container for all the rest.

Following the Scrum Guide, Sprints are the heartbeat of Scrum, where ideas are turned into value. This means that all of the work that is needed to be done to achieve the product’s goal is done within the Sprint.

As mentioned before, a Sprint’s length should be agreed with the team but it usually takes 1-4 weeks. During this period of time, Daily Scrum meetings take place every (working) day. This is the second event in Scrum.

Daily Scrum

The Daily Scrum is a 15-minute meeting for developers to inspect and adapt (remember the Scrum pillars above).

In other words – to check if work is going as expected, if there are any obstacles and, if so, to agree on how to fix them.

This is a meeting for Developers. You, as the Product Owner, can be a listener.

Sprint Planning

Each Sprint has to be planned before it starts, so the next important event is Sprint Planning. During this meeting, the team will ask you how to increase the value of the product and what is the most important from the business perspective.

Then, together with the Scrum Team, you will define Sprint Goal and the Developers will choose the tasks that need to be done to achieve it.

Sprint Review

Once the Sprint will end, it’s time for the Sprint Review. This is the moment when the team should get your feedback regarding what was done within the Sprint.

This meeting used to have two parts: demo and review:

• During the demo session, you will be able to see the finished piece of your application.
• During the review part, you will be able to verify together with the team which tasks were completed (achieving the Definition of Done) and which were not.

The Definition of Done is a set of rules that defines whether the work on a particular task is done or not. It will be defined at the very beginning of the project. If you will all agree that tasks meet Definition of Done – such tasks will become a part of the increment (a new, valuable part of the application).

Sprint Retrospective

The last, but still very important, event closing each Sprint is the Sprint Retrospective.

The goal of this meeting is to discuss, together, whether we are able to raise the level of our efficiency and quality of work as a team. If the team will describe any action that needs to be implemented – such actions can be also added to the next Sprint’s backlog.

Refinement

The Scrum Guide does not treat Refinement sessions as events.

According to the Guide – Refinements are a constant process of specifying requirements by the team.

But, during a real project’s lifetime, it’s sometimes just easier to meet together and discuss all of the doubts regarding development. Due to this, a lot of Scrum teams organize Refinement sessions as separate meetings. During Refinement meetings, discussions include the common understanding of the scope of work and if further work is estimated.

How does the team estimate the end date of work?

The first thought that that may come to your mind might be – why do we estimate?

If the requirements of a particular feature are already known and well understood (during Refinement sessions) – they have to be written down as tasks, as mentioned before. In the development process, one developer will work on one task at a time.

All of the tasks should be visible both to you and the rest of the team.

To ensure they’re visible, we can use Jira’s virtual boards. Here, the team can place all of the tasks that have to be done within the current scope.

Tasks in Scrum can be both big or small – and simple or complicated.

The estimation of each task shows such characteristics. Thanks to estimations, you can plan the work with the team more adequately from one Sprint to another. A key to this success is the Velocity metric, based on estimations. I will explain it in more detail below.

In Scrum, we mostly use story points or hours to estimate tasks. Regarding the details of estimations in story points, I would refer you to this article: The Best Way of Estimating Your Product Backlog Effectively and Quickly.

If estimations are done in hours, then it is just the approximate time that the development of a particular task may take.

Estimates are also the fuel for metrics that help you to control the quality and the speed of the team’s work.

How can you be sure that the team works effectively?

There are no metrics mentioned in the Scrum Guide.

However, based on experience, there are several indicators that are worth sticking to.

Once we speak about tracking the progress of work, we, first of all, have to plan the actual work well.

A well-planned Sprint should meet your business goals for the next period of time because, as mentioned before, it will last up to 4 weeks.

We can think that, if the tasks for developers are well planned and organized according to business priorities – we should just let developers work.

Not completely. Something can always go wrong, despite our best efforts.

There are a few metrics that will inform you about the progress of work, help you to find out if we may get in trouble, or prove useful for planning the next Sprint better.

The Scrum Master of your team will introduce you to those metrics, help you understand the details, and encourage you to track them on a daily basis. Let me introduce you to two of them now.

Burndown / Burnup charts

Burndown / Burnup charts can show warning signs on our development way.
Don’t worry, it is not about fire: by ‘burning’ we understand the full completion of a task.

Those are the charts that show if we will complete our scope within a particular time frame (Sprint/Sprints/end date of the project). They take into account the approximate time spent on a particular task by the team and refer to the number of tasks that are left to be done.

Burnup chart shows the same values as burndown, but in a growing tendency.

It’s good practice to track the results of Burndown/Burnup charts every day ie. after the Daily session to make sure that our progress of work is appropriate.

Verifying charts on a daily basis also allows for an early response to detected delays.

Velocity

The second indicator that helps to plan work in both the shorter and longer-term is Velocity.

Velocity shows how much work was done by the team within the Sprint. It can be measured in story points or in hours, depending on which method of task estimation is used by the team (see above).

The approximate Velocity of the team is visible after a couple of Sprints.

Based on the results, you can predict the possible speed of work and plan the next Sprints more adequately.

For example: if in Sprints 1-3, the team completed tasks of approximately 30 story points, it’s highly possible that the team should be able to deliver a similar 30 story points in the 4th Sprint.

Scrum Pros

Using Scrum in software development projects has many advantages.

• High visibility regarding the progress of work. All of the work is kept on one board
• It helps to deliver a working piece of the application after each Sprint
• The team works on features that really bring value to you and other stakeholders
• You have the team’s full support and you are advised by developers, a group of professionals
• Your feedback is included at every step of the development process
• It helps to identify obstacles and inefficiencies, frequently removing from the process of work
• The project’s budget and time will be used efficiently, as you can make your further business decisions based on frequent results of the developers’ work
• Roles in the team are clearly defined and events have their own sense and rhythm, which increases the efficiency of cooperation
• The team has a chance to continuously improve the quality of their work, thanks to Retrospectives

Scrum Cons

• As the Scrum Guide says: Scrum is easy to understand but difficult to implement, so there is a big risk that Scrum will not be understood correctly by the team or by whole organization.
• There is a trap: the Scrum Master can be seen as a project manager when the PO selects him as the contact person for the team.
• Scrum only works well when all of the team members are equally involved and engaged in the process.
• Scrum will not work for projects where the scope of work appears randomly, ie. maintenance projects.

When is Scrum a good choice?

I hope that I’ve convinced you that the Scrum framework can turn out to be a very valuable choice. However, like any framework, it will work best under certain circumstances.

Scrum will be worth using if:

• It’s the very beginning of cooperation in Agile  – it allows you to learn good practices and use them later (if you switch to another framework).
• Projects don’t have strictly defined requirements at the beginning and the project seems to be complicated – Scrum leaves room for joint work and clarification of requirements during the development process. The requirements may also change.
• The team consists of less than 10 people – if the team is larger, it can be divided into several Scrum teams that work on one Product Goal.
• The team has a constantly supplied scope for work. It is important that, at every Sprint, you provide a similar amount of scope to develop. This ensures there’s no downtime.
• It’s important for you to release your app as soon as you see it’s good enough. If during the work, you decide ok, this is already a valuable product, we release it to the app stores!

Scrum – wrap up

Scrum and its assumptions and basics can be very helpful in organizing a team’s work at the very beginning. As you can see, this framework is a well-profiled skeleton of the basic rules that may sound simple, but may prove to be a challenge in implementation.

Based on our many years of experience, it’s always worth learning more about this framework at any stage.

At the start of app development, it’s essential you delve into this framework and learn it well. But even if you’ve already started your current project then, I highly encourage you to refresh your knowledge on the Scum rules frequently.

As soon as the team feels confident in this framework, they can start experimenting because Scrum, without imposing anything, gives a lot of room for self-interpretation and further modifications. I hope my article helped you to understand what Scrum in software development is.

Related posts