On December 3rd, we went where no Praecipio Consulting webinar has gone before: We answered your Jira questions live! Between pre-submitted questions from webinar registrants, online Praecipio Consulting followers, and real-time queries from viewers, our resident Jira expert Christopher Pepe fielded the questions you most wanted answers to. We were thrilled by your response to the call for questions and feel the answers to be so helpful that we decided to share them with the Jira-using public at large! From new Jira users to experienced technical leads, here are the top Jira questions and answers for your inquiring minds.
Q: We have yet to find a way to enter our estimates in a manner that gives us valid burn-down charts on agile projects and would like advice. The process we use is as follows:
- Issues are entered into Jira (into the backlog) with a high level estimate.
- When we get into a sprint, we'd like to create sub-tasks that reallocate the hours in the original task (e.g., a story is entered with 40 hours, then the team determines that there will by 6 hours of BA work, two 8 hour development tasks, 8 hours of QA, 2 hours of documentation, and some PM work that can be logged against the main story).
Presently, we see the subtasks showing as additive and in the scenario above it ends up looking like there are 72 hours. How would you recommend that we solve this?
A: (6:04) The way Jira handles time tracking, all of your time is rolled up, so your time is double-entered. Take the original hourly estimate, delete from parent ticket (as it misses the intent of the time-tracking) and either a) don't include time estimates in the original story or b) make your stories into epics and give all sub-tasks (tests, bugs, etc.) time estimates that roll-up to give a more accurate picture of time tracked. It's also worth noting that, as people are generally not the best at estimating time, one could utilize story points to track time and establish velocity across your Agile team. For example, this new feature will take x amount of time based on x amount of sprints (compared to previous tasks of the same type).
Q: Can we delete Statuses from already published Workflows?
A: (9:26) Historically no (and I believe that's still the case). You have to copy the workflow and modify, or rebuild. Then map it back to your workflow scheme, deleting the status.
Q: We are creating different issues-types for different entities, User Story, Task, Test, Bug, etc. Does having these many different issue types create complication? Is it convenient to keep track of these issues? For Ex. 1 User story might have 3 Tasks, 2 Tests and 4 Bugs, isn’t that creating linking issues or traceability issues?
A: (10:42) This is a big question and the answer is really our whole business at Praecipio Consulting, as we seek to model your processes to Jira for connectivity across all systems. Creating an efficient data model in Jira can be challenging. You're taking the right approach in thinking about how to model your data. I can't advise you without knowing more about how you operate, but recommend you think about making your Stories into Epics in Jira Agile, and then add your Tasks, Tests, and Bugs to the Epic. That really simplifies the issue linking.
Q: Is there a quick way to see an issue's priority when looking at it on a board besides filtering it?
A: (13:54) Yes, the priority is shown by its icon. Hover over to see what it is. Agile packs a lot into a little space
Q: Is there a way to automatically move an issue to a different workflow when the issue type changes. Like any Post-Function?
A: (15:29) Jira will automatically do this. It means that your Workflow Scheme needs to have different workflows configured for the issue types. If workflows have different custom fields, Jira will force you to go through a mapping stage. No post-function is needed!
Q: What options for Pass Through Authentication exist? Are Add Ons the most often used method? Are there other ways of doing this without paying hefty prices?
A: (17:44) Add-ons are really the only way. There are REST authentication resources so if you can control intercepting the username and password you can hand them off to the application, but if your mechanism isn't HTTP based its hard to get the token in the users browser. Atlassian's Crowd is a popular choice, providing a single-sign on platform for authentication through multiple avenues.
Q: Beside custom fields, what other system configuration items can cause poor system performance? Permission schemes? Notification schemes? If so what are some best practices for these?
A: (20:35) The short answer is: lots of schema. Custom fields, complicated workflows and the like can contribute to slower performance. Finding bottlenecks is challenging. Many layers of monitoring is the best approach (Maybe you don't have a big enough thread pool or your disk access speed is too slow.) to make sure you can see what the JVM is doing. New Relic offers simplified yet robust monitoring capabilities for these purposes
Q: When entering a custom field, what is the best practice for configuring the field for specific issue types/projects versus a global context (all issue types/projects)? We have custom fields that will only be used for one or two issue types and a subset of projects, but we have configured them as all issue types/all projects. Is there a downside to this configuration?
A: (24:35) I encourage new admins (and even seasoned ones) to use global context and focus their energy on designing screens and related schema to get a project to operate as expected. Context makes it hard to track down why a field isn't showing up or some odd behavior that's occurring.
Q: How can I make an issue editable when the status is already closed? Also, I am unable to add a transition from a closed issue to another status.
A: (27:25) You should be able in the workflow editor to create a transition from closed. Jira may be blocking this, since closed issues are uneditable. The default workflow that comes with Jira, if copied, wouldn't allow you to edit a closed issue- so the properties associated with the workflow are copied too. You'll need to edit your custom workflow and delete this property or create your own.
Q: Can we add more fields in ‘Test’ Issue-type, like currently there are Test Step, Test Data and Expected Result. Can we include columns for Module, Test Scenario, etc.?
A: (30:18) Yes you can add more fields by modifying the Screens and maybe Field Configurations. You may need to create your custom fields first too.
Follow-up: (in the Zephyr panel shown in the issue) No, that is not configurable. You should tell Zephyr that you'd like it to be.
Q: Can you fix the Jira header to stay at the top of the page when scrolling?
(If you listen to the webinar audio, you also hear our Jira Expert cat weighing in on the subject as Christopher Pepe translates.)
Q: What are the benefits of a federated Jira instance?
A: (41:06) Atlassian has several resources on the benefits of managing multiple instances through federating. The only places where we really see people federate instances is in industry mandates (ex. industry permissions for viewing data) or when different groups within an organization need individual ownership. In this case, you'd create application links between the two instances to allow reporting from one instance to another; the pitfall is that you can only get results from one instance at a time.
When it comes to Jira, there is so much to know and learn! At Praecipio Consulting, we bring our Atlassian expertise to Jira and the entire product suite through our webinars, trainings and full service offering. Still have Jira questions or want to apply our experience to your instance? Find out how we can answer your questions and get you your best instance by contacting Praecipio Consulting.