Breaking down technical tasks with Atomic Planning

The best thing about software engineering is that we get to build things. Cool, cutting-edge and complex things! Whenever I see a shiny new technical task I want to get my hands dirty straight away. From the outset it usually looks like it will only take a couple hours. I wave goodbye to my product manager and without much of a plan dive right into the code base, confident and full of hope.

Days later I emerge tired, defeated and with a monolithic commit that my team members refuse to review.

This is a common story in software development. Underestimated features and missed deadlines. We often have help from product and design in breaking down user stories and defining Vertical Slices, but it is up to the engineers to clearly define a technical solution and plan of attack. This article is a guide for engineering teams looking to break down, swarm and deliver features more efficiently.

What is Atomic Planning?

Atomic planning is the practice of breaking down technical tasks to a level that focusses on a single enhancement or purpose

The technique borrows on many of the principles from Atomic Commits which is a tried and tested engineering technique where you break down your code commits into smaller chunks. When then code commits are smaller, team members can quickly review the code, collaborate and deliver value earlier.

Atomic Planning aims to separate tasks so that each one can be worked on in parallel and by different team members. This leads to Asynchronous work which ensures that each team member can move at their own pace and they don’t get blocked by something out of their control. Instead of waiting a couple hours for your code to be reviewed or feedback on another member’s task you can pick up another task and continue working.

By incorporating Atomic Planning during the preparation stages you can reap a range of benefits for your entire engineering team. Some of the key benefits include:

1. Better estimates — the mere process of atomic planning enables the engineers to align on the solution, evokes earlier discussions and gives the team a better understanding of the work they are estimating.
2. Focussed iterations — splitting up the work allows multiple engineers to be focussed on the same feature at the same time. This reduces context switching and keeps team meetings focussed. Context switching can reduce productivity by up to 80% so it is crucial to try minimise this in your team’s work.
3. Early value — delivering incremental improvements enables non-engineers to get a look and feel of the product. This opens up discussions and can address issues earlier on in the development cycle.
4. Atomicity — Delivering smaller batches of work makes it easier to test and track changes in your code base, in other words, Atomic commits will help you git legit.

Atomic Planning Techniques

As engineers we are not taught project management skills and how to break down tasks. Luckily there are a range of techniques at our disposal for breaking down tasks in a manageable way.

1. Split up the task into micro-behaviours

Identify each action a user could perform and the potential outcomes when it is completed. Focussing on a micro-behaviours sets the initial step of clearly outlining what the product value of the task and what an engineer should focus on.

2. Top down breakdown

When tackling a product driven feature, focus on planning the UI first, the key actions, the user experience and then the backend requirements. Diving deep into the UI requirements will ‘reveal hints about the model and API that will be need’ — A practical guide to small and easy to review pull requests

3. Push code early

Identify the foundational layout and architecture of your application. Push up boilerplate code as soon as possible into a feature branch or behind a feature flag. This enables other engineers to begin working immediately on other tasks.

4. Fake it till you make it

Use facades and shims to fake components and utils where possible. If you see some complex behaviour, split it out into a separate ticket and create a placeholder component or mocked function.

5. Be dynamic

If a requirement change or bug arises mid sprint, don’t jam it into your current ticket. Separating it into another ticket will encourage smaller Pull Requests and can also allow another team member to pick it up. Be clear about what a simple change is. If the new change can’t be done in 30 minutes or requires a lengthy discussion, consider splitting it out.

Communication

An important note is that atomic planning requires a high level of communication in your engineering team. You must identify what tasks are blockers and make someone accountable for delivering these early on in the feature implementation. Have an open conversation about what tickets each engineer is planning to work on and what a successful delivery will look like.

Some good questions are:

• Which tasks can be worked on at the same time?
• Who is available to pick up the first task?
• If there are no tasks left: who needs help or what should we test?

Estimations

By nature, an atomic task is much easier for an engineer to understand what needs to be done and how long it will take. Whether you use estimates and story points to track your team’s velocity or not, they are a helpful tool in the process of Atomic Planning. They help achieve the following:

1. Encourages technical discussions — Putting an estimate against a task will invoke discussions around differing engineer perspectives and uncover the true nature of the task
2. Identify non-atomic items — If a team estimates a task to be large, it is usually an indicator that it is trying to achieve multiple outcomes. These non-atomic tasks will block your team and often contain unknowns that will lead an engineer down a rabbit hole. Break these down further.

But it is so much easier to submit multiple tasks in a single Pull Request….

A common argument I hear to Atomic Planning and Atomic Commits is that it is easier for an engineer to submit multiple tasks at the same time. The engineering ego usually comes into play and we underestimate how much work will actually be involved in performing the extra tasks.

When an engineer bundles all their work together it leads to longer pull request reviews, increases the chance the reviewer might miss something important and most importantly it can block the rest of the team who are waiting for a certain piece of functionality.

Lack of Context

One of the real disadvantages of completing smaller tasks is that reviewing engineers do not get the whole picture. An engineer who is inspecting an atomic Pull Request will likely find incomplete features and strange behaviours. This can lead to assumptions and incorrect decisions.

“It’s the author’s responsibility to make the code review easy” — How to Split Pull Requests.

It is important to be explicit and provide helpful hints to the reviewer. Most importantly, introduce the context of the Pull Request, outline what is included in the commit and most importantly describe what is not included. If possible, also link a trail of Jira tickets so an engineer can see the completed and upcoming work.

Don’t get caught in the Planning Trap

It is important not to go crazy with your breakdowns. Studies have shown that it can take 15 minutes to enter the zone of Flow where you are most productive. When planning, do not break down every minute detail. It is healthy to enter a sprint with a bit of flexibility for the engineer to build on and adapt if needed.

A key to making Atomic Planning successful is to be flexible and agile. During your retrospective analyse what worked, which tickets you were blocked on and why. Every team has their own flavour of working and it is crucial to factor this into the way you split up your work.

Conclusion

As remote working increases it is important that we structure our work in a way that empowers engineers to focus and move at their own pace. Whether you are working on an isolated task or a feature with many engineers, Atomic Planning can provide you with a level of freedom to efficiently deliver an iteration with a high level of quality. Go forth and see how Atomic Planning can help your team.