Forums

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. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

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.

New stories that affect old ones
Last Post 01 Jul 2013 03:41 AM by Alice Menezes. 10 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Paul Smith
New Member
New Member
Posts:22
Paul Smith

--
20 Jun 2013 12:28 AM
    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.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1575
    Ian Mitchell

    --
    20 Jun 2013 12:56 AM
    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.
    Paul Smith
    New Member
    New Member
    Posts:22
    Paul Smith

    --
    20 Jun 2013 01:06 AM
    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?
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1575
    Ian Mitchell

    --
    20 Jun 2013 01:59 AM
    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.
    Paul Smith
    New Member
    New Member
    Posts:22
    Paul Smith

    --
    20 Jun 2013 04:03 AM
    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.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1575
    Ian Mitchell

    --
    20 Jun 2013 04:45 AM
    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.
    Paul Smith
    New Member
    New Member
    Posts:22
    Paul Smith

    --
    20 Jun 2013 04:56 AM
    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.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1575
    Ian Mitchell

    --
    20 Jun 2013 05:14 AM
    "...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.
    Paul Smith
    New Member
    New Member
    Posts:22
    Paul Smith

    --
    20 Jun 2013 05:19 AM
    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
    Randy Ho
    New Member
    New Member
    Posts:47
    Randy Ho

    --
    20 Jun 2013 06:54 AM
    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.

    Alice Menezes
    New Member
    New Member
    Posts:39
    Alice Menezes

    --
    01 Jul 2013 03:41 AM
    Brilliant explanation by randyh. Was lost throughout the thread and then finally got what it meant.

    ___________
    http://www.agiledistributed.com/tes...Agile.html
    You are not authorized to post a reply.


    Feedback