Skip to main content

New stories that affect old ones

Last post 08:41 am July 1, 2013 by Alice Menezes
10 replies
05:28 am June 20, 2013

What should happen when new stories affects previously implemented ones?

For example, an entry has a registered on date (time stamp) which is automatically set when it is committed. Further stories allow you to search for these entries based upon the date it was committed. Correctly the development team search against the registered on date to return the entries as the registered on date and committed date is the same.

A later story was introduced to allow certain entries to have the registered on date manually inputted for historical entries. The impact of this means that if I was to search for a historical entry that I created yesterday, based on how the search was developed, I would need to know the historical date as apposed to the committed date which is the acceptance criteria for the search story.

How should this be considered? A development task to go back and alter the search query?

Thoughts would be appreciated.


05:56 am June 20, 2013

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.


06:06 am June 20, 2013

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?


06:59 am June 20, 2013

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.


09:03 am June 20, 2013

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.


09:45 am June 20, 2013

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.


09:56 am June 20, 2013

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.


10:14 am June 20, 2013

"...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.


10:19 am June 20, 2013

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


11:54 am June 20, 2013

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.


08:41 am July 1, 2013

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

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


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.