One of our teams that is undergoing the transformation towards Scrum came across an interesting situation:

• A Sprint, and all its stories have completed all development, testing, acceptance, sign-off, product owner acceptance, etc…
• One Story in the Sprint cannot be released with the Release – because there’s a dependency on the business to have completed end-user training, which the business needs a few more weeks to do.

So how would you handle this?

• Approach 1: Story does not meet the definition of done.
• The training item should have been a task for the story in order to satisfy the goal of potentially shippable.
• Since a dependency/condition to being shippable was not met, it’s not done.
• Thus the Story would be pulled out of the Sprint and moved back into the backlog or into the next Sprint if it still has value and released on the next Release.
• It would cause a dip in points and artificially drop the velocity for that Sprint (all the work by the team was satisfied, there’s no more work to do), but that dip is ok as it points out an issue that prevented value from being delivered.

• Approach 2: Business issues should not affect velocity. 
• The team completed all work needed to create releasable code – the velocity should be recognized.
• If you keep the Story in the Sprint, it would delay the Release… for weeks. Which is the prerogative of the business. However it’s not a few days of delay, it would bump up against the timing of the subsequent release which goes against the mantra of continuous value… value is not created until you release it.
• Alternatively, you could ‘complete’ the story to record the velocity, but create a placeholder in another Sprint to recognize it actually being released. Or replace a faux/filler story just for velocity tracking purposes, and move the real story into the real Sprint/Release that it’ll get released in.