Discuss Agilepublic

Community Agile Discussions

A variety of ongoing discussions about Agile development

This is a public Discussion Area  publicRSS

Thread

    What's the best way to document the removal of a user...
    Thread posted 04/24/09 by Justin Stockton , tagged Project Management
    17146 Views, 3 Comments
    Title:
    What's the best way to document the removal of a user story/feature?
    Content:

    We recently started using Rally and user stories to document the rewrite of an existing application. The developers started by going through the existing site and writing user stories for all of the existing functionality so that we would know what we had to duplicate. Once we we were done recreating this functionality we turned the app over to the PO who discovered that one feature we had recreated they no longer wanted.

    Obviously we made a few mistakes by not involving the PO in the creation of the stories and especially in assuming that all existing features needed to be ported. If we had vetted the final list with the PO prior to development, I wouldn't be asking this question.

    So what I'm wondering is, now that we've developed this feature and the PO no longer wants that feature exposed, how should we document that? Would you,

    • just delete the story, it's tasks and test cases?
    • enter a test case for not displaying that feature on the screen? If so, what about the any other test cases associated with the story, would you remove them or rename them in such a way that they no longer matter?

    I'm curious if others have come across a similar situation and what did they do?

    Thanks,

    - Justin

    Comments

    • posted 04/28/09 by Chris Browne

      If the feature has already been developed and the story documenting the original feature has been accepted I would leave them along with any associated tasks. This gives you visibility into work you actually performed by adding the feature, now you want to track the effort you are going to put towards removing it. You could now create a story with related tasks and test cases to cover the removal of the feature. You would also want to delete the test cases from the original story because they no longer apply, you want to test that the feature is no longer available.

      Reply to this Comment

      Attach File...

    • posted 04/28/09 by Jean Tabaka

      Hi Justin,

      You already answered the #1 issue with your dilemma: lack of Product Owner engagement in defining the re-write. A release planning meeting at the start of this effort might have drawn this out from beginning. Also, was the Product Owner involved in each iteration planning meeting to see what the team would be working on. And did the Product Owner attend demos to see what features the team had completed during the iteration? I ask these latter questions because, even if the delivery team had made the first pass at creating all the stories for the re-write, the Product Owner should have been prioritizing them and deleting any that they didn't want as the iterations progressed.

      Now that the product has items in it that the Product Owner doesn't want, here is what I suggest:

      • engage the Product Owner
      • have the Product Owner list all the unwanted features in rank order
      • create these as items in the backlog because they will define what the team commits to doing in future iterations
      • for subsequent iteration planning meetings, pick through these ranked items one-by-one, WITH THE PRODUCT OWNER ENGAGED, defining the work it will take to remove these ranked items and the tests that must accompany that work to ensure it is DONE and didn't break anything when it was removed
      • make sure the Product Owner agrees to accept items one-by-one when they have been successfully removed
      • in the description field of each item, be sure to capture that this item was placed into the backlog due to a request from the Product Owner to remove the functionality

      All of this will track the work, the cost, the testing, and the DONENESS of this extraction process.

      And, I sure hope your Product Owner learned in a retrospective what caused the dilemma. And, at the end of this release with the extracted features, I hope you hold another retrospective that addresses what the impact was on the product, the team, the Product Owner, and your customers, and how your processes and team agreements can prevent this in the future.

      To be VERY VERY clear, DO NOT REMOVE the stories that you completed in delivering the unwanted functionality. They were requested items and had tests built against them. You must now create new items and new tasks because of new requests ("Remove the features.") from the Product Owner.

      Hope this helps! And, best of luck to you and your team.

      Reply to this Comment

      Attach File...

      • posted 04/28/09 by Justin Stockton

        Jean,

        Yeah, we're on track now. The issue we had with not including the PO was just a first iteration mistake. This issue did come up during the iteration's retrospective and we've since taken the appropriate steps to include the PO from here on out.

        - Justin

        Reply to this Comment

        Attach File...