3 ms·

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 small

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.

sverhagen 3y ago
Agreed. But and then... making small stories only works well for a limited horizon. So, now your estimating only works for planning ahead a limited time. You use that to build a general confidence in having a constant stream of feature output. And the same people can then make some assumptions about future projects, based on similar projects in the past. Which works great for feature factories, less so for committing to a tight, hard deadline for a big project that exceeds the limited horizon.
- 4ndrewl 3y ago
  Need to be sized appropriately to the project and planning exercise. Small stories for short projects, larger ones for large projects. Probably a bit of Goldilocks at play here.
- cheeseface 3y ago
  This is true, but when it comes to software projects, I don't think you can ever commit to a "hard deadline for a big project" unless the scope (or the cost of the project) is not set in stone.
  - sverhagen 3y ago
    You probably didn't mean that double-negative there. But still, scope may be set in stone from someone's perspective, but unless the circumstances are very exceptional, things tend to get uncovered as you move through the project that will upset the detailed plan. I just think that big projects have to assume a certain amount of uncertainty. Stakeholders will often accept some of that uncertainty if you have a proven track record of steady (feature) output. One of YOUR stakeholders may take it upon them to turn their confidence into an external commitment, but they should then also have the sway to deal with their error in judgement, and so on.
Falkon1313 3y ago
The slicing is the difficult part. Especially when there are so many dependencies, so many things are intertwingled, you need both back-end and front-end and maybe migrations and configuration to support this new thing. A legacy system has to work with an API, and there are permissions and data structures and so on that need to be right just for the bare minimum. 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.
- cheeseface 3y ago
  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).

sverhagen 3y ago

Agreed. But and then... making small stories only works well for a limited horizon. So, now your estimating only works for planning ahead a limited time. You use that to build a general confidence in having a constant stream of feature output. And the same people can then make some assumptions about future projects, based on similar projects in the past. Which works great for feature factories, less so for committing to a tight, hard deadline for a big project that exceeds the limited horizon.

4ndrewl 3y ago
Need to be sized appropriately to the project and planning exercise. Small stories for short projects, larger ones for large projects. Probably a bit of Goldilocks at play here.
cheeseface 3y ago
This is true, but when it comes to software projects, I don't think you can ever commit to a "hard deadline for a big project" unless the scope (or the cost of the project) is not set in stone.
- sverhagen 3y ago
  You probably didn't mean that double-negative there. But still, scope may be set in stone from someone's perspective, but unless the circumstances are very exceptional, things tend to get uncovered as you move through the project that will upset the detailed plan. I just think that big projects have to assume a certain amount of uncertainty. Stakeholders will often accept some of that uncertainty if you have a proven track record of steady (feature) output. One of YOUR stakeholders may take it upon them to turn their confidence into an external commitment, but they should then also have the sway to deal with their error in judgement, and so on.

Falkon1313 3y ago

The slicing is the difficult part. Especially when there are so many dependencies, so many things are intertwingled, you need both back-end and front-end and maybe migrations and configuration to support this new thing. A legacy system has to work with an API, and there are permissions and data structures and so on that need to be right just for the bare minimum. 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.

cheeseface 3y ago
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).