Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Best Practices - Revisions to old story, but new assignee

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:

  1. reopen the original story but reassign it to the new assignee
  2. reopen the original story, leave the orginal assignee, but create a subtask with the new assignee
  3. 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

1 comment

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.

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:

  1. Epics = Show Names (Vietnam, Nova, etc.)
  2. Stories = Deliverables for that show (eCard, Facebook Cover Photo, Trailer Grx, etc.)
  3. 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.



Log in or Sign up to comment