How We Build Software: Development Process at Cleveroad
Software development process may seem tricky, especially if you're working with a remote team. That’s why we’ve created this brief guide that walks you through the development process.
In it, we give answers to the following questions:
- How do we start the process?
- How many people do we need? What are they responsible for?
- What tools do we use for design, development, testing, and communication?
- What will you get at the end of each stage?
So, here’s how we create software – from Sprint Zero to product release.
What’s a Sprint in Software Development?
But first things first.
In Agile development methodology (which we follow), Sprint is a period when a team has to complete a set amount of work.
Here’s how a Sprint works:
Each sprint lasts for two weeks (ten working days) and starts with a planning meeting. In that meeting, the product owner (client) and the development team agree on what work will be done during the Sprint.
A Sprint starts on any given working day, depending on the Project Manager's (PM) workload. Together with the client, they negotiate the starting day to prevent any mix-ups, and this date must be specified in the contract.
Now, let’s move to the actual Sprints and what happens at the beginning and the end of each.
BA Stage: Sprint 0
Sprint Zero is mainly about planning – it’s a preparation period before development starts.
Here we give a brief description of the planning stage. We’ve got everything covered in 'What’s a Project Planning Phase For?' guide, see it for more details.
First, Business Analysts (BA) prepare the list of features, work on the communication plan, and estimate how long the planning stage will go for.
Next, they define the scope of work (clarify the client's requirements) and document these requirements in a Project Specification.
The Design Team then creates wireframes, a schematic layout of the future UI design based on user stories.
How wireframes look like
Quality Assurance (QA) team checks the specification and wireframes. Next, developers (web, iOS, Android – depending on the platform) together with the UI/UX designer and PM start working on a detailed project estimate.
The client then looks through the estimate and, if everything works for them, signs the contract.
After that, PM starts writing a Project Plan based on the number of devs who will be working on the project. This plan, just like everything else on this stage, should be approved by the product owner.
|Team member||Responsible for|
Organizing the team, preparing the contract
Preparing user stories, validating wireframes
Validating user stories, wireframes, preparing a Project Plan
Validating user stories
Preparing a detailed estimate
Deliverables during Sprint Zero:
- Detailed project estimate
BA team and Project Manager stay in touch with the client during this Sprint, updating them on the work status.
Tools we use for planning and communication
Now, let’s see what happens with the product UI/UX design.
As soon as the client approves the wireframes, designers start working on visual concepts (2-3). The owner then approves one of the concepts, and the team designs the screens showing what happens after a user clicks on each UI element.
App design concept by Cleveroad
If the owner approves the work, UI/UX designer handles the project to developers (using Zeplin) and switches to a supporting role. From now on, if anything – icons, fonts, other graphic elements – gets lost or any design-related question arises, they take care of it.
Want more details? See how we go about UI/UX designing in our extensive guide.
- Visual concepts
- Design for a few Development Sprints
What we use for designing and sharing the work with devs
First Day of Sprint 1-N.
And we’re getting back to the software development services. Sprint N means any Sprint following Sprint 1 – Sprint 2, Sprint 3, and so on.
Sprint 1 starts with:
- Project setup.
- Setup for test environments.
- Continuous Integration/Continuous Delivery (CI/CD).
Let's break these steps down a little bit.
A Workplace Admin creates repositories and gives access credentials to the team.
If, according to the specification, the team needs to develop a server-side backend or frontend, DevOps prepare two servers:
- Dev server (AWS) for the team to work on functionality, bugs, optimization, etc.
- Stage server (AWS) used to show results to the client.
On the first day of First Sprint, DevOps configure Continuous Integration (CI) and Continued Delivery (CD) processes for the project.
That’s what happens on the first day of the very first Sprint. The rest of the process is pretty the same for all the Sprints. I’m describing what is going on days 2-10 of any Sprint in the next part.
What the team does on the first day of any sprint:
- Holds a planning meeting
- Design for the next sprints
- Prepares test documentation
After the planning meeting, QA starts working on the Test Plan of the current Sprint using Sprint Backlog.
Test Plan includes:
- Acceptance tests for checking positive/negative scenarios, permissions of user roles.
- Testbed configuration (includes OS name and version, browsers, mobile devices)
And here’s what the team members do:
|Team member||Responsible for|
Up-to-date JIRA tasks
Writing the Test Plan
Development according to guidelines for specific platforms
DevOps engineer (1st sprint)
Environment setup (dev, stage server)
Deliverables of the first day of Sprint 1:
- Email, notifying about the Sprint start
- Plan for this Sprint
Tools used by developers and QA engineers
Second – Penultimate Day of Sprint 1-N
Now, what happens every day during Sprint N:
- The team holds daily meetings
- Continues development on the scope of this Sprint
- Continues design for the next Sprint
- Prepares backlog for the next Sprint
- QA checking tasks
Each new day starts with the meeting where the Project Manager checks the status of tasks – what has been done yesterday, what’s going to be done today, and what gets in the way.
One more thing: when a team member starts working on any task, they turn on a timer. They stop it once they complete the task.
Every time a developer finishes working on a feature, they must test it. These checks include not only functional testing but also platform acceptance criteria.
Once the devs change task status to "Ready to Test," the QA team starts checking on the feature according to tasks, sub-tasks, and user stories.
If they find out that:
- Main functionality doesn’t match specifications
- UI doesn’t fit design
- No dev testing has been done
- Negative cases aren’t passed
- Small UI issues
…they reopen the task adding a comment that describes the issue, steps to reproduce it, a crash log, and/or screenshots. Or create a new task with a Bug label.
Bugs don't stand a chance. Find out what types of software tests we run and what for.
|Team member||Responsible for|
Holding daily meetings, preparing backlog for the next sprint
Ad hoc testing, acceptance testing
Writing code, dev testing, keeping code documentation up-to-date
Last Days of Sprint N
In the middle of the Sprint, the PM initiates a planning meeting with the client to pick features from the project backlog and move them to the next Sprint backlog. Also, the PM starts working on a specification for the next Sprint.
What else happens in the last few days of Sprint 1-N:
- Daily meetings
- Code freeze (day 9)
- Preparing of Sprint and test reports
- Product Demo (day 10)
At the end of the Sprint, the Project Manager prepares a Sprint Report with information about the time spent and time initially planned. Sprint Report also includes:
- List of completed features
- Not completed features (and why)
- Change requests (if any) implemented during the sprint
- Change requests not implemented during the Sprint (and why)
- Time spent, including bug fixes and change requests
Finally, the team works on the Product Demo. This process may take from 24 up to 150+ hours per Sprint. Before the Demo, QA team checks features added in the current Sprint as well as goes over the whole app making sure new functionality doesn't break the old.
Product owners test Demo for some time (for example, till the end of the working day). If the clients find any issues, they should list them. These issues must be added to Project Backlog and fixed at no additional cost.
Sprint 1-N deliverables:
- Builds on the stage (testing) server
- Sprint report
At the end of the Sprint, the team gathers for a Sprint Retrospective. It goes after the owners accept the Demo but prior to the next Sprint planning meeting.
The team discusses:
- What went well
- What could be improved
- How they're going to improve it in the next Sprint
Finally, let’s see how the release process goes.
Once the team finishes all Sprints, QA starts the regression testing process. They run tests on all platforms and all features and, if requested, perform Stress testing. That means they check how the software works under a heavy load to find its breaking points.
During this stage, QA engineers use previously written checklists. In some cases, they need to modify them, testing only the main features of the product.
Deliverables of Regression testing stage:
- Regression checklists
- Backlog of defects
Tools used for Performance/Stress testing
After the regression testing, the team is ready to start the Release process.
First, the QA team runs Smoke testing to detect simple failures enough to reject a software release. They perform:
- Smoke testing of Dev builds
- Smoke testing of Stage builds
- Smoke testing of Product builds
If they detect any major issues, devs have to make hotfixes. And do it fast, before releasing the app to Google Play, App Store, or moving it to the production server. That’s why the team doesn’t leave their workplaces until the owner accepts the work.
Once the owner is satisfied with the result, the team hands project materials over to a client.
|Team member||Responsible for|
Planning & meeting with the client, preparing specification for the next Sprint
Regression testing, stress testing
Automatic build deployment and delivery
- Deployment into production environment
- Apps (if any) published on Apple Store or Google Play
That’s it! That was a brief description of how the software development process goes at Cleveroad. Want to see the projects we’ve developed this way? Take a look at our portfolio!