Can I exclude certain elements of an item from showing as a revision in a review?

Options
[Deleted User]
[Deleted User] Posts: 6
edited September 2016 in
I would like some changes NOT to show up in the "items updated" link after a revision and just show those items as updated if the title/description changed. Such as the status of a review item - the status may change and reviewers do not need to be aware of this change.  They are most interested in whether the requirement itself has changed.

Comments

  • [Deleted User]
    [Deleted User] Posts: 911
    edited June 2016
    Options
    Hi Pam! Thanks for joining the community.

    Can you clarify your use case a little bit? When you're undergoing the review process, do you need to retain all items in the review until the end? I ask because the best workaround for the reviewers-review-only-whats-changed scenario is by creating reviews from advanced search/filters, and as an example have those items drilled down to only a status such as "needs review" and items that are finalized are then removed from the next revision because the filter would have fewer results.

    But if your reviewing scenario is different, then removing items won't work. e.g., do you need to keep all of the items in a review from version 1 forward until it's signed off on? If this is the case, I'd like to change your question to an Idea so that our Product team can consider it as such. At this point there isn't a way to affect the "items updated" filter in the Review Center to exclude certain fields from triggering this. (As it is now, it's based on the version, which all fields affect.)
  • [Deleted User]
    [Deleted User] Posts: 6
    edited September 2016
    Options
    We include all items for a feature in a review - we tried including those such as "needs review" and our teams (dev, archtecture, test, etc.) wanted to see the full requirements so they could accurately evaluate the completeness of the product plan/end-result.  We currently mark those as new or enhanced with a different status, product release and release type.  Users can see the product release and release type within the review window so they can tell what is new, enhancements, etc and which release it was completed (current) or is planned for (new, enhancement).   For instance, here is how we would indicate what the new or changed requirements are in the review.

    Current requirements:
    Status = Completed
    Release Type = Baseline
    Version = 5.2.2

    New requirements:
    Status = Draft
    Release Type = New
    Version = 5.3.0 (or whatever version)

    Changed requirements:
    Status = Draft
    Release Type = Enhancement
    Version = 5.3.0 (or whatever version)

    Once a review is completed, all "Draft" requirements are changed to "Approved" and when development is complete, they are then updated to "Completed".  Changing a release type or version may be significant to the reviewer but the status, whether it is approved or draft, is not.  This is because a review is not formally closed until all items are reconciled/approved.  We could hold it open until the product manager updates all the statuses and then publish a revision but when we change them to completed after build, they will be again show up as "updated items".   

    I've read several other posts where other community participants use a similar approval or reference review process (not just for "needs review").  Currently we export a Word document but are trying to move away from that and refer all users back to the feature review to see the most recent feature requirements so it important.

    We would also like to use the reviews as our formal change process - any updates/clarifications to a feature would be updated in Jama and a new revision is published so the SRB can evaluate and approve the changes BUT when I publish that next revision after the status is change to approved or completed, ALL items will appear in the "updated items" link and the user will have to view each one to see what the change is when they are really just concerned about those with a change in the Name/Description.  So it would be VERY helpful to be able to set whether an item type field triggers a revision in the configuration of the item just like we are able to set whether an item type field triggers a suspect link or sync option.  I hope that helps you understand.  Let me know how else I can help.
  • [Deleted User]
    [Deleted User] Posts: 911
    edited June 2016
    Options
    Thanks, Pam, for taking the time to clarify your process. It's helpful to understand why you need to have this ability.
    I'll ask around to see if anyone has any workarounds for the time being.
  • [Deleted User]
    [Deleted User] Posts: 160
    edited March 2016
    Options
    Pam,

    While it is not currently possible to turn off the versioning of a specific field, you can turn off the versioning for all items in a project. This would allow you to make status changes without causing the Review to be flagged as changed.

    To perform this, complete your review as you have stated above whilst completing all updates as the moderator and publishing a final revision. Prior to transitioning, or updating the status, Go into the project configuration and turn off versioning. 

    image
    By unchecking this box, Jama will not create a new version number for changed projects. Now Batch transition or update the item's status. Once you have updated the status, you can return to the configuration and turn the versioning back on.

    While not perfect, this will allow you to continue using Review center for your Change Management process. 
  • [Deleted User]
    [Deleted User] Posts: 161
    edited September 2016
    Options
    @Dennis, thanks for sharing this tip. swoo
  • [Deleted User]
    [Deleted User] Posts: 6
    edited April 2016
    Options
    Thanks @Dennis.  I agree this could work temporarily but really would rather not rely on user error in the event one of the product managers forgot to turn versioning back on.  I am trying to convince the 'powers-that-be' to move from an export Word doc FDD process and, if the PM forgot to turn versioning back on, we would lose "updated items' altogether. Unfortunately, if that were the case, I could see a quick return to the more complicated cumbersome process.

    I have been thinking about using a workflow to change Statuses to 'Completed' when the Review is 'Finalized' but it looks the change would apply to all Statuses, not just those designated as 'Draft'.  I would not want to change those that are designated as 'Completed' (in prior release) back to 'Approved'.  

    It might help to leave the review open after reconciliation/approval, do the Batch transition - 'Draft' to 'Approved' - and then publish a final revision to baseline the items before closing the review.  Hmmm.  Still thinking on it.  I appreciate the feedback!

Categories