New stories that affect old ones

Since the original story will have met its Acceptance Criteria and the Definition of Done, a new story will need to be written, which you appear to have produced. I suggest that's the story to mark a new task against.

You shouldn't bring a "done" story back from the grave and then try to mark further tasks against it.

Yes the original story did pass but the new story created just says 'As a user I want to manually input registered on date so that I can add historical entries' so mentions nothing to do with the search.

Who should be considering old completed stories when a new one impacts on it? PO, dev team?

Neither user story has to mention anything to do with the search. Searching is best considered in the second part of Sprint Planning, which is when tasks are commonly elicited. It's those tasks which should get into the nitty-gritty of searching.

It may well be the case that the Product Owner doesn't care about searching, and he or she may therefore be critical about the team's conflation of registered & committed dates, and the technical debt this decision has incurred. However, the team has a responsibility to deliver minimum viable product as quickly as possible (which you appear to have done), and to pay off the debt as soon as it becomes apparent instead of compounding it (which you intend to do now).

It is perfectly reasonable to absorb the cost of this in a new user story. However, it would not be reasonable to "consider the impact" on old stories. There is no impact. There may be an impact on their products, such as BDD tests that circumscribe their acceptance criteria, but this should be addressed by new stories that consider the system as-is and the work remaining. The old stories are done, spent, finished, over with. Move on.

So are stories only valid for the sprint that they were developed in?

If this new story allowing manual input of dates come into a sprint several sprints after the search has been developed, the acceptance criteria for the search is not not met because we can not search for historical entries on the date they were committed.

Yes, the short answer is that stories are only "valid" for the sprint they were developed in. Stories are a placeholder for a conversation. Those conversations happened during the sprint in which the story was actioned. The timebox is over, and the conversation placeholders within it are history.

As regards your second point: if the acceptance criteria of the original user story have not been met, then the story is not done, never was, and should not have passed.

On the other hand, if it is new acceptance criteria that have been identified, then they will relate to a new story - i.e. a new placeholder for one or more future conversations. It might resemble an earlier such placeholder very closely, but it will be a new story nonetheless.

The original acceptance criteria was met so that is fine, however a future story now has impact because of the way it was developed. Nothing to do with stories altering the acceptance criteria.

The acceptance criteria of the search story is 'must be able to search via committed date'. Because when this was developed, registered on date and committed date were always the same, the development team searched against registered on date.

Once the story came along to be able to manually input the registered on date, this effectively broke the previously implemented search story. I could commit an entry today with a registered on date of two weeks ago and would only be able to find that result by searching the registered on date which is not what the original acceptance criteria said for search.

"...this effectively broke the previously implemented search story"

No, the story didn't break. The story met its acceptance criteria and the Definition of Done by the end of the timebox. The conversations it represented during that Sprint didn't break, and the placeholder itself didn't break. None of these things can travel forward out of the past and into a future timebox where they become undone and broken. What will "break" - hopefully - are certain products of that story, such as regression tests that were derived from its acceptance criteria.

Those acceptance tests will now need to change - just as the system itself needs to change - to accommodate new conversations and new stories that are yet to happen. That is achieved by having new conversations and new stories to represent them. The old stories are over, archived off, in the past, finished.

My explanation isn't that great. I know it doesn't break the story as that is done and finished.

I see that this new story should strike up the conversations and a task should be created to go back and amend things where required to do so.

Thanks for your help

Perhaps an example would help you.

Sprint 1 Story - "Would like to store red balls in the box"

Development: Team writes accetance tests that verifies that box only stores red balls. Team builds a box that stores only red balls.

Then we get to sprint 2 and the customer has a different request

Customer: "I want to store blue balls in the box"

The development team should clarify this story with this customer during grooming. Does the box need to store blue balls AND red balls? or should the box store blue balls INSTEAD of red balls?

Here are 2 ways the new story could impact the software and how the team adjusts.

Scenario A (Adding to existing functionality)

Sprint 2 Story - "Would like to store blue balls AND red balls in the box"

Development: Allow box to accept blue balls. Red ball automated tests from Sprint 1 should not fail.

Scenario B (Changing existing functionality)

Sprint 2 Story - "Would like to store blue balls INSTEAD of red ball in the box"

Development: Change acceptance tests for red balls to blue balls. Change box to store only blue balls. Development team does not go back to sprint #1 story for this. They simply change the software and the acceptance tests.

Brilliant explanation by randyh. Was lost throughout the thread and then finally got what it meant.

___________
http://www.agiledistributed.com/testingDistributedAgile.html