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 Sign up to comment
Atlassian Community Anniversary

Happy Anniversary, Atlassian Community!

This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.

Read more
Community showcase
Julia Dillon
Posted Apr 17, 2018 in Jira

Tell us how your team runs on Jira!

Hey Atlassian Community! Today we are launching a bunch of customer stories about the amazing work teams, like Dropbox and Twilio, are doing with Jira. You can check out the stories here. The thi...

763 views 2 19
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