I'd like to be able to edit closed backlog items without having to re-open sprints/backlog items, then editing, then closing. the reason for this is that I would like to backfill a lot of closed items with Feature Group functionality which I have just started using for reporting purposes
by: James G. | over a year ago | Product Planning
Comments
I agree... opening an old item and sprint to make a change is painful. Maybe only admins can do this?
We are looking for such a solution for now almost 9 months and I can tell you it is almost impossible via the API!
it is painful. Sounds like we all have been there. I know we must risk allowing this to be done while closed. Maybe limit it to a key security level (Administrator?).
And, since VersionOne doesn't track the Close Date (so only have the Last Modified Date), reopening an item messes up metrics. Would be good for VersionOne to track Close Date in a separate field, and also be able to edit certain fields without reopening the item & the sprint that has probably been closed also.
I completely agree with these concerns. I lose a lot of time and data quality with the current limitations ingrained into Version One.
TOTALLY agree. We have created a bidirectional bridge and if someone updates the external system while someone else has closed a story and associated Epic, we have to walk the dependencies trying to reactive, update and re-close the items.
How about allowing only certain actions after an item is closed? We almost always find that items have landed in the wrong project, and we have to reopen EVERYTHING to move it to the correct project, but nothing else really changes about it. Please allow movement to different projects at the least.
I would love to be able to add a dependency to a closed story without having to reopen, especially if the dependency is buried in a closed Epic or Project Release.
I don't think we are going to get anywhere with this. I brought this item up with one of their Agile Coaches during a consultation meeting because this was really bugging us and getting in the way. (think about doing release notes at the end of the release, we have to go open all the sprints and stories for any story that needs to be flagged as needing release notes if we missed it the first time around)
Anyway, the agile coach said that it wouldn't happen because V1's view of closing a story is that it is equivalent to ripping up the paper sticky on a physical board after the sprint is over. So once it is closed they consider it to not really exist.
That view alone caused us to reconsider v1.
I'm currently trying out the system, and I have to say that this is really a major pain. I think it's good that it's trying to enforce a process but there are many good reasons why people may want to change a closed story. Just having a warning that a user could bypass should be enough... I think even non-admins should be able to do this.
In my situation, we had a lot of closed items that we were originally thinking would go to a release... and eventually reconsidered and decided to move them to a different release. This is very painful to do for items that were closed and done in prior sprints.
I've worked with products from v1 competitors that also support agile and scrum and don't impose this restriction.
This is desperately needed in the API at a minimum. Since syncing of items from one tool to another tool may lag behind when the item is closed in Version One. Lacking a security level that will allow modifying a closed item causes unnecessary errors in integration tools.
+1 We're trying to start using the Priority and maybe Feature Group fields, and the current process to "fix" closed backlog items is a huge waste of time.
Or at least allow item to be reopened and editable when a linked item (sprint for example) is closed.
We just ran into this issue AGAIN today. We had to open defects to move them to the next version of a project, and it changed the CLOSED dates when we did that. This is getting to be a real productivity issue, and it throws off ALL the associated scorecards!
I want to add a Portfolio item to a new Project so we can use the planning room. Half of the Stories in the Portfolio are complete/closed so they are not showing up on the Planning Room cards (without me re-opening all the Stories individually and assigning them to that project).
Please allow admins to edit stories that have been closed without needing to reopen them. Right now, I need to run metrics on a project that I can only do by updating the backlog group and this should not require that I need to be reopened.
HOW can you write release notes without this? SO Frustrating! FIX IT! Please and thank you =)
yes, reopening all the artifacts necessary to make a minor change to a closed story is unmanageable. Even if we would be able to just edit certain fields on a closed item (ie, comments and a few other) that do not affect the metrics.
Just because an item is closed, does not meet that all attributes in it are correct. Today you have to reopen closed items and change attributes and this is a huge time suck and one of the reason that we will seriously be considering leaving VersionOne next year. Please fix this, it is more than annoying, it is a deal breaker.
Being able to edit closed items would be a very big help. Of course, you would want to be able to limit the editing of these fields such that not anyone can do it. And it would probably be a good idea to capture the fact that the item was edited after it was closed.
It would be very helpful if V1 would comment on this. There are ideas with many fewer votes that are in planning stages.
Editing features in closed PIs without having to re-open the PI would be very helpful.
Version One needs this feature! I recently took over for a Product Owner and needed to create my own releases as many did not make it to Prod, and each Sprint and Story needed to be re-opened. How many votes does it take for an idea to be implemented?
Another problem we encounter with this limitation is when assigning completed work to an Idea, which only works with open backlog items. Only this morning I had a customer log an idea that I knew we'd just delivered with our latest release, but because the backlog item was closed, I couldn't assign it to the Idea.
I total agree with everyone's posts. The ability to add an upstream dependency without having to reopen a backlog item or epic is something that happens to us all the time. I just spent 3 hours reopening stories so I could add them as a dependency to a current story. So not Agile! We use dependencies in a "deploy" story to link back to development and configuration stories. Having the dependencies in a single story make it easy to match automated regression test sets to the deployment. Even though all the stories are in a "release" we have other items like roll back plans, Last Responsible Moment checklists, etc. that do not need regression tests.
This is definitely a priority VersionOne needs to look at. As a tool administrator, I need a capability that allows authorized users to edit stories/epics/features that were previously closed without re-opening them. The current method requires re-opening Sprints, portfolio items, backlog goals, projects, etc., causing an unintended effect on metrics.
We use the possibility of linking Defects to Features when a Defect is a direct result of the work done on a Feature.
However, sometimes the defect is not discovered until after the Feature has been completed and also closed.
And then we have to re-open the feature (and planning level) in order to link the defect to the feature.
We disagree with this limitation and would like to have it removed such that we can link - also after completion and closure of the feature - all direct defects to the relevant feature.
The alternative is never to close defects and planning levels which is also not desirable.
Lots of good ideas and thoughts in the comments...
I wonder if we confined this suggestion to only allowing edit of closed work item fields which do not alter tracking progress, such as velocity. That would prevent issues (like revising history) while encouraging the behaviors V1 product owners/coaches appear to be endorsing: if you find you need to change a closed work item, what is it in your processes that creates that need?
I agree with not editing things in the story that impact velocity. I would love to be able to update dependencies of the story when we find a defect in a future sprint - to be able to link back to the closed story without reopening it.
This is probably the most tedious function of VersionOne. Release plans change, thus completed efforts need to be reallocated to new planning levels to properly be tracked. By having to reopen stories, the original Closed Date is lost and is no longer an accurate field to report on.
The logic that "it will mess up your metrics" doesnt make sense. Usually you're still going to reopen the associated sprint / planning level, make the change, then close them all down again. Which will still mess up your metrics. Please prioritise user friendlyness, and consider fixing the metrics calculations.
Seeing Backlog items as postits doesnt make sense either. One major benefit of an ALM tool is it gives documentation over the lifetime of the system.
Another nagging problem, you cant read the description field of a closed Backlog Item (it is collapsed by default) and you have to reopen the Backlog Item, just to read the description.
2 user stories where this causes frustration
Create a test set from a test suite based on a closed planning level to do some regression testing. You cannot close your test set, because its parent planning level is closed.
Create Defect templates configured with a sprint (to assist users during test periods). When the sprint closes, you'll want to update the Defect Template to point to then new sprint. You cannot do this without reopening the Sprint which the defect template is assigned to.
This idea should be implemented sooner rather than later. This is one of the top ideas voted on within IdeaSpace. There are many valid reasons and examples listed in this thread for why this is needed. It boils down to the tool being extremely inflexible and that gets in the way of companies from becoming truly agile. The Agile Manifesto says it best, "Individuals and Interactions over processes and tools."
+1
Agree
The ability to edit empty attributes after closed was introduced in the Spring 2020 release Check out https://community.versionone.com/Release-Notes-and-Downloads/Spring_2020_Release_Notes for more details