Yes, you should update the release plan both to reflect what actually happened in completed sprints but also to incorporate any new information which helps with planning future sprints.
How to account for stories which end up spanning multiple sprints
There has been some confusion on how to account for a task which is worked on over multiple sprints. The important points to remember are that you want to both know when the story met the definition of done, but you also want to be able to accurately observe the team’s velocity over time. In addition you want to observe the accuracy of your estimates so that you can improve them in the future.
In the following example, task 76 is worked on over two sprints (other tasks are not included for the sake of simplicity). It was originally estimated at 3 points and in the earlier sprint, 4 were completed. It was then re-estimated as a total of 5 (1 more to be done). In the end the size was 8.
This shows how the release plan was changed to reflect new information.
At the start of sprint 9:
[#]
Sprint # User Stories Estimated Size Real Size
9 76 3
10 102 1
[/#]
At the start of sprint 10:
[#]
Sprint # User Stories Estimated Size Real Size
9 76 (4) 3 4
10 76 (1) 1
[/#]
At the start of sprint 11:
[#]
Sprint # User Stories Estimated Size Real Size
9 76 (4) 3 4
10 76 (4) 1 4
[/#]
In the Feature Archive the task is attributed to the sprint when it is done (using the specific meaning of ‘done’). Here I’ve chosen to reflect both estimates which were made, both the original and the planning which was done as part of sprint 10, in order to learn from mistakes in estimating.
[#]
Release Sprint Estimated Size Real Size
76 2 10 3 (+2) 8
[/#]
Dear all,
some of us were wondering about the final release deliverables as described in slide deck 01A page 21. Could you give us some further details about the quality criteria of each of these deliverables?
Thanks,
Larissa
Were there any artifacts or aspects of the product in particular that you wanted to know about? From my weekly feedback of the planning documents I expect that there is already a fairly good understanding of the planning artifacts. User documentation should show a non-technical user how to use the software. You’ve probably encountered both good and bad guides online, so think of guides you’ve liked, which were clearly structured.
As for the final software product, the working criteria should be obvious: a fresh installation of the software should work (perhaps with minimal configuration), there should not be unexplained crashes or broken pages. The technical documentation should cover both installation (including information on configuration, dependencies, hardware requirements) of the product and an overview of the architecture which would allow someone to develop the product further. The code repository should not have a clearly organized directory structure and not contain files which are not meant to be checked in.
Interesting 
Indeed we’ve seen different types of documentation. Among all we saw (especially when it comes to documentation for non-technical target groups), video tutorials have been the most useful ones. Obviously one can also link text with screenshots in a „classical“ document, however usually the most appealing explanation is a personal demonstration and a demo video is what comes closest to that. Besides, we believe that a written documentation for an App is not very usual.
Are we required to deliver a text-based documentation or are we free to provide a video if we believe it adds more value to our delivered release?
Oops!
Obviously, you should have a clearly organized directory structure.
I think it is best if Dirk answers this. In my opinion, video can be a great supplement, but does not replace written documentation. This is because video can only really be accessed sequentially, which makes it great for an overview, but frustrating if you know the basics and are looking for help on a specific topic. In written documentation, even if it isn’t grouped by topic, I can search for a specific term and jump to the relevant text.
Is the deadline for the documentation also Thursday night? If so, do we have to upload them on github as well?
You should try to have everything in place before the demo, but certainly it should all be done by Thursday night. Documentation which helps someone understand the project should be part of the repository. The exception would be if you produce specific documentation for the industry partner which contains proprietary information that you cannot make public. But since the software is open source, in general you should make it possible for someone to pick it up and start using it even after you finish the class.
Final release tag
Today I was asked about tagging of the final release. What you presented today should already bear the sprint_xx_release_candidate tag. For the final release, as with the midterm release, the usual sprint_xx_release tag is replaced with the final release tag (as found in the slides and the weekly checklist): product_release_v2. This is a non-optional release.
Final deliverable: individual retrospective
Today I was also asked about the final deliverable, the personal retrospective. Today in the demo you presented your team reflection. Prof. Riehle wrote about the personal retrospective in his mail from 18.06.2014:
Specifically, slide 20 in the slides 01B describe the requirements.
For those of you who are stuck on what to include in your retrospective, here are some questions to consider. You don’t need to limit yourself to them but they could provide a starting point.
Team
What tools or practices contributed to a good team relationship?
What tools or practices contributed to a bad team relationship?
What worked well in my team?
What didn’t work well in my team?
Self
What did I learn from the official aspects of this course?
What did I learn from the unofficial aspects (teammates, challenges) of this course?
What did I do well?
What could I have done better?
Project and Process
How effective was the Scrum process for structuring the work?
How satisfied was I with the project my team delivered?