The Lifecycle of a Mobile Task
From planning, to execution and production, here is how to maximize productivity from the eyes of a mobile developer.
What is your team’s top priority when handling a task? Is it speed, flexibility, or quality? In a healthy team, the answer should probably be a little bit of everything. Are you satisfied with your current work methodologies, or do you sometimes feel as though your team is following a predefined, inherited process that does not necessarily suit your needs? Whatever your process may be, you can always customize it and try to create a tailor-made solution that suits your team’s requirements.
In this article, we will discuss how we adjusted our processes to suit our needs and why you should rethink and refine some of yours.
Motivation
Some of the ideas in this article might sound familiar or even trivial to you. After all, we did not invent the wheel , we simply tweaked it to work better in our terrain. Accordingly, before we dive into every step of the process, let’s discuss what we consider to be quality execution when facing a task.
Accurate Estimations
Any team member should be able to estimate each task as accurately as possible during the planning stages and execution.
Velocity of Execution
We should always aim for fast delivery.
Flexibility
Deal with changes efficiently and handle context switches when unavoidable.
Quality of Delivery
- Accuracy - Match the expectations set during the planning stages.
- Reusability - Reuse similar code in your project, and write your code in a generic manner for future reuse.
- Scalability - Scale the project to serve the needs of the current task and prepare for future task phases.
We will return to this list multiple times later in this article with more specific action items for each stage.
Planning
Let’s discuss mobile development with agile methodology and why mobile tasks are a bit different.
In most cases, we aspire to release a version at the end of each sprint. For purposes of this discussion, we will define a sprint timeframe as three weeks. This means that each mobile team has approximately three weeks to produce a working version that is ready for release.
Each version contains a set of tasks. Some are standalone (i.e., non-epics), and some are large tasks that can be broken down into a collection of user stories. Those are called epics, and this article will focus mainly on epic tasks.
In iOS, every version submission must be reviewed by Apple, so there is more time overhead to the actual production release. That also means there is no option to fix post-release bugs without uploading a new version, as a result, quality assurance plays a key role here.
Let’s return to our earlier motivation discussion and try define a clearer set of matching action items for our planning process:
Accurate Estimations
- Sprint tasks have a well-defined timeframe that makes accurate time estimations essential.
- Developers assigned to the task should be involved early in the process so that they can:
1. Highlight potential issues and update time estimations accordingly
2. Offer insights regarding the difficulty of implementation or reusability
3. Suggest a better solution (i.e., technologically) - Bug fixes and post-release changes should be considered in estimations.
Velocity of Execution
- We should discuss technical constraints and find solutions during the early stages of planing.
- It is also important to conduct comprehensive research and highlight potential issues before execution.
- We should be prepared for a long development process before a working product can be reviewed.
Flexibility
- We should be able to find quick solutions for issues encountered along the way within our timeframe.
- We should be able to communicate task and time estimation changes to everyone during every step of the process.
Quality of Delivery
- Time constraints should not affect quality, we should always aim for the best solution.
- Reusability should be part of the planning discussion, as it can help reduce time estimations immediately and for the future.
- Scalability should be part of the planning discussion, as it can help with reducing time estimations and preparing for future task iterations.
Planning stages are a series of meetings to help the developers gather all of the necessary resources and knowledge for a better, more productive execution. We’ll elaborate on each one in chronological order:
Pre-Planning
Estimated Length: 30 minutes
Attendees:
◦ Product manager
◦ Team leads
Agenda:
A discussion about which tasks should make it to the upcoming sprint. Each task is usually backed up by a specification document (in short spec), written by the product manager, and a user interface design made by the designer. In this meeting, the product manager and team leads will prioritize the tasks and try to give them raw time estimations.
The team leads can also highlight potential issues with a task or require some additional time for a supporting technical task if any infrastructure changes are required.
Tip!
It is highly recommended to decouple technical tasks from product tasks. Even if at first glance the two feel related, infrastructure changes or refactors can cause unpredictable changes and regressions that can be difficult to estimate at times. Separating the tasks and, of course, the order of execution, can help keep estimations more precise.
Sprint Planning
Estimated Length: 30 minutes
Attendees:
◦ Team lead
◦ Team members
Agenda:
The team lead will present the upcoming sprint tasks to the team. Each task will get a quick overview (i.e., from spec to design), while the team members can provide notes. The team lead will assign each task to a different team member or members. Any assignee will give its own raw time estimations as a way to double check the accuracy of the pre-planning estimations. After this meeting, the team lead can start the sprint.
BE Integration
Estimated Length: 30–60 minutes
Attendees:
◦ Team leads
◦ Task assignees — backend
◦ Task assignees — mobile teams
◦ QA
Agenda:
When a task requires supporting backend, it is crucial to review implementation (or planning) early in the process. In this meeting, the backend engineers will present their implementation or planning for the upcoming task. The mobile team members should make sure that they have all of the resources they need to complete the task properly, and that the backend is aligned with any changes or requirements on the client side.
It is also important to communicate the mobile team’s priorities to avoid waiting for resources later in the process.
Everything discussed in this meeting should be reflected on a backend integration document that will be filled by the backend assignee.
Kickoff
Estimated Length: 1 hour
Attendees:
◦ Team leads
◦ Product manager
◦ Task assignees — mobile teams
◦ QA
◦ Designers
Agenda:
After the mobile team members have concluded their research, reviewed all of the documents (e.g., spec, design, and backend integration), and aligned requirements with the backend, it’s time to connect everything together.
During this meeting, the product manager will go over the task and its requirements in detail, including introduction and KPIs through design and spec, possible next phases, analytics, and experiments. It is the developer’s duty here to highlight any issues that they encountered along the way during their research, raise red flags for potential problems, and suggest alternative solutions. The developers should also discuss missing resources, if any, and potential changes to time estimations.
By the end of the meeting, the timeline should be clear, and it should be possible to set up a version release date.
Tip!
After the kickoff meeting, we will create a task communication channel so that each discussion, side note, or change will be documented and available for all. Miscommunication issues can be a lead factor in slow or inaccurate execution.
Design Review
Estimated Length: 1 hour
Attendees:
◦ Team lead
◦ Team members
Agenda:
At this point, we have all of the information that we need to start planning our execution. The developers assigned to the task will fill out a design review document (in short DR) that covers every aspect of the implementation in detail.
Our DR document covers:
- UI Components - New and existing, naming, responsibilities, interface, and collaborators
- Data Components (e.g., view models, managers, etc.) - New and existing, naming, responsibilities, interface, and collaborators
- Non-Functional Requirements
1. Scalability:
◦ Are there any future iterations planned?
◦ Is there another phase to this feature?
◦ What can the developer do to ensure that future engagement with this code will be easy?
2. Reusability:
◦ Do we use certain pieces of code in more than one place?
◦ Can this code be reused in the future?
◦ Can we use an existing code for this task?
3. API - Network layer interface
4. Data Objects - New and existing, naming, and fields parsing. - Flow - Charts and diagrams
- Complexity Discussion - Assumptions, constraints, and dependencies
- Tests - Experiments and variants
- Time Estimations
- Special Considerations and Developer Comments - Open discussion
The team notes and suggestions will be added as comments to the document, solutions will be discussed on the appropriate communication channel if needed and will be followed up during code review, which we will discuss later in this article.
Execution
Although it sounds like a lot, all of the planning stages combined should not require more than one day of work. So, here we are on the second day of the sprint. Planning has been completed, the developers have gathered all of the preliminary information they need, we have implementation all mapped out, the team leads and product manager have received well-thought out estimations and even some red flags about potential issues, and we’re ready for execution.
Let’s return once again to our earlier motivation discussion and define some more action items for the execution process:
Accurate Estimations
- Time estimations should be assigned per subtask for a better followup.
Velocity of Execution
- We should break down epics into subtasks in a way that minimizes developer dead time due to a lack of resources.
- Maximizing efficiency of teamwork should also be taken into consideration with regard to the task breakdown.
- We should avoid content switches as much as possible.
Flexibility
- Context switches are sometimes unavoidable, so tasks should be broken down in a way that the developers always have another subtask in their queue.
- Task breakdowns should be flexible enough to cover absences, context switching, or reorganization between developers.
Quality of Delivery
- We should review every piece of new code along the way.
- We should test our code and let others (e.g., quality assurance, product, design, etc.) test it for us.
With those action items in mind we can start analysing the different stages of execution by order:
Subtasks
Breaking a task down into smaller subtasks can have a significant effect on the flexibility and velocity of execution. Each subtask should represent a standalone portion of the greater task, and should be available for reviewing (i.e., code review) and testing separately. Proper prioritization of tasks can prevent hang time (i.e., when a developer waits for a resource or another subtask to be completed) and help avoid redundant context switches.
Subtasks divided in the right way can help with:
- Teamwork (i.e., division between developers)
- Prioritization
- Meeting time estimations
- Boosting the code review process
- Parallelizing work with QA engineers
- Flexibility and agility when facing changes or context switches
Implementation
Without going into too much detail about source control and git workflows, let’s discuss branching strategy. To be aligned with our subtask division approach, we will create a feature branch for our epic task. Then, each subtask will have its own child branch. When the subtask is done, the branch can be reviewed and tested. Afterward, those child branches can be merged back to the feature branch. You can read more about it in my dark mode article under the “source control” section.
Benefits of using this strategy include:
- Multiple developers can work simultaneously on different subtasks.
- The code review process can be divided into smaller chunks, while avoiding one big messy review.
- QA can test the finished portions of our code simultaneously.
Code Review
To assure the quality of delivery, we need to let our peers review our code, not only to comment on mistakes or wrong implementations, but also to follow up on our DR discussions and make sure that code standards and guidelines are being enforced.
As discussed in the previous section, each of the subtasks will be reviewed separately to avoid one long code review. When the task is done and the developers feel ready to merge our feature branch back into the version branch, there should be another final lighter review to make sure that nothing was lost or forgotten in the process of merging all of the finished subtasks together.
Testing - Quality Assurance
Even when the task feels complete, it’s important to let others review our work. As previously discussed, quality assurance (i.e., QA) will take place during and at the end of the development process. The QA engineers should find bugs and highlight issues, regressions, and spec mismatches.
Designers and product managers can also have important input regarding how close the implementation is to the desired product. Although QA can be involved during the execution stages, it’s better to let designers and product managers review the release candidate version.
Post-Production
The tasks are finished and the version is out, so we’re done right? Well, not really. Post-release bugs and code fixes are always part of the process and should be taken into consideration as part of the time estimations.
The developers should inspect production health regularly and try to recognize trend changes through metrics. Experiments and remote features might also require some additional post-release work at times.
However, even when we are ready to move on to the next sprint, we want to dedicate some time at the end of the process to go back, reflect on our execution, and share our work and insights with the rest of the team as a means of self-improvement and knowledge sharing.
Retrospective
Estimated Length: 15 minutes
Attendees:
◦ Team lead
◦ Team members
◦ QA
Agenda:
At the end of every sprint and the beginning of each new one, right before the sprint planning meeting, we take several minutes to review the last sprint execution. Usually, team members can reflect upon their last sprint tasks and sum them up in a few key points (i.e, things that they think we need to preserve and the stuff that we can improve). It is important to suggest action items for each point so that we can follow up on them and keep improving the process.
Weekly (Team Presentation)
Estimated Length: 1 hour
Attendees:
◦ Team leads
◦ Team members
◦ Product managers
◦ QA
◦ Designers
Agenda:
Finally, we need to share the knowledge with the rest of the group. Accordingly, each developer will take some time to present work from the last sprint, discuss the process and experiences, and receive feedback for the final product. In this manner, every group member can get to know the latest releases and features of the project, while having discussions and sharing opinions about the process.
Conclusion
Our process can have an enormous effect on our actual delivery. Even if we feel as though jumping into execution without spending time is sometimes the right approach, as complexity increases, being unprepared can cause lower efficiency in the long run.
The size of your team or group should be taken into consideration when you are trying to define the right processes for you. However, always keep in mind that, on any scale, the right process will help increase productivity and eventually create a better team.
So, what are your thoughts? Do you believe that you manage to distribute your time better? Do you have anything to add to this process? Let me know in the comments.
Fiverr is hiring. Learn more about us here.
