[matthewhartmans]

I think this is where a 'spike' solves your problem.

By creating a spike, you can do some initial investigation into how the code is written, what's involved, how long it will take, etc.

Once you have completed your spike, you can come back to the original piece of work and give a better estimate based on your findings.

[eropple]

In the perfectly spherical Agile world, yes.

In practice, for anything that's new, your project devolves into a set of spikes for development because your time-boxed investigation leaves unknown unknowns everywhere. Which is fine in that perfectly spherical Agile world, but it makes less-than-perfectly-spherical stakeholders very upset that they are not getting to use the Agile stick to beat over their developers' heads, as they have been trained to do.

[dymk]

Maybe a spike takes a week. Maybe a spike takes an hour. I can't estimate that.

Which would be fine, but then management or the PM expects me to loop back around when a spike is complete. I'd rather just continue engineering a solution when I'm done investigating, which is the natural progression of things.

I'd rather treat {get requirements, investigate, implement, debug, deploy} as a single atomic task, rather than splitting it across N meetings for planning the sprint, planning the spike, meeting with the PM for more requirements they forgot to put in the user story, describing it at a retrospective, showing it at a demo.

Now I know somebody will say "But that's now how agile works!". Well, we have a few agile "coaches" that were embedded in our teams who would disagree.

[nprateem]

What are you doing in a spike? If you can't work out after a day the rough complexity of the task (bearing in mind you should be working on a small deliverable) there's something seriously wrong. You're not meant to be doing the work in the spike. If your research spike shows that it could be a can of worms, then the outcome of it should be another ticket for a proof-of-concept for another sprint, but with specific goals (e.g. "get a POC working that does X, Y & Z").

[theptip]

> Maybe a spike takes a week. Maybe a spike takes an hour. I can't estimate that.

Timebox it then! If you think the spike is going to take a day, and it turns out you'd need a week to even get the prototype working, then that's a successful spike -- you dramatically increased the lower bound on your estimate.

(Sadly by the asymmetry of estimation it seldom happens that you think it's going to take 5d and it ends up taking just 1d).

[matwood]

> Which would be fine, but then management or the PM expects me to loop back around when a spike is complete. I'd rather just continue engineering a solution when I'm done investigating, which is the natural progression of things.

This has nothing to do with agile. Feature X may sound great if it takes 2 weeks, but if it takes 6 months I may not consider it worthwhile right now. Engineering is not just about building something, but dealing with constraints like time and cost.

[omikun]

Sure, that works for adding something without a lot of connections. But if you are tasked to add a feature that has many hooks into a complex system (plus additional unforseen hooks that you won't realize is needed until you implement it), it's basically a stab in the dark. You can guess a time, then triple it.