Building successful apps using scrum development

To stand out in the marketplace, quality apps that are user favorites can make all the difference. While there’s no recipe for final success, there are some tools that can help you with it. For us, the main tool is the scrum framework and its role in software development. Scrum development offers an approach that brings all the key players and skills together to produce digital products in a series of rapid and highly efficient instalments.

What is Scrum?

Let’s start with a short introduction.

Scrum is an agile framework tailor-made for the development of apps and other digital products. Scrum can be used to design and develop software in incremental iterations, ensuring progress at each stage. The whole approach is strictly empirical, based on experience and fact-based decision-making. No wonder that at Boldare, Scrum is our chosen solution for creating our user-centered, business-focused products.

What is Scrum development?

As an agile framework, Scrum is based on principles of transparency, inspection, and adaptation. Which is to say, transparency of process, including openness of communication, continuing inspection of both results and the ongoing process as a means of continuous improvement, and a readiness to adapt to changing circumstances, pivoting the project’s direction where necessary rather than being bound by an out of date objective or goal.

To put Scrum into context, the more traditional method of software development has been the waterfall methodology which relies on detailed documentation, limits client involvement in the process, and follows a rigid structure from start to finish. Agile (and by extension, Scrum) emerged in the early part of this century as a much more flexible and fit-for-purpose alternative, capable of developing digital products in today’s ever-shifting world (check out our article for more on the differences between the waterfall and agile approaches).

Making a long story short, the agile-based Scrum enables the creation software in small instalments that are released often (in Boldare it’s usually each week or two) on a regular basis. This way, we can be sure that our partners have full visibility of the whole process - from the very beginning to the happy ending: either releasing a new app to the market or putting a new set of features into the hands of the users.

Everything is transparent for our partners; they can not only follow the development process proactively, but also make changes to the initial business idea at any point in the process.

>>> See also: Product Vision Workshops – seeing clearly from the beginning

Scrum values

The Scrum Guide includes a set of core values that must underpin the work done throughout the Scrum development process:

  • Courage – to do the right thing and work on tough problems.
  • Focus – on each sprint and on the team’s goals.
  • Commitment – to achieving the scrum team’s goals.
  • Respect – within the scrum team and the project as a whole.
  • Openness – no secrets, all work and circumstances are up for conversation.

Scrum development terminology

For an exhaustive list of words used in Scrum development, the Scrum glossary on is the place to go. For our purposes here, these are the key terms used in this article:

  • Increment: a functional, working piece of software; when added together the project’s increments form the software or digital product.
  • Definition of Done: an agreed statement or objective that the increment must meet to be releasable.
  • Sprint: a set period of time (often between one to four weeks, depending on the project’s needs) used to develop and produce an increment. The process of scrum development in a project is a series of increments.
  • Scrum Team: effectively, the project team, including product owner, development team and scrum master.
  • Product Owner: the person responsible for input on the product and business expectations within the project; this role is usually taken by the client company’s representative.
  • Development Team: the team creating all aspects of the product; generally includes frontend and backend developer, product designer, and quality assurance engineer roles.
  • Scrum Master: the guardian of the agile Scrum process, and responsible for guiding, coaching, teaching and assisting the scrum team.
  • Sprint Backlog: effectively, an agreed to-do list of the work and tasks to be carried out to achieve the objective of the sprint; managed by the development team
  • Product Backlog: similar to the sprint backlog but for the Scrum development project as a whole; managed by the product owner.
  • Daily Scrum: a short, daily meeting of the development team with the goal of reviewing and checking that day’s planned activity (changes are recorded in the sprint backlog).
  • Sprint Review: a meeting to conclude and review the work done during the sprint. The scrum team and its stakeholders assess the progress, direction and impact of the work and update the product backlog accordingly.
  • Sprint Planning: a meeting of the whole scrum team, together with stakeholders, to decide what can be achieved during the sprint, including setting a sprint goal.
  • Sprint Goal: an agreed goal for the entire team, based on tasks from the product backlog and to be delivered within a single sprint.
  • Sprint Retrospective: a meeting of the scrum team at the end of the sprint to review the effectiveness of the Scrum development process and agree improvements for the next sprint.

If this list seems long, don’t worry. Scrum’s detailed nature can make it appear complicated but in reality, it is quite easy to understand. Especially if the theory is served with practical examples, and we will deliver it below.

Scrum roles - who is doing what?

Within the Scrum development process, the different roles interact so as to ensure the most efficient development process possible; for example, the product owner and any stakeholders have a great deal of input and can therefore exercise the necessary degree of control.

At Boldare, we go even further and our teams work without traditional managers. Some of their accountabilities are fulfilled by the scrum master, and others by the self-organized, dedicated team working together. This way, we work without proxies and our customers have always direct access to their teams and their members.

To expand on the previous mention, the key responsibilities for decisions and recommendations are:

  • Product backlog (technical issues) and tracking the work (development team).
  • Product backlog (non-technical issues and prioritizing tasks) (product owner).
  • Project scope (product owner).
  • Meeting agreed delivery dates (scrum master and development team).
  • The fit between development efficiency, product quality, and the client’s expectations and/or budget limits (scrum master and development team).
  • The Scrum development process (scrum master and development team).
  • Collaboration within the team (scrum master and development team)

>>> A step by step guide to Event Storming – our experience

How Scrum works in practice - a quick overview

What does a typical day or week look like for a scrum development team?

Let’s imagine that our team has already been working on your product for a couple of weeks. We have already held a product discovery workshop, which means that the team knows exactly what their goals are.

For our teams, each day starts with a daily stand-up, the meeting in which each team member (usually no more than 7-8 in the team) reviews their tasks and informs the rest of the team about planned activities. This is a daily opportunity to share details of upcoming challenges, issues and blockers. The daily stand-up should be no longer than 15 minutes, keeping the team focused on the project and how they need to support each toward success.

Read also: Lean Startup Series: Innovation Accounting

How does the team know what they should be working on? They use the product backlog as a reference, listing the tasks (such as creating app features) that need to be done to finish the product as agreed with the product owner (who, in case of Boldare’s development process, represents the customer). However, because the product backlog as a whole is usually very complex, the team divides the workload into several, smaller sprint backlogs. All the tasks in the sprint backlog must be finished during the sprint.

Ideally, the product backlog would be a closed set of tasks that translates into app features. This way it would be very simple to divide that main backlog into smaller (sprint) backlogs, and based on the length of those sprints we could easily estimate the time needed for the whole product (with all of the features described in the product backlog). In reality, the backlog is never (and shouldn’t be!) closed, but we will talk about that later.

Every sprint is bookended by sprint planning, a sprint review, and a sprint retrospective.

In Scrum development, sprint planning is key

Arguably, the secret of Scrum’s success lies in good planning, especially the planning for each individual sprint. The key issues for efficient sprint planning include:

  • defining sprint length
  • clarity of sprint goals (the ‘definition of done’)
  • ensuring that the sprint goal is genuinely achievable
  • involving the whole scrum team in the planning process

A well-planned sprint allows the team to work and focus together on the same goal and deliver a valuable increment.

Continuous improvement with sprint review meetings

One of Scrum’s most notable advantages is the flexibility of the process. Depending on circumstances, the project goals or the product’s features, can be changed. And the main mechanism for that flexibility is the review meeting at the end of each sprint.

What makes an effective sprint review?

  • The whole scrum team attends, plus key stakeholders.
  • The product backlog is reviewed, with each item classed as “done” or “not done”, according to the agreed definition.
  • The project timeline, budget and product features are considered.
  • Target dates for future delivery are checked and agreed.
  • Any changes to external circumstances (e.g. to the anticipated market for the product) are evaluated.
  • Looking forward, the team considers ‘what next?’ (this then becomes input into planning the next sprint).

Scrum retrospective - all the good and bad things so far

The other key tool for continuous improvement throughout the Scrum development process is the Scrum retrospective meeting. After all, if the team is to avoid repeating a mistake, they must be clear on where and why the mistake was made. This is why these popular “retros” are crucial for both teams and products.

The meeting is based on a simple exercise: all team members are encouraged to write down things that went well, what could they improve and what specific actions they will take to improve their work during the next sprint.

This meeting helps the team take a balanced perspective: appreciating the good work done so far, but also spotting issues and working out solutions and improvements for the next sprint.

If the team is partially (or fully) remote, it’s necessary to use some extra tools to conduct the retrospective effectively. We suggest Boldaretro - an app developed with the help of our scrum masters.

What are the practical advantages of scrum in software development?

Increment by increment, sprint by sprint, task by task, the team builds an app or digital product. The stakeholders can follow progress and even - if necessary - propose changes and suggest new functionalities, etc. (This is also why we usually don’t work on a fixed price basis - changes are unavoidable. Is that bad? Not necessarily!)

Scrum and its system of incremental delivery is change-friendly. This means that if you change your mind during sprint #3 and decide to add a new feature, the team can change or amend its direction without complications. Thanks to this, your app can be improved even before it hits the market!

To summarize: how does scrum guide and influence the development of the product?

  • Gradual and regular progress is made during development, thanks to the use of sprints and sprint backlogs.
  • Functional pieces of software (or design) are delivered each sprint, thanks to sprint goals that unite the whole team.
  • Problems are anticipated and solved in advance, and mistakes are learned from thanks to sprint retrospectives and the agreed actionable results.
  • Planning is easier, thanks to the use of backlogs.
  • The focus can be changed, pivoting the development process and adding or deleting backlog items at any time, thanks to the incremental way of working. In Scrum, it’s never too late to make a change!

As you can see, Scrum can positively influence the development process, but it also has multiple benefits on the business side of building an app.

See also: Digital Product Prototyping – what’s it all about?

Business benefits of Scrum development

Scrum can sound like an intricate or complicated approach. Definitely not (and much less so than waterfall software development). In fact, in the right hands, Scrum is a lightweight process that travels fast from initial business idea to fully-functioning app or other digital product. In comparison to other, less agile approaches, Scrum offers the following potential business benefits:

  • Quality products – Scrum’s iterative nature added to its flexibility means that the final product is as up to date as possible, meeting the latest user needs.
  • User satisfaction – the constant focus on the user and their needs in relation to the business concept means greater likelihood of having satisfied users; not least because the product owner acts a direct link between user needs, product requirements and the scrum team.
  • Fewer ‘dead ends’ – the Scrum development process allows for (encourages!) maximum flexibility; when factors impacting on business and user needs change, the product may need to be changed too, pivoting toward the new goal or direction; regular meetings and reviews mean that a Scrum project can ‘turn on a dime’
  • Reduced time to market – with Scrum, actual development work begins earlier because there’s no need for lengthy documentation to be created first; every sprint, something workable is produced; and the use of MVPs (minimum viable product) means you have a releasable product earlier.
  • Faster monetization – the reduced time to market with a usable product also means you can monetize and begin to recoup your investment earlier.
  • Better collaboration and teamwork – the role definitions provide clarity and the scrum team structure keeps things simple and eases direct communication between all parties; the result is usually a highly collaborative team, taking greater ownership of the project’s results, and consequently, higher morale.

The Boldare Scrum development process for web and mobile apps

As you can see so far, Scrum development follows a framework and process with carefully-designed fixed points and principles; a framework that allows for great flexibility.

To give you a practical example, the following is Boldare’s standard Scrum development process for apps and other digital products.

First, before the initial increment and sprint, we kick off with a product development workshop. The goal is simply to get the whole team together (including the product owner) and work through the business idea, plan the practicalities and agree what exactly the product will be (naturally, that may change later in the process if there’s a need to pivot but it’s important that we begin with absolute and agreed clarity).

This initial workshop may use tools such as event storming, impact mapping, and user story mapping to thoroughly discover and discuss all the relevant factors, including risk management.

Second, we usually work in two-week sprints. We find this ensures rapid progress but also gives us sufficient time to make each increment worthwhile. Each sprint begins with a sprint planning meeting which includes setting the sprint backlog.

Daily Scrum meetings keep us on track, and each sprint is rounded off by a sprint review and a sprint retrospective. The sprint process is repeated until the overall goals (maybe a full product, maybe an MVP, maybe a new scaled-up version of a previous product) are achieved.

Third, we work closely with our collaborators, keeping them always up-to-date regarding progress. We are extremely transparent with our work and decisions and this means that our partners can always speak with any of our team members at any time; without the “help” of a manager. And should issues arise, we are more than happy to help with various workshops and other, practical solutions that are based on Scrum.


The Scrum development approach is an agile framework highly suited to creating quality digital products. By ensuring transparency and openness of communication, together with a strong sense of collaboration from the first meeting, Scrum avoids the pitfalls of other software development routes, such as excess documentation and an inability to respond to changing circumstances. Here at Boldare, we’ve found Scrum to be the ideal tool for rapid development that meets both users’ identified needs and the owner’s business needs.

If you wish to see how we practice Scrum and agile - check out the section below to find some interesting articles.