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.

 

Comment

Log in or Join to comment
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,323 views 14 20
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot