A day is crazy. In my experience, retrospective takes about 30-60 minutes, and estimation is usually 1.5-2 hours.
Does it take time? Sure. But what's the alternative? Not doing it is even worse, because you wind up with these endless never-finished "features" that turn out to be 20x harder than anyone thought, that engineers have sunk months and months and months into...
Same - my new team doesn’t do any scrum or story points and it’s an amazing breath of fresh air - don’t miss those days just yelling random numbers at the zoom call for hours.
The truth is on most teams one or two people who are closest to the task have enough context to estimate, and probably only after they spent some time starting or prototyping the task.
Those people can give a reasonable estimate, in time not some strange point system.
Sometimes the estimate is wrong and that’s ok.
It’s fine to have a meeting catching everyone else up on the context but those pther people still likely don’t have enough to give an accurate estimate and shouldn’t be involved in estimation
Let me be clear -- nobody finds planning poker or story estimation fun. The same way nobody finds writing tests or documentation fun. So of course it'll be a breath of fresh air if it's not part of your job.
But the fact remains that in most environments, it's extremely useful for medium-term planning and especially in surfacing high-risk features that can send people down the wrong path for a long time. And it's meant to benefit stakeholders -- the people paying the developers' salaries -- not individual developers. It's about de-risking.
And if you really have the kind of team you seem to describe where everybody only works on their specific type of task and can't even estimate anybody else's work, then that's a danger situation when they leave or get sick or whatever and nobody else can step in and everyone's blocked because the only person who can do X is gone. Usually, you should be actively getting other developers to work on these features (usually the easier/smaller ones) and involving them in the estimation.
crazygringo|1 month ago
Does it take time? Sure. But what's the alternative? Not doing it is even worse, because you wind up with these endless never-finished "features" that turn out to be 20x harder than anyone thought, that engineers have sunk months and months and months into...
turdprincess|1 month ago
The truth is on most teams one or two people who are closest to the task have enough context to estimate, and probably only after they spent some time starting or prototyping the task.
Those people can give a reasonable estimate, in time not some strange point system.
Sometimes the estimate is wrong and that’s ok.
It’s fine to have a meeting catching everyone else up on the context but those pther people still likely don’t have enough to give an accurate estimate and shouldn’t be involved in estimation
crazygringo|1 month ago
But the fact remains that in most environments, it's extremely useful for medium-term planning and especially in surfacing high-risk features that can send people down the wrong path for a long time. And it's meant to benefit stakeholders -- the people paying the developers' salaries -- not individual developers. It's about de-risking.
And if you really have the kind of team you seem to describe where everybody only works on their specific type of task and can't even estimate anybody else's work, then that's a danger situation when they leave or get sick or whatever and nobody else can step in and everyone's blocked because the only person who can do X is gone. Usually, you should be actively getting other developers to work on these features (usually the easier/smaller ones) and involving them in the estimation.