How should user stories describing changes be written?
Should a user story that describes changes in an existing feature summarize what is new and what existing functionality should remain, or should user stories define the finished product? If the answer is the latter, that raises the question, "who do user stories serve if not the whole of a cross-functional team?"
Say we have an existing home page, packed full of functionality. One section of that page is a little out of date, so it needs to be updated. Nothing else will change on that page.
The user story might be something like this:
As a logged in user I want to see the latest terms and conditions so that I understand how I can use my account
The user story only describes the changes that are to be made, not the whole funtionality of the home page. A stakeholder reading the story on the backlog would get a good idea of why the change was being made and the value it delivered. That is the principle behind user stories, they are easily understood by somebody non-technical.