Slicing CRUD-Related Activities into Separate Backlog Items

A common question during backlog refinement is whether closely related CRUD operations should be implemented within a single Product Backlog Item (PBI) or split into multiple work items.

At first glance, grouping create, rename, and delete operations together seems reasonable. They all operate on the same entity and appear to belong to the same feature.

However, CRUD operations are not necessarily equal in terms of complexity, risk, testing effort, or business value. In many cases, splitting them into separate PBIs results in better planning and faster value delivery.

Different Complexity and Risk Profiles

Creating or renaming an entity is often straightforward. The implementation usually consists of validating input, updating persistence, and possibly writing an audit entry.

Deletion can be considerably more complicated.

Deleting an entity may require:

removing references from other entities,
handling cascading relationships,
preventing orphaned data,
applying retention policies,
maintaining audit trails,
checking authorization,
and protecting against accidental data loss.

For example, deleting a watch list might require removing all vehicle-to-list assignments before the list itself can safely be removed.

If creation, rename, and deletion are bundled into one PBI, the complexity of deletion tends to dominate both implementation and estimation. The relatively simple functionality then becomes blocked by the most difficult operation.

Independent Value Delivery

A useful backlog item should ideally provide value independently.

Once users can create and rename watch lists, they can already start working with them. The lack of a delete operation does not necessarily prevent the feature from being useful.

Deletion can therefore follow later.

Splitting the functionality allows the team to deliver and demonstrate the first usable increment earlier:

PBI 1: Create and rename watch lists.

PBI 2: Delete watch lists safely.

With a single combined PBI, none of the functionality is considered complete until deletion is finished as well.

This unnecessarily delays usable functionality.

Different Acceptance Criteria and Testing Scope

Another reason for separating the operations is that their acceptance criteria are usually very different.

For creation and rename operations, acceptance criteria might cover:

uniqueness of names,
naming rules,
authorization,
persistence,
and audit entries.

Deletion may require substantially broader testing:

removal of dependent assignments,
cascade behavior,
orphan handling,
retention policies,
authorization,
auditability,
and failure scenarios.

Combining all of these into a single backlog item makes the acceptance criteria unnecessarily large and difficult to reason about.

Separate PBIs make the expected behavior easier to describe and allow each operation to have a focused testing strategy.

Clearer Progress Transparency

Smaller backlog items also provide much better visibility into actual progress.

With separate PBIs, the team can report:

Creation and rename are finished. Deletion is still in progress.

With one large PBI, the backlog often communicates only:

In progress.

Even if most of the useful functionality has already been completed, the item remains unfinished.

This reduces transparency during sprint reviews and makes it harder for stakeholders to understand how much value has actually been delivered.

Different CRUD operations can also have significantly different implementation costs.

For example:

create and rename might require only a small amount of work,
delete might involve several dependencies and edge cases.

If everything is estimated together, the simpler functionality disappears inside the larger estimate.

Separating the PBIs makes the uncertainty visible.

A team might estimate create and rename as a small item while estimating deletion considerably higher because of cascade handling, policies, or data-integrity concerns.

The exact story-point values are team-specific, but the important point is that the work can be estimated independently.

This improves planning and reduces the risk of over- or under-committing during a sprint.

Risk Isolation

Deletion is usually one of the riskiest CRUD operations because mistakes can result in permanent data loss or inconsistent relationships.

Suppose a defect is discovered in the deletion logic shortly before a release.

If all CRUD operations belong to the same PBI, that defect may prevent the complete item from being accepted.

If the functionality is split, the safe portion can still be released:

creation works,
rename works,
deletion remains unfinished until the problem is resolved.

The riskier functionality no longer blocks functionality that is already stable.

Vertical Slicing

Scrum backlog items should ideally represent small, testable, and demonstrable increments of value.

That does not mean that every technical operation must become its own PBI. Splitting should still follow meaningful user value rather than technical layers.

In this example, however, both parts can represent useful vertical slices.

Create and rename gives users the ability to establish and maintain their watch lists.

Delete gives users the additional ability to safely remove lists they no longer need.

Each slice crosses the necessary application layers, can be tested independently, and results in observable user functionality.

That makes them good candidates for separate backlog items.

Avoiding the Mini-Epic

A warning sign during refinement is when a seemingly simple CRUD story starts accumulating many unrelated acceptance criteria:

create,
rename,
delete,
validation,
cascade behavior,
retention,
auditing,
authorization,
error handling.

At that point, the item is effectively becoming a small epic.

The fact that all operations affect the same entity does not mean they need to be delivered as one unit.

Conclusion

Bundling creation, rename, and deletion into a single PBI can hide complexity and delay otherwise usable functionality.

Splitting the work provides several advantages:

earlier delivery of useful functionality,
clearer acceptance criteria,
more focused testing,
better estimation,
more transparent progress,
and isolation of high-risk behavior.

The goal is not to split CRUD operations mechanically. The useful question during refinement is:

Can this functionality provide independent, testable, and shippable value?

If the answer is yes, it is usually a good candidate for its own backlog item.

In the case of create/rename versus delete, the difference in complexity and risk is often large enough that separating them leads to a much cleaner backlog and a more predictable delivery process.