zlacker

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.

>>crazyg+(OP)
How does it help with medium-term planning when it's just pointing tasks in one sprint?

>>impute+I2
Because you often estimate something like three or four times as many tasks as actually get included in the sprint. You can't possibly know in advance which features will actually wind up in the sprint until you've considered all the possible candidates. You estimate, then the PM confers with stakeholders to prioritize what's actually most important and figure out the "puzzle" of which pieces add up to a coherent sprint, and then work starts.

To the developer, it seems like short-term sprint planning. But to the PM and stakeholders, it's very much medium-term planning because they're picking tasks for this sprint in light of what they also estimate the following couple sprints will look like (given current information, which is always going to change).

It's not as bad as it sounds, because when you're re-estimating something you already estimated in the past 2 planning pokers, it's usually pretty quick. You're just seeing if the previous estimate needs to be revised based on what the team has learned since. Most time is usually spent on newly proposed features, or features that have significantly changed or been split up.

>>crazyg+(OP)
> The same way nobody finds writing tests or documentation fun

I'm not sure if it's the fun category, but at least they are useful and because of that, satisfying to do. In fact when I finish a solid suite of tests or good, clear documentation, I find it very satisfying. I can't say the same for poker/estimation. I've found to be them a complete waste of time in every job I've had and therefore soul sucking.

> 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

you're conflating the ability to estimate accurately with the ability to implement.

Just because I can't estimate a task accurately doesn't mean I can't do it.

>>theone+Pb
> you're conflating the ability to estimate accurately with the ability to implement.

> Just because I can't estimate a task accurately doesn't mean I can't do it.

Most programmers could ultimately do anything... if given enough time.

But if they're going to do it professionally, you expect them to have some prior experience so they can do it somewhat efficiently. And if they have that experience, they should be able to estimate.

So yes, being able to estimate and being able to do (with reasonable professional efficiency), do tend to correlate, of course.