From Idea to Product
How We Work in Neshan Android Team to Develop and Release Different Versions
Introduction
Global Navigation systems such as Google Maps and Waze have revolutionized the way we travel and find routes. However, these two systems still lack precision and reliability when it comes to local areas around the world and especially where global systems have limitations for their services. To offer better services for mapping and navigation on the go, we created a locally developed system called Neshan. I am going to explain the development process of the Neshan Map and Navigation mobile application. The present method has been created and improved over the last three years that I was responsible as a product owner of Android and iOS applications.
What Is Neshan?
Neshan is Map & Navigations mobile application that released in December 2017. Neshan is an alternative for Google Maps and Waze in Iran. We built it from ground up with a team of 10 people. At present, according to Firebase Analytics data, we have more than four million active users in Iran. We, in the mobile application team, are the point of contact with end-users. Our responsibility is to deliver services that provide by different teams such as Routing, Traffic estimation, Search, and Map’s data to users. Collaborating with several other teams with completely different services, imposes several technical challenges for our team. Therefore, if we start developing with the wrong process, we face unpredictable difficulties that delay service delivery to the market. Furthermore, it may overwhelm the technical team down the road.
Below are the main steps we follow to build and release a product:
Review the Ideas
When the product team finishes their research on adding a new feature to the product, we gather together to review the general idea. In this session, we try to break down the feature into small parts to deliver in several sprints.
Low Fidelity Sketch
In this step, we must create a sketch for the entire project, which helps the technical team to achieve a helicopter view of the design architecture. It is also useful for the product team to get convinced that the tech team understands what they want. Generally, the first low fidelity sketch of the whole feature results in a common understanding, and it is the goal of this step.
Afterward, we create a low fidelity sketch of the first part of the work with more details to prepare it for development.
Revise
We review and discuss the sketch with product and tech leads that help us spot design faults and drawbacks. It also helps to discover unforeseen aspects of the design, which is impossible to determine at first glance. Furthermore, the review session highlights technical risks by showing almost all of the product’s workflow.
Revising and sketching continues until we reach a clear definition of the final product and user journey.
Software Requirement Specification (SRS)
In this step, we prepare a detailed software requirement that helps the developers to understand every small aspect of the project. It helps them to break the user story into small tasks. SRS document also helps marketing and product teams in the future as a reference. In a few cases, there were several small features in the product that new members of marketing teams didn’t know.
We add user needs, dependencies, implementation requirements, and collaboration with other subsystems in an SRS document.
Frequently when adding details, we find out small or big conflicts or technical issues that can be considered before development.
High Fidelity Sketch and User Interface
We start to create high fidelity sketches after review sessions, and at the same time, we are preparing the SRS document. This sketch is interactive, so we can test it with real users to get early feedback. This helps us apply any modification in design or software requirements. Our Design team utilizes Adobe XD and Figma to create interactive designs that provide in-app and web-based access to designs. We use the web-based output to share the prototype with developers, which helps them understand user flow and relations. We also use the in-app output to share prototypes with test users to get primitive feedback.
In the final step, the design team gives the user interface documents to developers with Zeplin.
User Story
Next, the product owner prepares the user story and attaches it to the SRS document. It is also required to provide a Definition of Done (DOD), acceptance criteria, and required tests in this step.
Grooming
We discuss next sprints user stories in grooming sessions with the scrum team to get the backlog ready for the upcoming planning session. It also helps us to figure out if any prerequisite prepared before the planning session.
Planning
If we conduct the steps mentioned above correctly, we experience a great planning session because every backlog item is specific for the entire team, and this helps developers to break the backlog items into corresponding tasks and have an accurate estimation of each of them.
Test and Release
First of all, features are tested by developers during the sprint. Then the QA team tests the feature based on the SRS document. QA team has a close collaboration with developers until they reach a bug-free version of the feature. Following that, we utilize Google play console and provide an alpha version for internal testers, which are our colleagues. After that, we release RC versions for beta testers to find out any device incompatibility or crashes that may happen in particular situations. We continue releasing RC versions until we reach a stable and bug-free version. Eventually, we start to stage roll out and look at user reviews, in-app feedback, support tickets, Google play, Firebase Analytics, and Crashlytics data to ensure everything runs as expected.
Conclusion
An essential craft for agile teams is effective communication which helps the team to discover early feedback. As a product owner, you must facilitate intra-team and inter-team communications. It would help if you also defined several processes for receiving feedback in the whole product design and development life-cycle. Another crucial task of a product owner is to bring sufficient information about the feature in grooming and planning sessions. Time estimation by developers in planning sessions based on insufficient information is the critical reason for the failure of the project. Moreover, consecutive failures affect the team’s morale and hinder their performance.
Following what I described earlier in this article, we at Neshan mobile application team experienced several successful sprints with the minimum required modifications.
I’d appreciate it if you could share your experience or ideas as a product owner or developer about this process. Let me know if you believe some parts can be done differently.
