This works well, if the size of the stories is small enough.
When trying to get ”consistency” rather than trying to estimate better, you should aim for a smaller ”batch size” since it results in less variability.
When trying to get ”consistency” rather than trying to estimate better, you should aim for a smaller ”batch size” since it results in less variability.
There's only so far you can go with feature flags and "work in progress" changelogs. Plus having to beware shattering things into tiny pieces and then having to puzzle them all back together at end of sprint with code conflicts and tests that now fail when you combine things and maybe missing or incompatible bits that would've worked better if at least these pieces had been built wholistically.
You can only get so small before you're actually making more work and more potential for inconsistencies and delays.
All the tech stuff we do is relatively much easier in comparison to figuring out how to slice it well. That's the perennial challenge. Design, optimization, security - all are challenging topics, but none nearly as challenging as slicing things optimally.
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).