The post is solid on criticising sprint deadlines, but doesn’t give many suggestions on what works better. Except for this:
> Another idea is to experiment with more elaborate probabilistic ways of setting shipping estimates rather than gut based estimates.
In my experience, teams setting estimates and holding _themselves_ accountable is a great way to go with multiple benefits. This is why I’m a big fan on estimating software projects with a few ground rules [1].
Sprints and deadlines could be a tool to get here - as with a bunch of things, context, people and culture matter just as much as processes do.
Iterating and learning from iterations is how good software is produced, with a team that is motivated and continuously growing.
One estimation method I found good and worked at a risky project in my job (involved a regulator, they love deadlines) was:
1. Do the usual breakdown of tasks and point game to get relative difficulty estimates
2. Calculate the std dev points for each task instead of just averaging. The assumption is that this is valuable information about how uncertain developers are about the task, so we don’t want to throw it away.
3. Create happy-path and worst-case scenarios considering +-1sigma and +-2sigma
4. Prioritize tasks by deviation, to remove the most uncertainties at the beginning of the project
With this you start w/ a more realistic view of the uncertainty of the project, and it’s supposed to converge to the avg as the project goes.
> Another idea is to experiment with more elaborate probabilistic ways of setting shipping estimates rather than gut based estimates.
In my experience, teams setting estimates and holding _themselves_ accountable is a great way to go with multiple benefits. This is why I’m a big fan on estimating software projects with a few ground rules [1].
Sprints and deadlines could be a tool to get here - as with a bunch of things, context, people and culture matter just as much as processes do.
Iterating and learning from iterations is how good software is produced, with a team that is motivated and continuously growing.
[1] https://blog.pragmaticengineer.com/yes-you-should-estimate/