How We Create Software: Development Process at Cleveroad

02 Sep 2016
9 min
author avatar
Nataliya Kh.
Business analyst

Customers always expect more: faster development, innovation, exceptional quality, and first-rate service. To ensure better application performance our Cleveroad team continually improves its business processes, providing a flexible approach to software development.

The seemingly incomprehensible process of software development can be a little frightening and tangled from client's point of view, while experienced developers think it's a piece of cake and don't usually bother to clarify this process to the clients. You will never notice anything like that at Cleveroad. We treat our clients as partners and try our best to make the entire process completely transparent and collaborative. As our client, you will be involved in all stages of the web or mobile development process.

So, let's clear the air about what these stages are and examine the whole mobile applications development process in detail.

Development Process at Cleveroad: How We Create Software

Agile approach to software development

At Cleveroad we stick to basic methodologies in the development process. Splitting software building into different stages with certain activities for the purpose of more effective planning and management is the way that lets us deliver solutions our clients expect. Scrum is a flexible iterative and iteration based development strategy which consists of so-called Sprints the basic unit of development.

Scrum methodology for software development process

Scrum Development Process

What is the role of Sprint in the app development?

In order to understand the mechanics of the software development process, we should get a deeper insight into what a Sprint is and what rules it should follow.

Starting point

Every Sprint starts on any given working day depending on the availability of the project manager (PM) and after the negotiated start date with the client. The beginning of the week, say Monday or Tuesday, is a perfect time to start. In order to prevent any possible misunderstandings, the agreed date must be included in the contract.


Usually, every Sprint lasts for two weeks. The length of Sprint can be discussed with the client and vary from Sprint to Sprint depending on the tasks and features to be covered.


Take a look at this article if you need more information about Scrum: What Is Agile Methodology For Mobile Development?

Tasks planned for each Sprint can be very different, however, there are basic rules that should be followed.

First of all, here is a list of things that should be done only on the first day of the First Sprint:

  • DevOps must configure Continuous Integration and Continuous Delivery for the Project.

Continuous Integration (CI) is a common approach to the development when all working copies are gathered and built to deliver a working product for testing.

Continuous Integration in app development

Continuous Integration approach

Continuous Delivery (CD) means development in short cycles which ensures the product is ready for the release at any time.

Continuous Delivery in app development

Continuous Delivery approach

Every time a build fails during CI or CD, all stakeholders must be informed about this via email.

  • DevOps must provide all necessary credentials to the team members.
  • If specification requires to develop a server side backend, DevOps must prepare two examples on their servers:
1. Development server. It is located on Redmine and used by other team members and QA during development.
2. Stage server. It is also located on Redmine and used by the client for testing.
What is DevOps and Redmine?
To put it simple, DevOps is all the things that make CI/CD possible. DevOps' practises and processes blur the line between development processes to ensure that building, testing, and releasing software is rapid, frequent, and more reliable. 
Redmine is a widely used project management tool for convenient projects tracking.

Besides these must-be-done steps during the first Sprint, there are a few things that all Sprints have in common, and these basics are also essential. So, the following things are done on the first day of any Sprint:

  • PM creates tickets in Jira using Jira terms for managing Project Development: Epic, User Story, Task, Sub-Task, Component if they weren't created before (during Sprint Zero for Sprint 1, or during Sprint N for Sprint N+1);
  • Quality Assurance Specialist (QA), assigned to the project, starts working on a Test Plan for the Feature List. After its completion, the Test Plan must be approved by the client no later than the middle of Sprint. The client can change Test Plan if needed but all the changes must be agreed with the PM and QA.

Development Stage during each Sprint

The first thing team members must do is to follow Code Convention related to their development environment in order to bring a high level of quality to the project.

What is Code Convention?

Code Convention (or Coding Convention) is a set of guidelines and recommendations that are aimed to ensure software structural quality. This means the team follows a set of rules for a specific language that recommend methods, practices and coding style of a program written in that language. Following these rules helps to improve readability of the source code and simplify software maintenance.

Every time a team member starts working on any task (it can be a sub-task as well), they must enable a time tracking timer. Once they pause development or complete the task, they must stop the time tracking timer.

Testing Stage during each Sprint

Every time the team member completes a feature, he must test it before changing the status of the task to "Ready to Test". If CI Build System can't build a project, or automated tests didn't pass, the team member must fix all issues. He is not allowed to postpone these issues to future Sprints.


You can learn more about testing stage in software development process if you read the article: Testing and Quality Assurance: All You Need to Know

Once the status of the task is changed to "Ready to Test", QA team starts testing the implemented feature. If a bug is found, then the task must be reopened and a new comment with the issue's short description, steps to reproduce, a crash log and/or screenshots must be added.

Creating design in software development process

If specifications require creating design to be created by Designers Team, Sympli service should be used. Sympli is a sophisticated collaboration platform for designers and developers. Here are some basic rules we follow to avoid all possible misunderstandings and make the app development which is followed by creating design run smoothly.

  • All screens must be designed following the guidelines of specific platforms (for example, Material Design for Android). This includes proper values of margins, paddings, icons sizes, fonts sizes, etc.
Material Design Mobile Layout

Material Design Layout

  • If specific fonts are used in the application, these fonts must be provided to developers (preferably TTF, as OTF must be tested by developers).
  • All clickable elements must have a default state, hover/pressed state, and a disabled state. This applies to the element's background and text color.
  • Sprites must be provided to web developers manually.
  • All screens that display lists must have an empty state.
  • If an animation is used on screen, GIF images or frames are required.
  • In some cases, information can't be displayed properly due to lack of space.

Learn about the UX techniques our designers apply to make your product look and feel perfect: 6 Quick UX Design Techniques That Really Work

Designers Team should propose a solution for such situations (for example, if the text is so long that it would be truncated, it should be displayed on multiple lines, etc.)

What happens at the final stage of each Sprint?

In the middle of the Sprint PM holds a Planning Meeting with the client to select features from Project Backlog (a full list of requirements to the app functionality, ordered by their importance) and move them to Sprint Backlog of the next Sprint with assigning priorities. Also, PM prepares specifications for the next Sprint.

Note. During the Sprint, it may happen that there is remaining time after all features have been delivered. In this case, PM can request the client to determine additional feature(s) to add to this Sprint. On the other hand, if it is obvious that not all features can be delivered, then PM works with the client to determine which features can be delayed or perhaps split in order to deliver the most value by the Sprint deadline.

At the beginning of the third quarter of the Sprint, QA performs Smoke Testing to find issues in already implemented features: features from Sprint Backlog should be checked first, then the whole system should be checked for integration problems. The results of Smoke Testing are listed in Test Plan.

Preparing a Product Demo

Before displaying a Demo to the client a few important things should be done:

  • Team members must implement all planned features from the Sprint Backlog and fix all issues related to them;
  • If possible, Regression Tests should be performed to detect any issues related to integration of new features with old ones;
  • QA must provide a Test Plan report to the PM with Pass/Failed checks;
  • PM must prepare Delivery Reports with information about time that was spent and time that initially was planned.

Delivery Report usually includes:

  • features that were implemented;
  • features that were planned but weren't completed for different reasons with some explanation of why they weren't finished;
  • change requests that were introduced and were implemented during the Sprint;
  • change requests that were introduced but weren't executed during the Sprint with the explanation of why they weren't finished;
  • known bugs;
  • time consumption (including fixing bugs), change requests, and completing on time.
Delivery Report at the end of each Sprint

Delivery Report components 

Note 2. If the change request affects the main functionality, completely changes it, etc. the Sprint must be stopped for a discussion with the client.

The time required for preparing a demo varies from 2 to 6 hours depending on the release type (intermediate, final, etc.) This time is considered in a Sprint planning.

At the end of Sprint, a demo is shown to the client. They can then test it during some agreed upon amount of time (for example, till the end of working day). In case the client finds any issues, they create a list of issues which will be reviewed by the PM. Then the PM checks and detects any improvements masked as issues. Improvements should be discussed with the client and added to the Project Backlog. Real issues are then added to the Project Backlog, fixed and are not billed.

Team members don't leave their work spaces until the client accepts the Sprint. They have to make hotfixes if the client requires major issues to be fixed ASAP before an application release to Play Google, AppStore, etc. Once the client is satisfied with the results, all project materials noted in the contract (source code, application executables, etc.) are delivered.


Find out more about project delivery process: Successful Project Delivery and How To Control It

I suppose, this detailed and somewhat formal information about app development workflow at Cleveroad will help you understand this complicated process better. Still, if you have any questions left, feel free to ask and get a qualified explanation regarding anything concerning a project that you might have. We will be happy to hear from you!

Rate this article!

An image An image
An image An image
An image An image
An image An image
An image An image
Love it!
(1382 ratings, average: 4.61 out of 5)
Latest articles
Back to top
As s part of our team, be ready for:
An image
Competitive Base Salary
An image
Comprehensive Benefits
An image
Great Work Environment
An image
Drug Free Workplace
Tell us more about yourself