We've just started using JIRA Agile to manage our development process, and we're wondering what the best way to track and report work done by a development partner who does not have access to our internal JIRA system is. I should mention that we're quite new to both Agile and JIRA, so please forgive my ignorance.
We have a user story comprised of technical tasks. Our development partner is responsible for delivering some of those tasks. We are also unable to give our partner access to our JIRA system, an immutable circumstance. Nevertheless we need to track and report on the work being done on those tasks. What is the best way to accomplish this without:
We do have a developer who is our primary point of contact with the partner. Would it make sense to assign the task to this person, and if so, how would we make a distinction, reporting-wise, between the work the developer is "proxying" for the development partner, and the work they're actually assigned and responsible for?
If you go down the route of a proxy person (let's call them "Minion") to log work for the partner, then I would do two things. The first is to have distinct issues for each piece of work, so that you can start to separate out Minion's actual work from Minion's proxy work. The second is to have a clear and simple flag on the issues to indicate it was done by proxy. I'm not sure whether to recommend a dedicated custom field (maybe "work was proxied" as a single multi-check box), or a label, because it depends on what reporting you're doing and how well you can trust people other than Minion to set the box or label correctly.
Thanks for your response - I was sort of hoping that this was not so uncommon a scenario that I'd have to resort to proxying, that there would be a reasonably "standard" way to account for work done by a non-user; frankly that's the most desirable path, but if that's not possible...
If it makes a difference, the project type is "Agile Scrum" and it has not been customized. I've asked the project lead specifically what reports they're planning on using (I'm the devops/SA guy who is responsible for implementation) but at this juncture am not exactly sure.
The issues are definitely going to be distinct for the partner's work. Finally, we can assume that "Minion" will always set the checkbox or label correctly.
Well, I wouldn't say that they're "interacting" with the issues so much - they really have little visibility into them other than what work we've asked of them. The scenario is more that they've been contracted to develop some components for us (a relationship that predates our adoption of JIRA), and the "states" of the work they do, as far as our process is concerned, are fairly binary: done, or not done. They don't participate in our sprints, but have deadlines and can be notified when the non-completion of their work creates a block for us. So given all that, do you have any recommendations you could make or do you need to know more about the kind of reporting we're doing? Would we just be better off in sacrificing a user seat to the cause, or can we make meaningful distinctions in our reporting based on labels and/or custom checkboxes?
You've got quite a simple scenario, I think having Minion set a flag on work to indicate their progress is probably enough. Two other thoughts for this scenario though. 1. You could set up an issue type for "external work", which would dodge the need for Minion to flag things entirely, and make it *really* clear in your reporting at a glance (Also, separate issue types can use different workflows, fields and so-on). 2. If you're feeling particularly sneaky, you could also get the 3rd party to comment on the issue via email (although you'd still need to name a user to import the comments as), and there are some tricks and addons for sending email over to them when they don't have an account.
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!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot