There are limits to the decomposition, and for conventional projects where monitoring may be less routine (meaning not every day), it is in our best interest to decompose as far as possible to make answering any question about the status simple, yes or no rather than some vague estimate of completion (30% complete based upon no real measurement).

In agile we consider the law of diminishing returns (meaning benefit reaped from additional time decomposing and estimating is low) knowing that adapting to the situation is going to be required anyway. We want to break it down enough to gauge what it will take, in as much as a guess can do.  We also want to make sure we do not miss steps, forget elements or the sequence of events.  The project will only spend 4-8 hours of planning in sprint planning.  This will include the team, scrum master and the product owner.  In this meeting we will come to a collective understanding of what constitutes done or completion of an item, as well as refine our estimates via this collaborative discourse.  We will resurrect what constitutes done in the sprint demonstration comparing the delivery to the definition of done from the beginning.

One potential downside of breaking down and choreographing the product to the smallest elements, is that this can give you the perspective that this is the way things must happen.  Some may find it difficult to deviate from the plan.  However, there are probably other ways to achieve the objective of the project.  In agile, the breakdown needs to be sufficient to estimate how much can fit into the sprint.  Since estimating is a guess, and the time allocated for the sprint is relatively short 10-20 days, our team must be cautious not to over populate the sprint.

In summary, the team needs to estimate and populate (sprint planning) the sprint in 8 hours, knowing there is variation and likely parts missing and certainly items that have associated uncertainty.  We will adapt to the circumstance as we learn in the project.