Farfetch Apps Development: Organizing future Sprints
By: Farfetch Tech
Tags: Technology, Mobile Apps, Engineering, App Development, Agile

By Francisco Medeiros, Test Engineer — Mobile and Sílvia Costa, Test Engineer — Mobile

Do you know what it takes to build the Farfetch iOS and Android apps?

These two platforms are a combined effort of more than 70 people, with the teams divided by PODs which are small custom agile teams, ranging from four to eight members, responsible for a single task, requirement, or part of the backlog. This organizational system is a step toward realizing the maximum potential of agile teams by involving members of different expertise and specialization, like Developers and QA Engineers as well as Designers, giving complete ownership and freedom, and expecting the best quality output. These PODs are laid out to the scope of several product verticals, some dedicated to technical foundation and others to features, not only aligned with the web experience but above all with the business.

The continuous improvement of our apps requires a considerable amount of research, design, planning and development, which is a real challenge to all the participants.

Using timeboxing is a critical component for all of the Scrum events, such as Sprint, Sprint Planning, Refinement, Daily or Mobile Reviews and as a tool for concretely defining open-ended tasks like POD Syncs, cross-team or other required meetings.

This keeps teams focused on accomplishing the task at hand by providing a clear definition of “done”. Time constraints are a crucial component in helping us coordinate the efforts of a diversity of roles and teams.

Do you think that writing code all the time is the best way to be productive?

Software engineering relies on thinking and planning as much as it does on coding, acknowledging the importance of a design phase combined with a solid business case can actually save overall time by reducing refactoring and bugs in the long term. Plan better to identify and address major technical and scheduling risk areas.

Our planning starts by creating high-level estimates, where it’s essential to have a precise alignment within product, design and engineering. Our preparation and analysis also requires looking into resource availability, project scheduling and cost estimation so that we can define a capacity plan and a proper roadmap. This roadmap should be informed by a clear strategy that details what’s going to be built, why, and how we see it coming together.

When doing our estimations, we found that a combination of both Top-down and Bottom-up estimation techniques was the best approach to plan our features.

Top-down Estimates start by gathering enough information to get started and later adding more data as the team receives it. They can also leverage data from previous projects.

Advantages of Top-down Estimation

Quick overall cost overview. Effort predictability. React and adapt to changes. The initial estimates are snapshots, so they allow for fluid changes. A team can add new information as it becomes available to refine the earlier estimates and add detail as the project moves forward.

Bottom-up Estimates apply when having a proper level of detail for the project. This method involves using a work breakdown structure. First, estimate each task one by one and later roll up all the estimates to get the total project estimate.

Advantages of the Bottom-Up Estimation

Big picture of project feasibility. Extended documentation of all requirements. Detailed task estimation.

High-Level Estimation: L1

When a Product Manager (PM) first touches base with a lead or senior engineer to share a big-picture idea, we get a glimpse of the goals and scope of the initiative.

In this early stage, we have limited information, so we need to evaluate the problem we are trying to solve and provide a high-level estimate measured in the T-shirt sizing model. T-shirt Sizing is one of the Story points sizing techniques to estimate user stories used in agile projects. It’s a relative Estimation Technique, rather than having T-shirts in sizes 4, 5, 6 etc, there are just a few sizes: Small (S), Medium (M), Large (L) and Extra Large (XL). This technique is used to forecast the effort required to work on each feature. As the ideation and exploration process evolves, some of these initiatives may be abandoned — for example, if the L1 estimate is deemed too high for the expected benefit of the initiative. However, usually they go-ahead to the next stage.

High-Level Estimation: L2

After this initial phase, it is time to involve the rest of the engineering team for the first time. As the PM shares goals and KPIs, the team begins to estimate the effort required by reviewing the designs, risks, dependencies and minimum requirements to complete the initiative. These estimates are done and measured in One Person per sprint. This unit measure considers the effort based on past experiences, internal debate and agreement among team engineers, for what a single developer might be able to achieve in a sprint while focused on a single initiative, in addition to the usual meetings, interviews, and operational bug fixes.

This stage is crucial for the whole POD to level their knowledge about everything that the initiative requires to be complete.

Capacity Planning

After completing the estimation for the implementation timeline, we have enough information to start the planning phase, considering the work capacity of the team. We take into account the number of available elements, vacations, bugs, refactoring and learning time. We use the concept of learning time to account for the ramp-up of any team members on relevant new skills and personal development objectives during the sprint. All these variables are taken into account to define an execution strategy and evaluate opportunity costs, thus creating a Capacity Plan.

Managers often struggle with challenges such as the following:

Autonomous teams

Shifting and conflicting priorities

Tasks that are difficult to estimate

Understanding actual work versus planned work.

With capacity planning, managers can better anticipate how long something will take to complete and if they have the right staff available to do the work.

In practice, we discovered these benefits of capacity planning:

1. Optimising project costs

Capacity planning lets you visualise what everyone is working on. It makes it possible to change upcoming task assignments and projects based on the team’s skills as well as their availability.

For example, managers could decide whether it is worth delaying the start of the project by a week to reduce overall resource costs on the project. All the information is transparent, allowing managers to make the best decision on how to spend the budget.

2. Ensuring availability

Capacity planning shows what the demanded scope is to take on new projects. It reveals resource availability to avoid disappointing stakeholders or overstretching your team.

Any of your project plans are at risk when the team continually works overcapacity. They are more likely to take time off work with sickness or stress-related conditions.

3. Managing team expertise

When allocating someone to a task, you can quickly see if they are the right fit. Managers can also view collective skills at the team level and identify if it sufficiently maps to future strategic business initiatives or if you might have a skill shortage.

Skill shortages can exist at the broader team level or within a few key skills among a limited number of team members, highlighting the need for training, internal mentoring, or future recruiting strategies.

4. Allocating resources

Managers must be strategic about how they use their teams and on what. Capacity planning helps to balance the challenges of finding and allocating people to work effectively.

With the right people doing the right work, the success and predictability of projects across our organisation improves.

Roadmap

The Engineering Manager, Engineering Team Leader and Product Manager check the timeline resulting from the Capacity Plan to check if there is a need for adjustments due to dependencies and to validate if it is acceptable from a business/product standpoint.

This is the last chance to plan timeline optimization strategies like parallelising work within the team/other teams, to descope features and to get a balance between “done” and “perfectly done”. Technical debt can also be mapped out.

After establishing the capacity plan, we are now able to proceed to the final stage of planning and roadmap creation, with the primary objective of formalising the implementation of the initiative and communicating the start and end date of the project to the organisation/with key stakeholders.

After a consensus between stakeholders (Product plus Engineering) is met, the commitment to Lean Portfolio Management is carried out by creating Epics and projects in Jira.