How do you manage product documentation in scrum

If release was deferred to the final sprint as you say, then Scrum was not well implemented. Value should be released incrementally and in accordance with a Definition of Done that is fit for purpose. A good DoD will address handover and training needs for the continuation of the Product as soon as it is known that the original Development Team will be stood down.

I suggest you have a release retrospective with the client to consider these matters before moving forward with any further development.

Thanks Ian, I appreciate your answer. I think I can split this in two parts:

Part 1, my scenario is hypothetical, not a real situation

First of all, this is just an scenario, it is not a real example. I'm trying to expose a possible situation.

Second, what I meant with

March/31/2014 - Final sprint is done and the product is released to a happy client

is that the final release has been delivered, with several deliveries in between and value was added incrementally.

Third: DoD is supposed to be ok, because the client have been using the product.

So, when I said this:

Now, we're in november and client needs a whole refactor in a funcionality

I was thinking on a scenario like this: Imagine that in november, government changes a law and that has impact on the project functionality. how do you handle this?

Second part, my current reality

Now, going back to reality, I have a scrum project in course, and people is really new to scrum, and DoD is having problems. And yes, we're having retrospectives about how are we doing. however we need to move on, so:
How do you manage in scrum this problem?
Do you bring back old US and re-write them or just create new user stories?

Thanks again for your support

> Do you bring back old US and re-write them or just create new user stories? 

You don't bring forward old stories. They were placeholders for conversations that have already occurred and are now in the past. That means those stories are now finished and spent.

What you should bring forward are the acceptance criteria for those stories, preferably in the form of automated tests. Tests like this help to protect an existing product from unwarranted changes in the future. Where change is in fact warranted, you can then look *back* on the corresponding user stories for context, and write new ones that are a better fit for the new purpose.

Thank you Ian. Let me see if my conclusions are correct:

- After the final release, all the product documentation is written under the user stories and the acceptance criteria
- Every thing you may need review in order to analyze how and why something is working in certain way, should be written in the user stories and the corresponding acceptance criteria for each one of them.
- Every user story is identified in the begining (early stages) and you go deep into it when you plan it for a specific sprint.
- Acceptance criteria should be identified and described for every user story usually when you make a sprint planning

Fpr me it just sounds like you do not have any automated tests which will validate the new extensions agains the old features.
I would recommend you first to make sure you have automated tests implemented before you go ahead with the project. this will guarantee you that the available features will still work.

There is no chance to have automated test cases, it is a technical issue and it is not possible.

Really no chance at all ?
How can you hope to deliver shippable increment every sprint if all your tests are manual ?

It is a technical issue, no way to automate.
And, as scrum is supposed to work on changing requirements environments, this should not be a problem, what do you think?

In Scrum each increment must by definition include all previous increments. Acceptance criteria associated with requirements implemented in prior increments may therefore be impacted by future sprints. This implies that some form of regression testing will be necessary if the quality of each cumulative deliverable is to be asserted...and that is a tricky thing to scale manually.