Is aiming for "done" within a sprint harmful?

Many of my clients new to Scrum often try to fit everything into a 2 week cycle but find that all the work required doesn't fit! Often the definition of done is too long to get something to "done":

One response to this problem is to blame a lack of upfront analysis, and suggest it would be easier to commit to getting to done if more analysis was done up front, and while we are doing that perhaps testing could be allowed to spill into the following sprint:

Unfortunately this suggestion, to do analysis one sprint ahead and testing one sprint behind, leads to long end to end lead times (six weeks in the above example); It also reduces our planning agility, giving us only one chance to implement and provides limited opportunities to react to feedback or to learn as we go.

At this point I usually advise teams to start by looking at making the stories smaller by splitting stories up so that all activities do fit in the sprint. For new teams this can be difficult especially if we have not done any analysis to meaningfully split the story and does not really address the "one chance to get it right" problem.

Consider splitting the work into three iterations: one to learn, one to get it working, and one to polish for release, with all team roles and activities inculding development, testing and review happening for each iteration. At each point collecting feedback and refining the plan:

The first iteration of the story (v1 above) could start from nothing: analyst, developer and tester could working together through the sprint to discover what is possible, what is useful and how we might build, test and deliver it.  I'd suggest the team aim to demonstrate some working software at this stage, even if only a prototype of part of the story.  In v2 we might aim for a fully implemented and tested version perhaps with some rough edges, and in v3 we might aim for a fully production ready operational version. In this way we are deliberately not getting the story to "done" each sprint, instead emphasising learning and iteration over completeness.

Based on this chain of thinking I would say too much emphasis on getting to "done" (or getting it "right") can get in the way of our ability to learn iteratively and isn't learning fast the reason we are using Scrum in the first place?  I'm suggesting that creating multi iteration stories could be a useful practice in this context. If all else fails you can always increase your sprint length: a 3 or 4 week cycle is still much better than 6 weeks!

This is an early draft post, feedback welcome.