As you say, RTC allows you to proceed in either way. So this becomes more like a question regarding your Scrum process and without knowing more about your team, it's hard to come up with an advice. I do not think that there is a general "best practice" available, but I do have some thoughts on this topic.

I think the right approach depends on your situation: Are you at the beginning of your sprint where you just "assume" that you have 3 spare days, or are you approaching the end and you "know" that you have spare time? How many developers are affected? Is the team still fresh and burning for action or would some spare time be refreshing for them?
Because you have tasks already in your PB, I assume that you use some lookahead planning where stories are broken down into tasks already before the iteration planning meeting. How long ago did you break down the story that you are now looking at? Could the story be split? Are all of the story's tasks tightly coupled with this particular story or can they also be handled in the context of other stories?

My first choice would be leave the spare time, allow the team to use the time for some research regarding future stories, some refactoring, or the like. Maybe some other stories turn out to take more time anyway and the assumed spare time is gone.

Otherwise, create an artificial extra story that somehow covers the preparation for the "real" story that is covered in a subsequent iteration then. Just assign one or two smaller tasks to this story and then assign this story to the iteration. Leave the rest in the PB. This has the advantage that you can even think about the value and acceptance criteria for this preparation story, so although it might not lead to running code, there might be even something that is "done" at the end of the iteration.

I personally would not assign tasks to an iteration if the rest of the time stories are assigned. Nor would I intentionally assign too much work to an iteration because this is often frustrating for the team and dilutes their commitment (at least to my experience). Some time ago I ran a project where we always assigned tasks to iterations and left the stories in the PB. This was with RTC 1.0 and our stories were too big anyway. This worked well for this team and project, but today (using RTC 2.0) I do not do that any more.

Let me know what you think about that. I would be happy to discuss this further.

- Thomas

I'd be inclined not to schedule a story for an iteration when I know I
won't be completing that story for the iteration, because it can foster
the attitude that it's OK to not complete things scheduled for an
iteration (as displayed in various burndown charts not going to zero).

So I'd either create a sub-story (if there logically is one) that
describes work that can be achieved in the current iteration, or if not,
just leave the story in the future iteration and move the tasks to the
current iteration.

The advantage of creating the sub-story is that it keeps your velocity
more accurate (otherwise your velocity in the current iteration will
appear to be below what it actually was, while your velocity in the
future iteration will appear to be more than what it actually was).

Cheers,
Geoff

daviesd wrote:

Hi guys

We've been using RTC for around 8 months now and are finding it to be
good - thanks for all of your hard work.

I have a question regarding stories and tasks though which we can't
agree on which way to go.

The scenerio is:

I have a story that has 3 tasks under it. The tasks are each 2 days
work. In my first sprint I have 3 spare days at the end which I would
like to keep the developers busy for so I would like to give them this
story too ( knowing full well they won't complete it ).
Now, do I move the story and all its tasks into Sprint 1 from the
Product backlog ( I like the new backlog type BTW ) or do I just move
the two tasks and leave the main story in the backlog. We can pros and
cons for both scenerios but can't decide on the 'best'

Any ideas?

Many thanks and a Happy New Year to you all.

David

Yes, a "sub-story" is just a story that has another story as its parent.

Cheers,
Geoff

daviesd wrote:

Thanks for the replies guys...

So what I am taking from this so far is that we should move the
stories from the backlog to the iterations and that ideally they
should of the size so that they can be completed in each iteration.

When you talk of sub-stories are these just a story that has a story
for its parent or is there something else??

cheers

David