Slicing and atomization have become popular terms in the software industry, but many developers may need help understanding their true meanings. Most people use both words to refer to the same process. Yet, the two terms apply to different practices in software development.
Understanding slicing and atomization can help developers, functional analysts, and QA engineers think differently about organizing their work into reasonably-sized tasks.
This article will explain the two practices and how they can improve team performance on large projects.
What is Atomization?
Atomization refers to the breakdown of tasks and development requirements into individual assignments that developers or QA engineers can fully understand and complete.
In any given project, we often receive multiple features to create and test at a time. Developers receive their tasks and requirements in formal documentation, such as user stories (agile methodology) or technical requirements documentation (waterfall methodology).
For both methodologies, the concept means the same; atomized tasks and requirements are small, realistic, and understandable assignments.
The consequences of bad Atomization
During a project, a team may receive an assignment to add and test a large update to the software. Large updates may require significant effort to develop and test; without proper atomization, they may overwhelm a development team. Let's look at an example of how poor atomization can affect development.
Consider a medical company project requiring the development team to create software with complicated medical specifications. The developers receive no special training and need help understanding the requested specifications fully.
Functional analysts, also untrained in the highly-technical medical terminology, attempt to deliver the project's operational requirements, split into different user stories, to the developers.
Our development team receives eight user stories. In the planning meeting, the developers determine each level requires substantial effort to develop and test. Consequently, they add some stories into the sprint and push others onto the backlog.
Shortly after beginning work on the first user stories, developers will notice that they need exit criteria, and their documentation could be more technical and precise. The developers realize that completing these stories will take much more time than first expected.
Additionally, the QA analysts figure that if the developers need clarification about implementing a new feature, they will struggle even more when determining how to test it.
In this scenario, the user stories need to be correctly atomized. But they require too much work, and developers need help understanding them. For greater success, user stories need to be broken down into smaller assignments with more straightforward documentation.
How to avoid bad Atomization
To ensure a user story is correctly atomized, we can evaluate it against the following checklist:
1 - Complete Documentation
An atomized task requires no further adjustments to its list of requirements. The documentation also clearly defines every specification, so developers have all the information they need to complete their tasks.
2 - Team has clearly defined tasks that complete the user story
Each user story should have task tickets for every team member. The task tickets should include a detailed list of steps that, once completed in order, conclude the user story.
3 - Team members understand the user story
Each team member should have a clear understanding of their role and the expectations for them. If a developer needs to learn how to begin a user story, we can assume the user story lacks a precise procedure.
4 - All user stories should have exit criteria
Often, managers may forget to include the exit criteria in each user story. However, approved exit criteria helps the team decide when a user story is complete.
These four criteria provide an effective method for determining which user stories to take into a sprint. We can consider a user story as correctly atomized when every team member can clearly understand their task and complete it without further questions.
Using these guidelines will improve performance by facilitating more dynamic collaboration and communication between the team members. However, some user stories may still be too large to take into a single sprint. For these cases, we can employ another technique: slicing.
What is Slicing?
Consider the following situation: we have to implement an important new feature that requires a lot of work from both the development and QA teams. Even with more team members, there may be too much work to finish before the deadline. Also, further atomization may decrease the aggregate value of the business when combining the various stories.
For example, if we have a project that needs to work on multiple devices (iPhones, Androids, tablets, and TVs), we can use slicing to keep the scope of functionality reachable before the deadline arrives.
In this case, we can split the requirements up by devices. We can determine the primary device for which the application should always work and develop the functionality for that device first.
Another way to slice is to split by functionality. However, we must remain cautious about maintaining the story's purpose and delivering the expected results to the client.
Let's suppose, for instance, a user story has an extensive definition, including the following E2E operations:
- Users can add items to the cart before proceeding to payment.
- Users can add their credit card info and shipping address.
- The system generates a tracking ID every time the user buys a product.
- When a user clicks on the tracking ID, a status map shows their product's current location.
- Users can leave reviews for a product to evaluate the vendor's service.
At first sight, we can see this user story includes several operations that require significant effort. In this case, we can split it at each point and have the following five user stories to work on:
User Story #1
Adding items to the cart.
User Story #2
Adding credit card info to payment settings.
User Story #3
Adding a shipping address to the order.
User Story #4
Generating the tracking id on each shop.
User Story #5
Adding reviews for a vendor's service.
After slicing, we can complete each user story individually and have a more realistic goal to achieve.
Splitting stories into more practical tasks also improves a team's ability to handle unexpected issues that arise during development. In these situations, we can decide which user story to deliver first and which requires more attention in the next sprint.
A final thought
Atomization and slicing address a single issue: large, complex assignments that confuse and overwhelm developers and QA engineers. By understanding and applying the two practices, development teams can keep their user stories detailed and realistic to improve their team's performance and deliver quality products more effectively.
