What to do when your sprint length is X days and a task needs 2X days? In SCRUM you sacrifice quality and make the task fit into X days. And, no, it is not true that every task can be meaningfully split into smaller subtasks: sometimes finding a good split of a complex task is equivalent to solving it, and it requires quite some time and analysis. In such cases, the SCRUM approach is to come up with a simple solution that you can show during the next sprint review, and hope there is no bigger problem hiding somewhere.

This is the mantra that is repeated over and over again when I ask this question but you glossed over the fact that, as I said above, some tasks CANNOT be broken up into smaller subtasks, because finding a way to break such a problem up is the problem itself. I think what is implicit in your answer is that in SCRUM you simply don't try to solve problems that are too complex to be solved within the duration of a sprint. This is fine for me, but it should be stated clearly.

Using variable length sprints as you suggest is also fine with me, but then you do not have SCRUM any more.

I agree with your view of choosing the appropriate SDLC. Regarding "I don't think that any true scrum advocate would suggest forcing such a task into a sprint.": time-boxing and keeping a constant tempo (sprint length) are fundamental principles of SCRUM, as it was repeatedly explained to me in a recent SCRUM course held by a certified company. So, I do not think that in SCRUM you can change the duration of sprints at will. You can do this if this suits you, but then you are not doing SCRUM any more.

@Giorgio It is also a basic scrum tenet that tasks take however long they take... You never change a task's duration just to fit into an arbitrary sprint length. Personally, I've never seen a task that absolutely cannot be broken down into smaller, measurable chunks that can fit into a sprint. If the entire task takes more than a single sprint to complete, fine; but are there really no measurable and testable waypoints you can reach along the way? Those are what you complete during the course of a single sprint.

"Personally, I've never seen a task that absolutely cannot be broken down into smaller, measurable chunks that can fit into a sprint.": What if these chunks, taken alone, do not add any meaningful functionality whatsoever? Compare this to a chair: as long as you don't have all four legs in place it is useless. You can build the legs one at a time, but the chair won't stand as long as you don't have all four legs. So what are you going to present at the end of a sprint? One leg that by itself does not have any customer value.

@Giorgio Can the chunks be tested? Can they indicate some progress towards a measurable goal? So you won't have a fully functional, customer-usable feature after a single sprint... So what? You've already indicated that is impossible. What's the next best thing? Certainly not 'let's cut corners so we can say we met a deadline (by arbitrarily fitting it into one sprint)'. That's not scrum. Instead, do what chunks you can, and validate that the individual pieces work as designed, even if they aren't incorporated into the whole yet. That's what you present at the end of the sprint.

Furthermore, sometimes you have an open problem and you cannot know in advance how long it is going to take to solve it before you actually solve it. AFTER you have solved it, you can break up the solution into small implementation tasks whose duration is more predictable and schedule these tasks over one or more sprints. This has occurred to me several times.

@Eric King: I understand this (been doing SCRUM for a while already): but would the customer be interested to see unfinished functionality?

@Giorgio Sure. A customer will understand "It'll take a month or more to build the whole chair, but in two weeks we'll show you progress towards the first two legs and the back; the rest will come later". What they don't want to hear is "we're not sure how long it's going to take, and we won't have any progress to show you until we're completely done", nor do they want to hear "we couldn't fit the chair you wanted into this arbitrary two-week period, so we built this pseudo-chair for you so we'd have something to show".

"we couldn't fit the chair you wanted into this arbitrary two-week period, so we built this pseudo-chair for you so we'd have something to show": This is what I have seen way too often. Wouldn't it be more professional to just deliver the finished chair at the end of the month?

Yeah, it's definitely more professional to deliver the finished chair when it's done. But it's also professional to provide concrete feedback on progress while it's being done.

That's the whole point of the sprints... Provide a constant 'heartbeat' of feedback, so nobody's ever more than one sprint's worth of work in the dark

And what feedback you should provide should be based on useable, real work, not work that is watered-down so it can fit into a sprint

That goes against the very core nature of scrum (as it relates to Agile)

So if you can't provide an entire feature in one sprint, you must break down that feature into measurable chunks and provide regular feedback on progress. That's the entire point of sprints.

I understand this in principle but what happens in practice is that people stop trying to solve the real problems and concentrate on producing something they can show during the next sprint review. Also, often a very poor solution that you can present now is preferred to a better solution that would take longer than one sprint. Needless to say, months later you have to spend one sprint or two fixing or implementing that feature again.

I'm sure that happens, I've seen it to. But that doesn't mean that's the Scrum way. You said "In SCRUM you sacrifice quality and make the task fit into X days." I was responding to that by saying, no, that's not the Scrum way. The Scrum way is more like "Is there anything we can complete (correctly) and demonstrate by the end of this sprint? If so, that's what we'll do."

I think a lot of folks get caught up by the "potentially shippable functionality" wording. It doesn't mean "we better have something that we can deploy to the end users." It means "this is functionality that can be used by our product." The slap-dash we-gotta-get-it-done-in-two-weeks-or-else-so-let's-fake-it code distinctly does not fit the latter meaning.

I can give feedback on the leg. Tell the makers what I do and don't like about it. That is the point of the iterative nature of scrum and fail-fast methodologies

In this way, we can make changes to the legs before we have an entire chair put together, and then have to take it apart and rebuild it because we didn't get feedback soon enough.