Optimal slicing is indeed a hard problem, since what is ”optimal” also depends on what you’re optimizing for. Bigger slices more easily lead to higher short-ter

Optimal slicing is indeed a hard problem, since what is ”optimal” also depends on what you’re optimizing for. Bigger slices more easily lead to higher short-term throughput and more developer flow time, but less collaboration, knowledge-sharing, and predictability. You meantioned ”sprints” so sounds like you’re working with something Scrumlike? I worked in Scrum teams for ~5 years and have now worked with Kanban for the past 2. For me, Kanban has really solved much of the ”puzzle everything together at the end.” Instead of sprints we structure our around stories (goal of the original scope is ~2 weeks). Before we start, we slice the work inside the story into less than 1 day tasks (or as small as feasible). This allows us to have a high-level plan on the APIs, migrations, frontend, and backend work. Each story can then have 2-4 people working on them (depending on the level of ”natural concurrency” the tasks offer).