TL;DR
You may have been told that, but it's generally (although not always) an anti-pattern, especially in agile frameworks. I don't know if I've coined the term, but the practice is called "shepherding," and while there are occasionally use cases for it as outlines below, it's generally a framework implementation smell.
Lifecycle Assignments of User Stores Aren't Required
I was told that user stories should always only be assigned to 1 person for the life of the story.
This is not a requirement for user stories as defined by Mike Cohn, nor is it a requirement of the Scrum framework. It is also not called out anywhere in the values or principles. In other words, it's a practice that you may or may not choose to use (I generally recommend against it), but it is definite not required 1 by any common framework that I know of.
1: Any kibitzers that find a framework (not a tool) that actually requires this practice should post a comment, and I'll add a section for those atypical exceptions.
So, unless you have a really strong reason specific to your organization or that your team has chosen to adopt as part of its self-managing process, I would junk this idea on principle. There are use cases for it, but you haven't posited one except for hearsay.
Shepherding
A Possible Exception: The "Work-Item Shepherd" Practice
One of the few arguments that I would personally accept for assigning a singular person to "own" the work item—as opposed to assigning ownership to the team as a whole—is when you're using an immature implementation (e.g. a Kanban without all the externalities, handoffs, wait states, and other queues fully identified) where someone on the team needs to shepherd the work item through the process.
From a RACI perspective, that person is accountable for helping the ticket move through the process. It doesn't mean they are solely responsible for doing the work it represents.
In a properly-functioning agile implementation, this shouldn't ever really be an issue. From any project management perspective, explicit hand-offs and inter-team dependencies should be minimized to improve flow, so the team should collectively own the work item. However, in less mature processes, someone may need to routinely follow up to ensure that the work item continues to flow through all the essential process stages, routinely update the work item's status, flag the item appropriately if the item becomes blocked in a way that isn't visible to the rest of the team, or otherwise facilitate its completion per the Definition of Done.
Why Shepherding is an Implementation Smell
Despite the foregoing, I'd still consider this practice a little whiffy. It usually indicates:
- A ticket-driven system based on individual responsibility rather than collective team ownership.
- A tool-driven process where the team is conforming to the expectations of the tool rather than finding or configuring tools that support an empowered team's desired process.
- A command-and-control reporting structure where individuals (rather than teams) are accountable for delivery, rather than focusing on a cohesive increment of value (e.g. a Sprint Goal) and a predictable delivery cadence.
- An example of the 100% utilization fallacy where the idea is that work is distributed or assigned in a way that's optimized for leveled work distribution rather than focusing on iterative outcomes.
Avoid Cargo-Culting 2 the Shepherding Practice
2: Because someone always argues about definitional things, cargo culting as used here comes from an amalgamation of non-religious connotations relevant to the application of any practices applied without consideration of the underlying purpose or theory. See:
for some of the various ways this is intended to apply to any unconsidered practice, including shepherding.
That doesn't mean you should never use shepherding if it's actually necessary. It simply means you should re-evaluate why you are doing this, what purpose it services, what it's actually measuring, and whether those metrics are intrinsically valuable to the project. I'll bet you a shiny nickel that the answer is because:
- The PMO requires it.
- Middle- or executive-management is requiring it.
- Because "it's always been done this way here."
Whatever the reason, haul it out into the light of day. Reconsider it with a strong presumption that it's solving the wrong problem. If it is, replace it with an experimental metric of some other sort that is more outcome-based. Continue doing that until your outcomes improve. That's the very essence of empiricism and continuous improvement, both of which are considered underpinnings of most modern modern project management frameworks, and explicitly part of Scrum Theory.
