I am part of a team that builds an API and we manage our tasks in MS Azure DevOps. We have this user story around one of the endpoints, which is not yet deployed. But it just keeps staying alive sprint after sprint, now on version 7 of the API spec/schema. Every change is logged in the discussion thread on the work item. I wonder if it would be better to stop, close it up, and handle updates in a new work item.
What do you prefer in your team? What are the pros and cons? - and what did I forget so far
I don’t seem to see a problem with the flow you’re describing.
Is it about the aesthetics of it in the PM system/tool?
When we had these things, we had conversations within the team, whoever had a strong preference towards some other approach, we’d be inclined to maybe do that. It didn’t matter much the direction, and the main goal was to keep the people engaged and understanding the flow & organization.
kill and re-start - the downside is that if the PM is tracking time to deliver as a metric, their metric will be useless. But any PM that uses their fuel gauge alone to know how fast to drive the car, clearly has no idea how far apart gas stations might be, and less clue about how to only discover that they just passed the cheapest gas station in the country just 3 miles back.
Restarting also allows teams to rename the endpoint properly or fully refresh the feature/documentation and not keep a name that no longer fits the functionality and will alter cause confusion for Sales people trying to sell the new endpoint anyway.
