nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Best Practices - Revisions to old story, but new assignee

David Wilder

If you have a story that was assigned to a user and completed, but then needs to be revised and the original user can't do it, do you:

reopen the original story but reassign it to the new assignee
reopen the original story, leave the orginal assignee, but create a subtask with the new assignee
create a new story with the new asignee but link the two stories

If I do option #1 the reporting results are tainted and unaccurate

If I do option #2, the breadth of the new revisions are not accurately reflected via a subtask (i.e. the new fix isn't so simple and requires a lot of work)

If I do option #3, it appears we're creating 2 seperate deliverables when in reality it was just another version of the original story

Comments

Walter Buggenhout

Although you do not mention what the workflow behind your story is, I think we can safely assume that a story is only closed when all work on that story is truly completed.

As a consequence, you do not reopen a story. There may be good reasons that additional work is required. Maybe a bug has been discovered. In that case you would create a bug and (potentially) indeed link it to the original story.

Maybe there are new insights. Potentially because the story was not well elaborated initially, maybe because the product owner changed his/her mind. But this does not influence the fact that your original story has been fully completed. So you create another story. If you should link it to the first story is something I would leave in the open. If your backlog is broken down from epics at a higher level, I would rather associate the new story with the epic it functionally belongs to.

I would only create a subtask to the story if it is your regular practice to break stories down into sub-tasks. That would be an approach quite similar to what I just suggested about Epics.

David Wilder

Thanks Walter. This definitely makes sense. I appreciate all the time you took to write an answer.

We use a pretty unconvential way of organization for us because we work in marketing - not products. So our organizational structure is quite different than most. Here's how we break things down:

Epics = Show Names (Vietnam, Nova, etc.)
Stories = Deliverables for that show (eCard, Facebook Cover Photo, Trailer Grx, etc.)
Subtasks = Versions of each Deliverable (Premieres Tonight, Continues Tonight, Tomorrow, etc.)

I still understand your meaning though and I'll think about it some more. My initial inclination is to go with #2 but don't reopen the Story (Deliverable) because that would mean the original assignee would then see it again in their dashboard.

This is a pretty big outlier issue for us, so no matter the outcome, this situation probably won't come back around for awhile.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

agile

jira-core