4 ms·
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 us
by 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 agoNeed 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 agoThis 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 agoYou 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.