Morgan Folsom

Morgan Folsom


Recent posts by Morgan Folsom

4 min read

How to Report in Confluence with the Jira Issues Macro | Praecipio Consulting

By Morgan Folsom on Aug 31, 2021 12:57:07 PM

Blogpost-DisplayImage-August copy_How to Report in Confluence with the Jira Issues Macro

One of the most powerful integrations in the Atlassian ecosystem is the native link between Jira and Confluence. For users working with both tools, the transition can be seamless if you do it right, but clunky if you don't. 

Now, what if I told you there was just one Confluence macro you could start using today that will immediately make reporting in Confluence easier and help you (and your team) keep track of your work? 

The Jira Issues macro is the go-to when reporting in Confluence.

Here are some tips to get your team to leverage this outstanding integration.

Insert an issue count for a Jira filter

Let's start small. Insert a link to Jira with the number of issues returned from a Jira search, written in Jira Query Language (JQL) or calling an existing Jira filter.  A Jira filter is a saved search written in JQL.

This is useful to pull up basic metrics for a high-level overview. The macro becomes a link to the filter, so if you want to review the issues in-depth, you can quickly hop over to Jira's issue navigator by clicking the highlighted issue count. The table below is an example of how our marketing team tracks employee blog post submissions.

Blog post submissions

To insert an issue count:

  1. Insert the Jira Macro
    1. Select the Jira create new in the top menu bar and select Jira Issue/Filter, OR
    2. Type { on your Confluence page, search and select Jira
  2. Enter in your JQL query
    1. To input an existing filter, type "filter = "Filter name", OR
    2. Type in the JQL directly, we'll use "project = PCM"
    3. Be sure to click on the Magnifying glass to execute the query
  3. Select 'Display Options' at the bottom of the dialog box to expand the options.
  4. Select 'Total issue count'
  5. Click Insert, and Voila!

Insert a single issue into Confluence

The macro can also link a single Jira issue to a Confluence page. That means not only can you see what issues are important (and what status they're in) in your documentation, but you can also see who's talking about the issue when you're in Jira.

Take, for example, this blog post. My progress is tracked on a Jira issue, linked to this very page in Confluence. Below you can see how it looks on the Confluence page I'm writing in. 

Jira ticket in Confluence

If I click on that link, I'll navigate to Jira where I can see under Issue Links, all of pages in which the issue has been mentioned. I can quickly see that this issue has been mentioned on the original page as well as another tracking Blog Content. 

Jira issue link

To insert one issue:

  1. Insert the Jira Macro and enter in your query (steps 1 and 2 above)
  2. Select one issue from the list
    1. If you know exactly which issue, you can simply type the Issue Key into the search bar and hit enter. 
  3. Expand the Display Options and select 'Single Issue'
  4. Select 'Insert'

Use the Jira macro to insert a list of issues in a page in Confluence

Remember that filter you entered in above? You can insert that filter into your page, too. Filters inserted with this macro are dynamic - that is, as the issues are updated in Jira, the Confluence page will reflect the most up-to-date information. You can customize which columns appear in the macro just like you can in Jira. To head into Jira, you can select the individual issues, or click on the total number at the bottom ('2 issues') to pull up the query in Jira.

Jira issue macro To insert a filter:

  1. Insert the Jira Macro and enter in your query (steps 1 and 2 above)
  2. Expand the Display options and select 'Table' 
  3. Edit the maximum issues and columns to display.
  4. Select 'Insert' to add to the page!

Create a Jira Issue from a Confluence page

If your issues don't exist in Jira yet, don't worry. This macro can create new issues in Jira if inspiration hits while you are editing a Confluence page. The issue will be created and you won't even have to leave the page!

Jira issue filter

To create a new issue:

  1. Insert the Jira Issue Macro
  2. Select 'Create New Issue' on the left panel
  3. Complete the form
  4. Select 'Insert'

No edit permission, no worries - you can also create issues from Confluence while viewing a page - simply highlight some text and then click on the Jira icon that appears. Create issues from Confluence

This one macro can solve many of your reporting needs in Confluence. What's more, you can provide context around the data instead of just displaying straight data. The Jira Macro is a great way to keep team members informed without navigating from Confluence to Jira and back again. 

If you have any questions on how Jira and Confluence work together, or any other questions on the Atlassian tech stack, contact us, and one of our experts will get in touch with you.

Topics: jira atlassian blog confluence tips integration macros reporting
3 min read

How to effectively communicate across all of your tools

By Morgan Folsom on Aug 5, 2021 12:33:48 PM

Blogpost-DisplayImage-August-Why-more-tools-does-not-mean-better- communication

One of the coolest parts of working with the Atlassian suite is the ability to see the wide variety of industries that use the tools in different ways. In my role working with clients I have seen how every company has adapted the tools slightly differently to make them work best for their processes, and help them make that process even smoother.

 While doing so I get to see firsthand how they communicate internally and externally. 

It becomes clear that while many of the tools that we use in our day-to-day jobs are great at facilitating communication, it can be hard to figure out exactly which tool we should be using for what. Here at Praecipio Consulting, I could reach out to my colleagues or clients lots of different ways – a Slack message, a comment on a Jira issue, a comment on a Confluence page, an email, or I could skip all of that and just call them directly. Sometimes, I'll see a combination – a Slack message to verify if a call is okay, or an email that follows a comment on a Jira issue to make sure that I've seen it. 

While Jira and Confluence is often the most direct way, many organizations run into the issue of mismanaged notifications that means people filter out all of their notifications (for detailed guides on how to fix that in either tool see How to Solve: "Too Many Jira Email Notifications" or How to Solve: "Too Many Confluence Email Notifications"). Ultimately, what's most important is that the team is consistent enough in their usage that you know where to find the information you need. 

Given that, here are my recommendations:

Jira

Use Jira comments for all communications specific to the issue at hand. This keeps the information tied to the subject, easy to find in the future, and permanent. You won't have to worry about having deleted an email if you've got all of the comments on the issue themselves. 

Confluence

Follow the same guide as above – if you've got a Confluence page about a subject, keep the collaboration in one place! You can use either inline comments or page comments to track the communication. Even resolved inline comments stick around, so if you need to reference this in the future, no problem. 

Chat (Slack, Teams, etc.)

Great for informal chats, quick clarifications, and funny gifs – but I try to keep any official decisions either out of the chat, or copied to the issue/page that holds the content on the subject we're discussing. If you're using a tool like Workato to integrate your Jira and Slack instances, you can even have your Slack messages added to the issue directly. 

Email

If you're going to be emailing about a ticket, just include the issue key in the Subject and CC your Jira email address, and the email will be added to the comments of the issue. This way, for folks who prefer working in email, the communications aren't lost. Otherwise, I try to send as few emails as possible.

Call (Phone, Slack, Zoom, etc.)

I'm a millennial, so let's just say this is rarely my first choice. Most of the time, for quick conversations I prefer chat, but, especially as more workers are moving remote, this can replace the quick stop by your desk that you may be used to. 

Ultimately, the above is how I manage communications internally and with clients, but which tool you use for which purpose is far less important than that you're consistent. The less time you have to spend hunting down information the better, so agree as a team how you'll communicate and stick to it!

If you are having trouble managing your teams' communications, contact us and one of our experts will be glad to help.

Topics: jira blog best-practices confluence workato workflows community culture slack
2 min read

Work Should Be Pulled, Not Pushed

By Morgan Folsom on Jul 29, 2021 1:08:14 PM

Blogpost-DisplayImage-July_Work Should Be Pulled, Not Pushed

Pushing work is generally considered to be the process by which someone will finish their work and then hand it off to a teammate, regardless of whether or not that teammate is ready for it. This type of behavior is commonly referred to as "Throwing something over the fence" - 

though it can also elicit comparisons to seagulls, pigeons, or other mischievous birds who come in, drop something unfavorable, then turn and fly away. The clear implication is that a person who pushes work typically does not pay attention to nor care what happens after it leaves their hands.

Pulling work, on the other hand, is generally considered the action by which someone will finish up what they are currently working on, then go out in search of the next work item. Typically, there is a known stack of work that person can pull from, ideally ranked by highest priority. The implication in this case is that the person has completed their current work (or is blocked) and has the bandwidth for new work.

Which work environment would you rather be a part of?

Ignore Salt-N-Pepa: don’t push it.

In our experience, teams that have built a culture of pulling work see two main benefits: a better working environment and more accurate metrics. As described above, a push-heavy culture can result in friction, frustration, or even animosity between teammates. Perhaps just as detrimental, a push-heavy environment can actually skew the data and give misleading insights.

When the culture transitions to becoming pull-heavy, the seagulls – and their unfavorable somethings – disappear! Teams are better able to manage their workloads, and the data become clearer and more useful.

A simple way to begin establishing a pull-heavy culture is to add neutral zones at the points of handoff in your process. These neutral zones represent areas where no team is adding value – rather, the item is finished with the previous part of the process and awaiting the next part. An example would be a “Ready for QA” column. When the development team is done with an item, they can move it to the Ready for QA column. QA can then manage their own workload and pull the work into their process when they have the bandwidth to do so.

This change is likely to generate new insights and improve the way your team is working. For instance, it should now be possible to determine when an item is actually being worked on as opposed to idly waiting for someone to pick it up. This can better inform managers how throughput can be increased. Additionally, it becomes easier to focus on high priority items, as lower priority work should remain in the neutral zones until the high priority work is completed. Having a team lead periodically prioritize work in the neutral zone will further improve the process as team members can simply select the first work item that meets their skillset.

Create a more autonomous and less frictional environment for your team: focus on pulling work through your process, not pushing it. 

If you're curious on transforming your team's culture and create the ideal environment to get work done, contact us, we'd love to help.

Topics: blog best-practices service-management culture agile
2 min read

Agile 101: What is a Spike?

By Morgan Folsom on Jul 20, 2021 11:59:24 AM

Blogpost-DisplayImage-July_What is a spike-

A Spike, in Agile software development, is a work item to support future work by the team that can't be performed without more research, design, or prototyping. Creating a spike allows you to dedicate time in a sprint to finding out more information in a defined time-box.

The benefit of using a Spike is that if the work turns out to be either more or less effort than you expected, it won't throw off the team's ability to get all of their committed work completed. No one wants to find out mid-sprint that a story is much more work than you thought because you didn't really know what it required yet. When running Scrum and trying to manage velocity, sometimes you need to build in room for uncertainty. It may be that there's a piece of work that needs to be completed, but we're not really sure how much work that's going to take. In these cases, using Spikes can be a huge help. 

How do I use Spikes?

  1. Create a ticket to represent a spike in your backlog
  2. Include the Spike in your sprint – Estimate the spike to determine how much effort should be dedicated to completing the spike
  3. Complete the necessary exploration or design during the Sprint to determine the estimate for the original story
  4. Close out the spike and update the original story with the new estimate

Using spikes in your sprints can make your teams more reliable – you've got a better idea of what's going on, with less pressure to know everything up-front.

Looking for more Agile 101? Check out Project Estimation - Story Points vs. Hours Estimation or Why Jira Won't Make You Agile.

And if you have any questions on Agile, contact us, one of our experts would love to talk with you and see if it's a good fit for your organization.

Topics: blog scrum tips agile
2 min read

Can Scrum Masters have multiple roles on a team?

By Morgan Folsom on Jul 2, 2021 9:15:00 AM

Blogpost-DisplayImage-June_Can my Scrum Master have multiple roles on a team-A question that I'm often asked is: Why have so many different roles on a scrum team? If a developer on a scrum team has the experience to act as the Scrum Master as well, is there any harm in consolidating? Short answer: Yes!

Although having one team member covering multiple roles seems more efficient, it can cause more problems than its worth. Before putting a team member in multiple roles, it's important to consider the following challenges.

Context Switching

Statistics show that it takes an average of 25 minutes to resume a task after being interrupted. Jumping between tasks that require completely different mindsets and skills require a huge context shift. Having a developer who is switching between working on code and managing blockers for the team can actually reduce efficiency. It may be more effective to have a Scrum Master working as a Scrum Master for multiple teams. 

Skills & Training

The skills needed to be a successful Product Owner (PO) are different than those needed to be a Scrum Master, which are different than those that make a good developer! The Scrum Master should have a high level of emotional intelligence and act as a leader for the developers. Developers should be subject matter experts, familiar with the best practices and best ways to implement the PO's requirements.

Conflicts of Interest

The Scrum Team is designed to have certain checks and balances – each role is well defined so that they can focus on the subject matter they are there for. When you start consolidating roles, there's a high risk of conflicts of interests. This is very clear when organizations try to combine PO and Scrum Masters – after all, one of the major jobs of the Scrum Master is to protect the team from scope creep, represented by the PO. Additionally, the Scrum Master unblocks the development team if needed, and helps facilitate the scrum ceremonies – an important part of that requires allowing the team to work through issues before utilizing your authority to pull in outside stakeholders. 

It can be tempting to try and combine your Scrum roles, but we strongly recommend respecting the division of responsibility that has been established. 

If your teams are having trouble with their scrum roles, have any question or just want to chat, contact us, we'd love to help!

Topics: best-practices management scrum tips project-management
3 min read

Jira Service Management Request Types Best Practices

By Morgan Folsom on May 10, 2021 3:10:00 PM

Blogpost-display-image_Jira Service Management Request TypesSince 2013, Jira Service Management has been Atlassian's solution to IT Service Management for both internal and external customers alike; more than 8 years of continual development has led to countless examples of how JSM has delivered value to its users. In this 2014 video, we can see how Puppet Labs used Atlassian's Jira Service Desk, now Jira Service Management, to resolve tickets 67% faster. Take it from Atlassian's ITSM Partner of the Year three years running, we love how JSM supports your IT governance strategy. However, when defining a service desk for your organization, one of the most important decisions that you'll make is around how you define your Request Types.

What are Request Types 

In Jira Service Management, the request type defines exactly what the customer sees and how the ticket moves and is displayed after it's been submitted. 

Request types allow you to map a single issue type to different kinds of requests. For example, you may have issue types like Incidents and Service Requests. That's how your IT team understand incoming requests and they have the benefit of being able to span multiple contexts. However, as an end-user, when I'm coming to the portal I'm not thinking in ITIL terms. I'm likely thinking more along the lines of "I can't login" or "I need a new computer." 

Request types allow you to represent both sides of the equation - the foundation of your portal are the issue types, but request types let you customize how they appear to customers in the portal. So, let's see what exactly we can do with request types.

What can I do with request types

  • Map a single issue type to many different request types: If there are multiple requests that follow the same workflow, you can utilize a single workflow across as many forms as you'd like!
  • Group requests: You may have multiple requests that can be logically grouped together, like Software and Hardware.
  • Change field display names: Even thought they're filling out the Summary field, on a request you may want it to say "What problem are you experiencing?" or "How can we help."
  • Show specific Jira fields: While an agent may need to see and edit fields like Team or Priority, you probably don't want your customer to see those on Create.
  • Preset fields: If certain request types have some constant information, you can preset fields without needing to modify the workflow or use any automation.
  • Customize how workflow statuses are displayed: If you don't need your customer to know that an issue is being escalated to Tier 2 or Tier 3, you can mask those statuses so all the customer sees is that the issue is "In Progress" and they won't receive notifications as it moves through that internal workflow. 

With that in mind, there are some best practices to keep in mind. 

Request type best practices

  • Think about the customer experience! Why are they coming to the portal?
  • Don't necessarily break request types or groups down by IT org structure. While this could be useful, there are lots of ways to route request types to the right place without having it affect the customer view.
  • Use hidden fields on your requests to simplify the experience - if you know a system wide outage is always urgent, don't make the user complete that field!
  • Use hidden components or Team custom fields to route to the appropriate queues. 

At Praecipio Consulting, we have the experts that can help you implement ITSM best practices across your entire organization.  Contact us, we'd love to help!

Topics: jira blog best-practices tips request jira-service-management
3 min read

Can a Product Owner also be a ScrumMaster?

By Morgan Folsom on Apr 12, 2021 10:21:00 AM

Blogpost-display-image_Can a Product Owner also be a Scrum Master-TL;DR: No!

Can one person hold both the Product Owner (PO) and ScrumMaster(SM) role in an Agile team? It's a question that a lot of companies starting their way through their Agile transformation will ask themselves (and us!). The Scrum team has three specific roles: Product Owner, ScrumMaster, and (most importantly) the Development team. It's clear why the question of combining SM and PO comes up so often - trying to figure out where current roles fit into the new dynamic can be a challenge for an organization, especially if your teams are now smaller and you don't have enough resources to fill the role of an SM and PO for each team. 

However, combining these roles is the biggest disservice you can do for your Agile teams. It may seem like a small tweak to the model, but given the functions of the two roles, you are setting up your teams for failure. Let's start with the definitions of these two roles so we can see why that is. 

Product Owner

The focus of the Product Owner is on the Product, as you might have guessed by now.  According to ScrumAlliance.org, "The Product Owner defines the what--as in what the product will look like and what features it should contain." The PO is responsible for maintaining the product backlog, and are responsible for communicating with stakeholders internally and externally to identify what the development team is working on. In their day-to-day, they are responsible for creating and prioritizing backlog items and communicating with the team expectations and acceptance of complete work items. 

ScrumMaster

The focus of the ScrumMaster is the team. "The ScrumMaster helps the Scrum Team perform at their highest level. They also protect the team from both internal and external distractions. ScrumMasters hold the Scrum Team accountable to their working agreements, Scrum values, and to the Scrum framework itself", as defined by ScrumAlliance.org. Where the PO is focused on What, the SM is focused on Who and How.  Arguably, the most important part of this definition is the emphasis on protecting the team. Internal distractions often come in the form of scope creep – new scope being introduced once work has already been committed to. In Scrum this often looks like new stories or bugs being introduced in the middle of a Sprint, and the job of the SM is to prevent this from happening as much as possible.

While I'm sure that we all know that some scope creep is inevitable (unless perhaps you're inhabiting the perfect utopia of business environments, in which case, I'll keep an eye out for my invite), but it can get out of hand quickly if there is no one on the team who is able to push back against the business. 

Okay, so why can't they be the same person?

By definition, the role of the ScrumMaster is to protect the team from the Product Owner (and the stakeholders that they are representing). Blurring the lines between these two roles mean that there is no one to push back when scope is added last minute, or ensure that the team is sticking to Scrum best practices, despite heavy workloads.

The most common outcomes that we see when these two roles are combined are:

  1. Tons of scope creep. Just, loads of it. All over the place.
  2. Sprint commitments are consistently not met because the team is being asked to do more work than they've agreed they are able to. 
  3. Product Owners assign out work to the team , as they are now "Managing" the team. 
  4. Buggier products –  after all, if I'm a developer trying to get through more work than I've acknowledged I can do, quality is inevitably going to suffer

Overall, not great!!

So what should I do then?

In a perfect world, you should have a single ScrumMaster per team, and Product Owner per product. This means that Product Owners can span multiple teams, if the teams are working from the same product backlog, but ScrumMasters are dedicated to a single team. If you don't have enough resources to commit to this model, in the short term, a ScrumMaster could potentially span more than one agile team - but I would say no more than 2 - after all, one person can only attend so many Scrum ceremonies while also being available to unblock their teams. 

However, the long term success of your Agile transformation means that it's time to start planning to fill those roles. Combining these roles will almost certainly decrease the effectiveness of your move to agile, as your teams are left unprotected and (likely) overworked. 

Looking for more information on Scrum best practices? Check out Sprint Planning - How long should sprints be? or Agile Batch Size: An Ode to Laundry

Topics: blog process scrum workflows project-management agile
2 min read

Jira Tips: Create From Template vs. Create From Shared Configuration

By Morgan Folsom on Apr 9, 2021 11:26:00 AM

Blogpost-display-image_Create from template vs. Create from shared configuration (1)

There are a variety of ways to create projects in Jira – whether from a predefined template from Atlassian or from a shared configuration with an existing project. As Jira administrators, this is one of the first questions you'll be faced with when onboarding new teams to the instance. Let's walk through the different strategies, and why we prefer creating from shared configuration. 

Creating from a template

Creating from the Atlassian templates will create a new set of unique schemes to that project - new items in your instance that are not shared with any other project. To create from a template, simply select one of Atlassian's predefined models on the 'Create Project' page. 

The benefit of using these templates is that each of your projects are self-contained, and a model has already been put together by Atlassian. Configuration is not shared with any other projects, even if everything is exactly the same. This means that teams can adjust their workflows, screens, etc. without affecting anyone else. This can be good for teams who don't share any processes with other teams using Jira, and allows project administrators more control over their projects. 

However, for organizations that are looking to scale and/or standardize, this can be a huge headache.

Creating from shared configuration

Using a shared configuration means that you are reusing existing and established configuration items in your instance. Rather than creating new sets of schemes when a project is created, you create based on another project. For example, if you created from shared configuration, both the old and new projects will use the same workflows, screens, and field configurations. Note that they won't share any Jira Service Management specific configuration items, like request types or queues. 

Additionally, once a project shares a configuration with another project, Project administrators can no longer edit the workflows without being Jira admins, which has the added benefit of supporting the goal of standardization and scalability in addition to administrative governance.

There are pros and cons to each of the above, but ultimately, it is recommended that whenever possible, projects should be created from Shared Configuration.

While templates allow teams to have more control over their projects, it does not lend itself to standardization or maintaining a clean Jira instance. Although IT teams often request more options for teams to self-service with Jira project configuration, in the interest of scalability, allowing any user to create their own Jira projects is not a best practice. Jira projects should not be treated as "projects", spun up or spun down on a regular basis: as a best practice projects should be long-lasting and consistent. Additionally, from an administrative perspective, it can be challenging to manage the sheer number of schemes and additional items when trying to troubleshoot issues or maintain the instance.

Looking for expert help with your Jira instance? Contact us, we'd love to help!

Topics: jira atlassian blog administrator best-practices tips
3 min read

Jira Workflow Tip: Global Transitions

By Morgan Folsom on Apr 5, 2021 11:47:00 AM

Blogpost-display-image_Jira Workflow Tip- Global TransitionsBuilding Jira workflows can be overwhelming. As Atlassian Platinum Solution Partners for over a decade, we at Praecipio Consulting have spent a lot of time building workflows (seriously, A LOT). 

One piece of workflow functionality that we often see either ignored or abused are global transitions. A global transition in Jira is a transition to a workflow status that is able to be triggered regardless of where the issue is in the workflow. These can be very powerful, and we use them in some capacity in almost all of our workflows. However, there are a few things that we put into place to make these transitions easier to use. 

When do I use a global transition?

While these are not appropriate in all situations, we recommend using them in situations where users should be able to move to the status from anywhere else in the workflow. The most common use cases are "On Hold" or "Withdrawn" transitions, where users should be able to place the issue there regardless of where it is in the life cycle. It is understandable that users shy away from global transitions, as without specific configuration they have the potential to be confusing to end users and open up the workflow in ways we may not want. Keep in mind that global transitions should not be overused - using direct transitions allows for processes to be enforced, while global transitions are great options when you need to remove an issue from its normal flow.

With that in mind, we recommend the following configuration on all global transitions:

How to configure a global transition

Transition Properties

Opsbar-sequence is a transition property that allows you to determine the order of all transitions in your workflow. To use it, you assign numbers to each transition, and Jira will numerically order them on the issue view. 

Global transitions generally belong at the end of the list, so we usually give them a high number (100 or  500) so no matter how robust your workflow gets, they're always at the end of the list of available transitions. 

Conditions

Workflow conditions prevent transitions from showing when certain criteria are not met. As a best practice, we always add a condition so the transition is not available from the status it's going to – e.g. if we have a "Withdraw" global transition that goes to Closed, the condition should be "Status != Closed". If this condition isn't present you'll see the global transition available when you're in the status it's going to. 

Post Functions

One of the biggest issues that we see with global transitions is around resolution. Jira resolutions are an extremely valuable tool, and if you don't configure your global transitions correctly, they can affect your data integrity. So, 

If the global transition is moving into a "Done" status (e.g. Closed or Withdrawn), add

  1. A post function that automatically sets the Resolution, OR
  2. A transition screen with resolution that prompts users to enter a resolution before the transition

If the global transition is NOT moving into a "Done" status, add

  1. A post function that clears resolution

With the above configuration, your workflows will be more user friendly while also ensuring that your Jira data stays clean. 

Still need more help with your workflows? Praecipio Consulting is an Atlassian Training Partner with a robust catalog of training, including Workflow help!

Topics: jira blog tips training workflows configuration atlassian-solution-partner
3 min read

Individuals and Interactions Over Tools Doesn't Mean No Tools

By Morgan Folsom on Feb 1, 2021 11:00:00 AM

Blogpost-display-image_People & Process over tools doesnt mean no tools-1"Individuals and interactions over processes and tools"

It's an important line from the Agile Manifesto – one that establishes that the focus when trying to work in an Agile way is the people. However, we often see this used as a justification to provide inadequate tools to teams. In a well-run Agile organization, you shouldn't have to think about the tools - they should support the work that the team needs to do without getting in the way. Organizations often make the mistake of implementing tools to make teams work in an Agile way. However, tools are in and of themselves not enough - the people and processes behind them are what makes a business go.

However, this doesn’t mean we should ignore the tools we use, opting for whatever’s cheapest, easiest to setup, what we’ve always used, or something that’s “good enough.” Rather, we should take the exact opposite approach and select our tools purposefully, deliberately identifying the tools which best empower employees and promote processes. Because of this, there are two properties of utmost importance when considering a new tool: the tool should allow our team to run with the process that best meets our team’s needs, and the tool should help our team members work better together.

To fit the first of these criteria, the tool should be customizable in a way that allows your team to use your own process. Much of enterprise software today shoehorns teams into predefined configurations and settings which the tool manufacturer thinks are best. This leads to frustration, difficulty in using the tool, and potentially costly transitions to new software. In our experience, every team is at least a little bit different, and even two teams that want to implement the same fundamental process will find they have a few differences they would like reflected in the process. Because those differences tend to arise from the uniqueness of your team, they are important to capture in the tool in order to give your team the tools that best meet your needs.

Further, a good tool will promote communication and collaboration between teammates, inside or outside of the tool. Information tends to get lost when team members do their work in one system but communicate that work in another. For this reason, an ideal product will allow for conversations to take place within the product, ideally directly on the work item those conversations are referring to. Historical conversations should be preserved to allow for a look back on what decisions were made and why, and the tool should have options for how users are notified of important communications. Further down the collaboration path, handoffs should be made simple if not automatic, and any approvals should be doable within the tool. Finally, high-level or detailed status reports should be visible and accessible by any team member who needs or wants to see them.

These two crucial properties are two of the reasons we like Jira. Atlassian’s strategy for a long time has been to develop applications to meet the 80% of needs that are shared by most teams, such as collaboration features, malleable processes, and easy visibility of work, while allowing the remaining 20% of needed functionality to be determined by individual teams and sourced in the Marketplace. The result is a product which delivers good performance out of the box, but can be optimized to meet the needs of any team.

Consider the role that Jira plays in Agile. A large portion of the functionality is built in: Kanban and scrum boards, backlogs, issue types, workflows, and sprint reports. However, the software is customizable to the point that it works equally well for teams that have a quick, simple process with a few issue types and teams which have a complicated process with several rules, handoffs, and types of work. It doesn’t matter to Jira whether your version of Agile requires multiple manager sign-offs before it’s done or if your team lives on the edge, skips QA altogether, and goes straight to production. The point is that the software fits your process, not the other way around. Regardless of process, there are several mechanisms for the team to stay in touch along the way. Every issue can be commented on and allows for @-mentions to draw attention quickly. Email notifications are sent out at times decided by the team, not at arbitrarily defined times decided by the tool’s developers. Progress is simple to see on a board, and every user has access to generate reports or build dashboards to collect information relevant to them, reducing the need for repetitive status reports.

Most organizations will purchase a tool, kick it around for a few years, then junk it because it “doesn’t work right” or “doesn’t make sense for us.” Don’t let this happen to your organization. Pick your tools with care and optimize them for your team. And if you need help, talk with the experts, and get great advice!

Topics: jira blog best-practices tools atlassian-products agile
2 min read

Should my Jira Service Management instance be separate from Jira Software?

By Morgan Folsom on Jan 29, 2021 2:04:24 PM

Blogpost-display-image_Should my Jira Service Desk instance be separate from Jira Software-As companies grow either organically or inorganically, many are faced with the decision of whether they should consolidate or keep their Jira instances separate. Today I'm going to address one specific flavor of this conundrum that I am often asked about, specifically with regards to separate instances of Jira Software and Jira Service Management. Some organizations choose to have separate instances for Jira Service Management and Jira Software, but I am here to tell you that is probably not necessary!

Although Jira Software and Jira Service Management are different products, there is no need to keep them separate. The most efficient companies use both in a single instance, so that teams can collaborate much more easily. As organizations adopt DevOps or start to think about it, one of the first things that is looked at is how IT interacts with the development organization. If these two groups are working in separate Jira instances, collaboration and clear understanding of ownership and handoffs is much more difficult. For example, It is much easier to link an incident that was submitted to the service desk to an associated bug if all of those tickets live in the same instance. While you can link to tickets in other instances, that requires users be licensed in both and have a clear understanding of where the work lives. Working in a single instance removes the need for potential duplicate licenses and ensures teams can communicate clearly. 

Occasionally teams use separate instances due to security considerations. However, in almost all situations your security concerns can be addressed by project permissions, application access, and issue security. There are few cases that Jira's native security features won't account for. 

Finally, let's look at this from a user experience perspective. One of the most prominent complaints that we see as organizations undertake their digital transformations are that users have to keep track of too many tools, a pain that I've felt in my career as well. Trying to remember where to log in for a specific subset of your work can be a headache. If your Jira Service Management and Jira Software instances are separate, they'll have two separate URLs that users have to navigate to. Signing into multiple locations and using different URLs adds an extra step where there need not be one.

Since you've already made the great decision to use both Jira Software and Jira Service Management, you might as well reap the benefits of the easy connection between the two so your teams can focus on what matters, rather than managing their tools. 

Are you looking to merge your Jira instances? Contact us, we know all about how to do that, and would love to help.

Topics: jira atlassian blog optimization tips integration project-management jira-core merge jira-service-management
4 min read

How is Confluence Cloud different from Server/Datacenter?

By Morgan Folsom on Dec 18, 2020 1:06:00 PM

Blogpost-display-image_How is Confluence Cloud different from Server-Datacenter-

If you've recently moved from a Confluence instance that was hosted by your organization to one on Atlassian's cloud, you may be noticing some differences in how the tools work! The experience is quite different, and we know that can be a bit overwhelming if you've spent a lot of time getting used to the server UI. The change will require some adjustments, so we've provided a quick overview of things to keep an eye out for so you can get back to expertly collaborating with your team.

Navigation

Let's start with getting to Confluence! You can of course access your instance via the new link provided by your IT team https://yourcompany.atlassian.net. But, if you're looking to get to Confluence from your linked Jira instance, the application switcher looks a little different. The application switcher now lives in the grid icon(Screen Shot 2020-04-17 at 11.09.36 AM). Select that and you can navigate to any linked applications, including Confluence. 

Creating pages

Page creation looks different in the new view - you'll notice that there is now only one option to create pages, the Create button. This functionality has made it a lot more intuitive to create pages from templates! In Server, users need to consciously make the decision to create from a template (selecting the '...') or a blank page. Now when creating pages available templates will appear on the right, allowing you to filter and search through templates. With this new navigation you can even see previews of the templates before you select them. 

Keyboard shortcuts

This is the change that threw me off the most when switching between the products, because I rely very heavily on shortcuts! Here are three that I use a lot that have changed:

Action
Server/Datacenter
Cloud
Insert a Macro { /
Start an ordered list 1. 
Change header level Cmd/Ctrl + 1/2/3... # / ## / ###

 

To see a full list of shortcuts, you can select Cmd/Ctrl + Space while editing a page and a dialog will appear and display all of your options. 

Page layouts

The experience in Confluence Cloud is more mobile friendly, so pages are more narrow by default than previously. However, you can still expand your pages to span full screen if you've got a lot of content. Opening the page layout options hasn't changed - you select the icon in the editor. However, the page layout editing experience has changed so you can work on it within the body of the page, instead of at the top.

Screen Shot 2020-04-17 at 11.24.48 AM

You'll notice the arrows pointing out - those allow you to span full screen for either the entire page (top) or the specific section (bottom). The same options to edit layouts are available but you can see them in-line instead, which makes for easier navigation while working them into your pages. 

Panels

The Panel macro is one of my favorites - I like the ability to break the page up visually, and they are a great way to do that. Atlassian has revamped how panels work in Cloud so that instead of having separate macros for different types of panels: Panel, Info, Warning, Note, Success, etc. they are all just one macro, and you can switch the coloring as needed by selecting different icons. 

Screen Shot 2020-04-17 at 11.28.05 AM

Macros while viewing a page

The last change I want to highlight is perhaps my favorite. When editing Confluence previously, you might've noticed that when you insert macros, many of them appear different while editing vs. viewing the page. In cloud, we now see that macros like the Jira Issues macro pictured below actually shows the content while editing now. 

Screen Shot 2020-04-17 at 11.31.30 AM

Switching between tools or views can be tough, but with Atlassian's cloud platform you'll see a lot of changes that make the user experience run more smoothly. Now you've seen some of the changes, you're ready to hit the ground running!

Thinking about switching to Cloud? Contact us to talk about how we can help!

Topics: jira atlassian blog migrations server cloud data-center confluence-cloud
2 min read

How to Get Involved This #GivingTuesday

By Morgan Folsom on Nov 30, 2020 2:14:24 PM

Blogpost-display-image_SJ- Giving Tuesday blog

Now that we're rapidly coming up on the end of 2020, I'm taking time to pause my life and find things to be thankful for. Under normal circumstances, this exercise can be a great way to wrap up the year; after this year, though, let's just say that I had a harder time than normal pulling together a list. The truth is that despite it being a tough year, I do have a lot to be thankful for – I've made it through this year with a job and a home, something that many people are not experiencing this year.

As we enter the holiday season, the messaging that we see is increasingly commercial: Black Friday edges earlier into Thanksgiving, Small Business Saturday tries to pull focus locally, and Cyber Monday pretends like we're not online shopping for the first two, making it a trifecta of commercialism.

Giving Tuesday is an annual celebration on the Tuesday following Thanksgiving that encourages individuals and organizations across the country to do good. What better way to wrap up three of the highest spending days of the year by looking at how we can support others?

What we're doing

Here at Praecipio Consulting, we've stepped back and taken stock as well. Supporting our communities has always been a core value here, and we've been a member of Pledge 1% for years. We are proud to spend our time and money with organizations like the Flatwater Foundation, TreeFolks, and Bamberger Ranch. This year, we felt like we had to do more. At the beginning of June, the company began matching employee donations and doubling VTO toward relevant organizations.

This #GivingTuesday, we'll be taking it a step further and doubling employee donation matching for donations made on Tuesday, December 1st, as part of our continued dedication to supporting our communities. 

How you can get involved

That's what we're doing, but what about you?

There are a lot of ways to get involved, even in the middle of a pandemic. Check out local resources to find organizations that are accepting donations or for volunteer opportunities (if you're comfortable!). Events like gift drives and meal delivery are also great ways to contribute while still staying safe. Don't forget to look at local mutual aid funds for opportunities for even bigger impacts in your communities. 

Topics: blog flatwater-foundation do-good pledge-1% global-climate-crisis treefolks green-team
3 min read

Challenges in Managing Your Own Atlassian Instances

By Morgan Folsom on Oct 2, 2020 12:30:00 PM

Blogpost-display-image_Challenges in managing your own Atlassian instances

Are you having trouble managing your Atlassian instances? As tools like Jira become mission-critical to organizations, it's increasingly important that their maintenance is formalized, with dedicated resources who manage the tools. Let's walk through a few of the biggest challenges that we see and how Praecipio Consulting's Managed Services offering can help ease the pain.

 

Can you help if we don't have the technical experience to support the tools?

It's not uncommon that teams find themselves struggling to manage the specifics of Atlassian. Just because you've got a killer IT team doesn't mean they'll be experts on a whole new platform on day one! There are a lot of intricacies to the tools that can take admins a while to understand, especially when we're looking at Jira. On top of figuring out the technical aspects of maintaining the tools, you're also expected to help make process recommendations and changes for the teams that use the tool at your company. 

One of the biggest benefits of using a Managed Services provider is that you don't have to develop all of the in-depth expertise on the tools, because we've been there and done that. Our focus on the Atlassian suite means that we know the tools better than anyone so that in addition to answering your requests, we can anticipate issues because we know what to look for. 

What about about if our IT team is too small to have dedicated admins?

Maybe your team are experts at managing the Atlassian suite, but you're missing one major thing: time. Keeping your instances healthy requires ongoing maintenance, dedicating time for things like platform upgrades and marketplace app configuration, as well as triaging requests from your users to make the tools work for them. This is something that affects teams of all sizes and can be especially painful if you're part of a small organization. When you don't have dedicated Atlassian admins, the impact on your instances can be huge. If teams are only able to focus on addressing breakfixes and user requests, things like upgrading your marketplace apps can fall by the wayside. 

Our Managed Services team excels at thoroughly preparing for and executing upgrades, and regularly checking to make sure your instances and apps aren't affected by any critical security issues. 

Or what if we've moved to Cloud and don't know what administration we need to do anymore?

If you're one of the many organizations that have moved from hosted Server or Data Center instances to Atlassian's Cloud, you've probably realized that administration looks a little different now. Because a lot of the technical maintenance tasks aren't necessary anymore (woohoo!), your team gets to focus on making sure the instance is healthy from a process perspective. This kind of administration requires different skills from your admins – and while they hopefully have been providing this before, it's easy for this to fall through the cracks. 

Administration isn't just about creating workflows or fields, but making sure that the configuration in the instance aligns to industry and Jira best practice. Jira in particular is extremely configurable – with the right combination of apps and know-how, you can do basically anything, for better or worse. A lot of common configuration choices can be setting you up for future headaches – things like too heavy a reliance on scripting when out-of-the box configuration can do the same thing, making upgrades a pain and causing negative performance impacts. 

If any of the concerns above strike a chord, let us help

Topics: atlassian managed-services cloud atlassian-products atlassian-solution-partner
3 min read

Agile 101: Why Jira Won't Make You Agile

By Morgan Folsom on Sep 2, 2020 12:15:00 PM

Why Atlassian tools won't make your organization Agile

It's no secret that here at Praecipio Consulting, we love Atlassianwe love Agile, and we especially love using Atlassian tools to Agile ends. The Atlassian suite (Jira, in particular) has been built to reinforce a lot of the concepts that are core to functioning in an Agile way, which is one of the many reasons that 83% of the Fortune 500 use it. So, setting up Jira is often one of the first steps companies take when they want to adopt the Agile framework. 

However (and this is a big one!), Jira, or any other tool, should absolutely not be the first step in your Agile transformation. 

Here's why:

Tools Won't Change Mindsets

If you've ever happened upon the Agile Manifesto, then you might guess where I'm going here. The very first line of the Agile Manifesto reads:

"Individuals and Interactions OVER Processes and Tools"

Agile is not something that you "do" to an organization by giving your developers Jira and having daily status updates that you call stand-ups. Rather, an Agile transformation is the process of rethinking how you deliver value to your customers from the ground up. It might sound like a big undertaking, and that's because it is! There's a good reason that "transformation" is the word we use to describe this process (I could insert a cheesy metaphor about butterflies, chrysalis, etc., but I think you get the idea). Now, while part of successfully running an organization means identifying tools that help your employees do their jobs well, the function of your process and tools is to support the individuals and interactions. 

Sure, we can use Jira to enforce some good Agile practices, but if teams don't know what the practices are or care why they're doing it, you won't get the same value out of them. The tools should be enforcing values that have been established, keeping teams from veering too off-path, but they are simply not an effective way of establishing values in the first place. 

Jira's not broken, you're just not Agile

While Jira can be customized to do almost anything you want, there are some structures in place that enforce Agile best practices. There are small things that work perfectly if your teams are well-aligned to best practices, but are huge headaches if you've got bad practices.

The most common example of this that I see is the struggle to manage sub-tasks in Sprints. Many teams use Sub-tasks to break down stories and bugs into smaller pieces of work. However, Jira will not allow you to close a Sprint if you've got stories with open sub-tasks. From a process perspective, this makes sense - your story isn't done until all of the work is done, which means you don't get credit for a story until it, and all of the work beneath it, are Done. Teams fight against this, wanting partial credit for the story that's not been completed. Ultimately, the problem here is not Jira - Jira is enforcing a good practice. The problem is the underlying process - maybe the team hasn't had the discussions about the Definition of Done, or they are getting pressure from above to complete a certain number of story points in a Sprint, or QA is not part of the team, so they're hitting bottlenecks along the way, etc. 

Examples like this come up often. Jira will enforce some fundamentals, and your failure to meet those minimum lines can make it look like the tool doesn't work for you. We can see another example in this hotly-debated blog titled Jira is an antipattern. This article posits that the use of Jira is a good sign that an organization's off-track, and while we explicitly disagree with the thesis, it highlights effectively why Jira cannot be the driver. Trying to use a tool to drive your Agile transformation can easily make it look like the tool is the problem, obscuring the underlying changes that need to be made. 

Ultimately, Jira is a great tool for supporting those Individuals and Interactions the Agile Manifesto highlights, but it is essential to remember that's just what it is: support. Trying to use Jira to drive your Agile transformations sets your teams up for failure if you're applying those rules and structures before even explaining what their purpose. 

When we say we love Agile, we mean it. If you'd like some guidance in your journey to Agile transformation and how to properly set your teams up for success with Jira, get in touch with the Praecipio Consulting team

Topics: jira blog scaled-agile jira-software agile
1 min read

Atlassian Hosting: What are my options?

By Morgan Folsom on Aug 20, 2020 2:15:00 PM

Atlassian Hosting options

One of the most important decisions that your organization has to make with regards to your Atlassian applications is which hosting option you'll use. Not only will you will want to review the differences between Cloud, Server, and Data Center, but unless you are using Atlassian's Cloud platform, you'll also have to make key decisions about infrastructure. Praecipio Consulting offers Cumulus Cloud, our managed hosting solution to help make your decision easier. 

Amanda Babb, our Principal Consultant, was recently invited to chat with the hosts of “CarahCast,” Carahsoft’s new podcast dedicated to bringing listeners the latest in Government IT case studies, technology trends, recent legislation news, and Government IT best practices. 

In the podcast episode titled “Hosting in the Cloud with Atlassian,” Amanda discusses Cumulus Cloud, our comprehensive hosting solution that manages server and data center editions of the Atlassian suite, the value it brings to the enterprise organization, and why it's different from any of the other solutions out there.

Listen to Principal Consultant Amanda Babb outline all of the above and more in this Atlassian Podcast with our partner, Carahsoft. 

Topics: atlassian blog migrations cloud hosting atlassian-products podcast
2 min read

Praecipio Consulting's Incident Management Solution Is Live in Workato's Automation Marketplace

By Morgan Folsom on Jul 31, 2020 12:15:00 PM

2020 Blogposts_Praecipio is live in Workatos automation marketplace

Fun fact: At Workato's 2020 Partner Awards, Praecipio Consulting took home the Partner Award for IT Automations for the work that we did in collaboration with Workato and a leading animation studio to deliver an integrated Incident Management solution. The award recognizes our value in streamlining the incident management process through the integration of on-call tools, leading to improved resolution times and an enhanced experience for both the agent and customer.

And now, you can find this exact solution to in Workato's recently-launched Automation Marketplace, an online marketplace of best-in-class workflow automations across various business functions inside an enterprise. The Praecipio Consulting team created a solution around Incident Management using Workato and the Atlassian suite that seamlessly communicated to Jira Service Desk, Slack, AND PagerDuty. This recipe for success keeps agents focused on helping their users (rather than trying to figure out which tool has the most up-to-date information) and delivering an exceptional experience for the client's customers.

Head over to Workato's automation portal, where we outlined exactly how to implement this solution within your organization. And for more information about how we use Workato, check out our recent case study on Enterprise Service Management!

Topics: atlassian automation workato incident-management user-experience
1 min read

Is Going Agile Worth It? The Wall Street Journal Says So!

By Morgan Folsom on Jul 29, 2020 12:15:00 PM

2020 Blogposts_Is Agile Worth It- The Wall Street Journal Says So

Agile is one of the hottest trends in the business world right now - but is it actually worth it? (short answer: Yes!). The Wall Street Journal recently published an article that discussed the importance of cultivating an agile culture for enterprises who want to move forward with their business and survive the pandemic. Check out how our client, ACI Worldwide, has made impressive improvements in their process, pivoting to the Atlassian suite to manage their work across the board, in this Wall Street Journal spotlight. 

https://partners.wsj.com/atlassian/built-for-change/aci-worldwide-paying-agility-forward/

Not only did these changes help ACI Worldwide increase its enterprise agility, but it also successfully prepared their organization to quickly shift focus and resources during a constantly-mutating global pandemic. 

Give the article a read and let us know what you think!

Topics: scaled-agile enterprise service-management safe agile
4 min read

Where Do Business Analysts Fit Into The Agile Organization?

By Morgan Folsom on Jul 8, 2020 12:15:00 PM

2020 Blogposts_Where do Business Analysts fit into an Agile organization-

One of the hardest parts of an agile transformation (outside of, you know, changing up the entire way that your organization produces value), is aligning existing organizational structures to new Scrum team roles. This process is absolutely essential, and you must take into consideration both the current role as well as the personality and interests of your team members. 

This blog post will focus on how you can specifically map Business Analysts (BA) into your new Agile organization. Changing someone's job title requires sensitivity, and not every BA will exactly fit the description as outlined below. So, be sure to work with the individuals in your organization to find exactly where they should be. Don't forget that one of the key tenets of Agile is fast feedback and iterations! You may not find the right mapping the first time around, but some people will likely shift around as teams figure out how they work best.

What is a Business Analyst (BA)?

Let's start with the basics - what do BAs actually do? Before you can figure out where they'll go in the organization, let's start with establishing what role they serve. 

According to CIO.com, "Business analysts (BAs) are responsible for bridging the gap between IT and the business."

What this looks like can vary across companies and industries, but the BA role generally involves analyzing data to determine requirements, deliver recommendations and reports, and evaluate existing processes. Successful BAs are often very detail-oriented and effective communicators, which can make them an asset to any team. 

What are the roles in a Scrum Team?

Looking at Scrum teams, in particular, there are three primary roles:

  1. Scrum Master (SM): The Scrum Master supports the team members, unblocking them when necessary, and holding them to their commitments. Scrum Masters are the protector of the team – they ensure that the Product Owner and the organization respect the dedicated scope that the team has agreed to. 
  2. Product Owner (PO): The Product Owner owns the product (wild, I know!). They incorporate customer and organizational feedback to manage and prioritize the backlog of the team. 
  3. Development Team: A self-organizing team of developers that are responsible for determining the best way to implement the requirements of the Product Owner

So, where do they fit?

Let's compare. Which of the above Scrum Roles sounds most like a BA? Someone who has experience analyzing data and translating it to requirements will likely be well-prepared for...doing the same thing for a Scrum Team! Generally, where we see BAs succeed the most is when they take on a Product Owner role. 

Much of the work is the same in these two roles, with a focus on data-based decision making and effectively communicating requirements. A Product Owner must be able to clearly communicate their goals to both the team and to internal and external stakeholders. Additionally, these communication skills are also necessary for the process of gathering feedback from customers. 

On the other hand, we generally see less success in mapping BAs to Scrum Master roles, or (even worse) trying to have a BA function as both a Scrum Master and PO. The shift from product and data focus to people-focused work can be hard for experienced BAs, but it's definitely not impossible. 

Again, when trying to align your existing team members to scrum roles, being open to feedback and change is important! You are dealing with people, so even if on paper your BA is a good match for a PO role, if they are expressing interest in something more like a Scrum Master, your teams will benefit from leadership being open to this kind of shifting. 

Looking for more help in your agile transformation? Check out The ABCs of Agile or What’s the Difference? Agile Coach vs Agile Consultant! And if you are an enterprise looking to scale your business in a way where you still have financial control, learn How Jira Align Helps Enterprises Embrace Lean Budgets

Topics: scaled-agile business-teams
3 min read

Workato: A Recipe for Efficiency

By Morgan Folsom on May 19, 2020 9:15:00 AM

We'd like to feature one of our partners, Workato, and showcase just a few of the many reasons why we love working with them. Workato is a cloud-based automation and integration platform. We've told you about how we used Workato as an integral part of a full Enterprise Service Management (ESM) solution, and in this post, we cover how we leverage Workato at Praecipio Consulting to connect Jira and Salesforce. 

Our use case

Most of our use of Workato internally is in support of our Business Development and Account Management team. As an Atlassian Platinum and Enterprise Solution Partner, you might have guessed that we do a lot of work in the Atlassian suite. Between Jira and Confluence, we cover the vast majority of what we do as a business. However, there are some use cases internally that are better suited for other tools - specifically Salesforce. Even though we're using a variety of tools, Jira and Confluence remain our single source of truth, we need a platform that integrates Salesforce with Jira, and Workato helps accomplish this. We've got a wide variety of recipes to this end, but there are two I'd like to feature in this post. 

Lead management

One of the primary reasons that we see organizations trying to shift their work into the Atlassian suite (apart from all of the other reasons that Jira is great, of course) is cost, and we are no exception. We don't have Salesforce licensed for the entire company, as many non-Sales folks don't need to interact with it very often. We do use Salesforce for lead and opportunity management, though, and we all know that leads can come from anywhere in the company, not just Sales. 

With that in mind, we have Workato working behind the scenes so that any Jira user can create a lead in Jira, which is then immediately pushed to Salesforce. On top of that, we've got bi-directional sync set up so that when a lead that requires more effort comes into Salesforce, like a process demo or technical questionnaire, the issues are created and assigned out for the appropriate people to complete. This allows for both a more dynamic user experience (for example, I can create tickets in the tools I'm used to, and I don't have to bug someone on the sales team to create a lead for me in Salesforce) as well as better reporting since all of the information lives in one tool. 

Client contact information

Additionally, we also track all of our project management in Jira (seriously, we use it for just about everything). When we start a new project, we track it in Jira, but all of our client contact information is stored in the Salesforce. To solve the problem of syncing information in different tools, once we create an Epic for a client, Workato automatically pulls the contact information from Salesforce based on the customer selected. This way the project resources have access to everything that they need to hit the ground running, and we don't have to manually update information in multiple tools.

These are just a few examples of how we use Workato. Truly, the possibilities are endless. In a world where your daily work involves multiple tools, Workato makes the entire process move more smoothly so that your team can focus more on their actual work and spend less time working within the tools used to get it done. 

Want to learn more about this versatile, does-it-all tool? Check out Praecipio Consulting's solution in Workato's Automation Portal, or watch this Webinar that shows exactly why we love Workato.

Topics: jira automation salesforce workato
4 min read

Navigating a Pandemic in a Digital Age

By Morgan Folsom on Apr 10, 2020 9:15:00 AM

2020 Blogposts_NavigatingAPandemicInDigitalAge

Right now we're living in unprecedented times. With COVID-19 moving across the planet, families and businesses are having to learn how to keep moving forward amongst an onslaught of swiftly changing information. During a conversation with one of our technology partners, Splunk, they shared their current COVID-19 data aggregation:

splunk image

This got us thinking: How can we best stay informed during this crisis while still staying sane?

Check your sources

First and foremost, with public health emergencies, it is always best to stick to official agencies like the World Health Organization (WHO) or the Center for Disease Control (CDC), or state, county, and local agencies where appropriate. 

Outside of that, it is as important as ever that we check our sources before reading or sharing. Not all resources are alike, and with a situation as widespread as this novel coronavirus, not only is there a lot of information out there but misinformation as well. A study by MIT researchers determined that, at least on Twitter, false news stories spread faster and farther than the truth. There are many ways that both individuals and businesses can be sure that the information they are sharing is correct. As someone who reads a lot of news online, there are a few things that I check for. 

  1. Date: When was this published? Is it recent enough to still be relevant, or has it resurfaced due to a clickbait headline? If an article is old enough, try googling some of the keywords for more up-to-date information
  2. Authority: Who wrote the content? Look at both the website and the specific author for signs of bias and credibility. 
  3. Look & feel: Does the website look suspicious? Most of us have run into a website and immediately turned around - whether that means it's extremely ad-heavy, trying to trick you into clicking on things, or looks like it was made in the early '00s. Trust your instincts if something looks off. 

When in doubt, try searching elsewhere for the same information. If you can find it corroborated elsewhere by known reliable sources, you're probably good to go. Some large online platforms, content aggregators, and social media companies are doing their part to assist in this. Pinterest, for example, has limited all of the relevant search results to only internationally-recognized health organizations. Many major news outlets, like the New York Times and The Washington Post that have removed COVID-19 related articles from behind paywalls, are allowing people access to the content without a subscription. Even further, I'm sure you've noticed your inbox filling with notifications from every company you've ever interacted with, letting you know their contingency plan for their services and their employees. 

pinterest image

Right now, it is essential as both individuals and businesses to be sure that the data we're reading and sharing is clear and accurate. 

However...

Stop scrolling 

Amanda Mull recently wrote about plague dread, the specific anxiety that comes from an onslaught of information paired with a lot of unexpected time spent at home or alone. While it is important to follow recommended guidelines and stay informed about local and national announcements, there's nothing wrong with signing off once you get the information you need. My strategy for this is pretty simple: limiting screen time. When at home, it's easy to accidentally spend hours on my phone or computer, so I try to be conscious of this. When I can tell that all the scrolling is taking an emotional toll, I'll leave my phone in another room and focus on something else (have you seen this Buzzfeed list of quarantine hobbies?). 

These are certainly unprecedented times, but we're more connected now than at any point in the past, and that can make navigating situations like these a bit easier. For more information, see Praecipio Consulting's COVID-19 response to see how we're working through this crisis. 

Looking for tips on how your team can adjust to remote work? Check out How ChatOps Can Connect Your Remote & Traveling Workers or Less Meetings More Collaboration.

 
Topics: covid-19 work-from-home
3 min read

How to Solve Too Many Confluence Email Notifications

By Morgan Folsom on Mar 18, 2020 9:30:00 AM

confluene email notifications

We often hear feedback that Jira is too noisy, but Confluence has the potential to fill your inbox as well if you're not on top of your email preferences. If you've read our blog outlining the solution to reducing Jira notifications, but your users are still complaining about noise, it may be time to provide some guidance on Confluence notifications too. 

So if you're a user, let's talk about which notifications you're getting and how you can escape the inbox overflow. 

Watching a Space

If you use Confluence 6.13 or an earlier version, you may be required to watch a space when you first log into the instance. Watching a space means that you will receive notifications for all updates to the pages within this space, and this can be a harsh welcome to a new Confluence instance. If you are on one of these affected versions, a Confluence admin can fix this by disabling the Onboarding dialog globally. Confluence 6.14 and later removes this requirement, but it is still possible to watch spaces manually.

To identify which spaces you are watching:

  1. Click on your profile photo in the top right and select Watches.
  2. View Space Watches to identify which spaces you are watching.
  3. If you want to unfollow the space, simply click Stop Watching on the right side of the screen.

Watching a Page

In addition to watching entire spaces, you can watch specific Confluence pages. You can do this manually, or automatically if Autowatch is enabled on your profile. If Autowatch is enabled, you will be added as a watcher to all pages and blog posts that you've created, edited, or commented on. For users that contribute to a lot of content, this can result in a great deal of notifications. 

Disabling Autowatch is your best bet if you receive too many of these. To disable Autowatch:

  • Click on your profile photo in the top right and select Settings.
  • Select Email under the left panel labeled Your Settings.
  • Select Edit at the bottom of the page, and uncheck Autowatch

Additionally, to see all pages that you're watching:

  1. Click on your profile photo in the top right and select Watches.
  2. View Page Watches to identify which spaces you are watching.
  3. If you want to unfollow the page, simply click Stop Watching on the right side of the screen.

Recommended/Daily Updates

If you receive notifications that aren't tied to specific pages that you edited or watched, you may be receiving Confluence Recommended Updates or Daily Updates. This functionality will send updates and information about Confluence content.

If you're not interested in receiving these updates:

  1. Click on your profile photo in the top right and select Settings.
  2. Select Email under the left panel labeled Your Settings.
  3. Select Edit at the bottom of the page, and uncheck Recommended Updates and/or Daily Updates

Notify on My Actions

If you don't ever want to receive notifications for changes that you've made in Confluence, you'll want to be sure that this box is unchecked as well!

  1. Click on your profile photo in the top right and select Settings.
  2. Select Email under the left panel labeled Your Settings.
  3. Select Edit at the bottom of the page, and uncheck Notify on My Actions

Uncheck Notify Watchers

Help keep your team's inboxes clean by unchecking the Notify Watchers box when updating pages. Checking this only when you want to let your team know there have been changes to a page will help keep notifications relevant.

 

Now that you've updated your Confluence and Jira email settings, you can get rid of those inbox filters, and finally receive just the notifications that matter to you. 

 

 

Topics: blog best-practices confluence tips email-notifications
2 min read

Which Jira Product Do I Need?

By Morgan Folsom on Oct 29, 2019 11:53:00 AM

Atlassian, the developer of Jira, has a wide variety of products. If you're here, you're probably wondering about a few specifically:

  • Jira Software
  • Jira Service Desk
  • Jira Core

Particularly, what the heck is the difference between them? Which is better/ Which do I need to use? Can I use more than one? Take a look to learn more about each Atlassian Jira product and discover which tool makes sense for your team. 

Jira Software

When you're thinking of Jira, it's most likely you're thinking of Jira Software, Atlassian's biggest Jira (and oldest) product. If you're a user in a Jira Software Instance you can:

  • Work in Software projects
  • View issues in kanban or scrum boards
  • Run sprints
  • Track releases

If you're developing code or are running your teams in an Agile way, Jira Software is likely for you. 

Jira Service Desk

Jira Service Desk, on the other hand, is Atlassian's answer to ITSM (IT Service Management) —it gives you customer portals and the ability to allow unlicensed users to submit tickets to your team. 

If you're working as an agent in a Jira Service Desk instance you can:

  • Work in Service Desk projects
  • Work on tickets submitted through a customizable customer portal
  • View issues in queues
  • Track Service Level Agreements (SLAs)

If your team manages request intake (internal or external) and are tracking SLAs or service requests, Jira Service Desk may be your answer.

Jira Service Desk is ITIL certified, but any team can use it. For more information on this, watch this Webinar to hear how non-technical teams can use Atlassian.

Jira Core

Jira Core is Atlassian's business team offering. If you want to track projects without too many bells and whistles, Jira Core and its "Business" projects will get you there. 

With Jira Core any team can do things like:

  • Manage projects or campaigns
  • Track assets
  • Anything that requires moving work through a workflow

Jira Core ships with both Jira Software and Jira Service Desk, so if your organization has either already, then you can try out a business project today. 

So what do I do now?

Any Jira instance can have any combination of these three products, which makes it very easy to cover multiple parts of your organization.

Each offering brings a number of ways to make Jira work for you and your team, and each type of instance lets you customize everything from permissions to specialized workflows to better fit your organization. 

Now that you've got that figured out, contact Praecipio Consulting to help with your licensing needs or to simply help you get started.

Topics: jira jira-service-desk jira-software jira-core
3 min read

Jira Service Desk: Help Center vs Service Desk

By Morgan Folsom on Sep 20, 2019 8:51:00 AM

When designing Jira Service Desk implementation for your organization, there are tons of choices that need to be made. One important decision during this process is determining how to break down your service desk - Will you have one Service Desk for all of the teams working in the organization? Or will you build out multiple service desks and use the Help Center to route users to different Portals? 

Note: On November 9, 2020, Atlassian announced Jira Service Management, the next generation of Jira Service Desk. Jira Service Management is an ITSM solution built on Jira to help IT, operations, development, and business teams collaborate at high velocity. It empowers teams to respond to business changes rapidly and deliver great customer and employee service experiences.

This decision will dictate both user and agent experiences working in the tool - so it's in everyone's best interest to consider as many factors as possible when making this decision.

But before we jump into the pros and cons, let's talk about the Help Center a bit.

What is the Jira Service Desk Help Center?

Jira Service Desk comes with the Help Center out of the box. The Help Center is an aggregated view of all of the Service Desks in that Jira instance. Customers are able to view the Help Center to search across multiple service desks and knowledge bases, see requests they've raised across all service desks, and much more. 

The Help Center may or may not make sense for your organization. Below are some things to consider when designing your organization's Jira Service Desk. 

Benefits of Using One Service Desk

Jira Service Desk comes with a ton of out of the box functionality that can help you group work in logical ways. 

  • The customer can never go to the wrong place - the experience is simplified because there’s just one portal.

  • Since all agents are working in the same place, there is clear visibility across teams, preventing silos. 

  • Requests, queues and SLAs are customizable based on teams or org lines - making it easy to determine who needs to work on the request.

  • All of your work is in one location, which means that finding issues in Jira is simplified.

  • Although all agents are working out of the same project, you can use issue security to lock down sensitive requests. 

  • JSD Reports are straightforward - because they are project specific, you can access them in one place to easily compare metrics. 

  • As an admin, everyone is using the same schemes - which means less effort to set up and less overhead to maintain. 

Benefits of Using the Help Center

If you decide that breaking up the service desk makes sense - you're able to customize the underlying schemes in each project, so teams can have different workflows, issue types, issue security etc. 

  • Schemes are customizable - so different teams can follow different workflows, permissions, etc. if needed. 

  • Each service desk can have no more than 50 queues - so if you've got a lot of teams working on separate work, you'll likely run into this limitation (but run into a fairly confusing service desk first)

  • Each service desk can have one set of customers who can see all of the requests - so the Help Center does the job if you need to restrict which requests customers can see.

  • With the integration between JSD and Confluence, you have the ability to connect knowledge bases to your portal. Each service desk can have only one knowledge base, and the Help Center allows customers to search across them all to find the relevant articles, while also viewing only the relevant articles when viewing from a specific service desk. 

Designing your Service Desk Implementation

As you can see, there are quite a few things to think about here. Designing your service desk implementation may be an overwhelming idea, so a good starting place is to consider the end-users. Knowing what you know now, think about who will be using the service desk (agent and customer), and what would make sense to them. Are there agents who will be working in multiple service desks - how would they manage their work? Is it clear to a customer which project they should go to, or which request they need to use? For more information on customizing your help center, read this article from Atlassian. If you're in the research stage of your Jira Service Desk implementation, read Praecipio Consulting's advice on Accelerator vs. Custom Implementation

Topics: blog implementation help-desk jira-service-desk jira-service-management
2 min read

Sprint Planning - How Long Should Sprints Be?

By Morgan Folsom on Jul 30, 2019 12:33:00 PM

Teams new to Scrum face lots of decisions - one key decision for teams to perform efficiently is determining sprint length.  

Scrum and Sprint Definitions

Scrum is an Agile framework that gives teams guidelines on how to complete their work. It contains sets of roles, ceremonies, and considerations for how your work is completed. 

A sprint is a concept in scrum that represents a time box - a short amount of time the team has committed to complete the work. Sprints can be as long as you want - however, it's most common for sprints to be between 1 and 4 weeks. Teams running scrum need to decide what makes sense for them.

What we often see is that team's first instincts lean toward the extreme: Either 1 week sprints or 4 weeks sprints. While there are arguments for the varying lengths of sprints, here are some common questions that you and your team should consider: 

Planned vs. Unplanned Work

If you are a scrum team that has high variability in your work, longer sprints may give you a necessary buffer. If you've got a one week sprint (with 1 of your 5 days already dedicated to ceremonies), even one or two unplanned pieces of work can prevent your team from completing the committed scope. 

On the other hand, if the team has unplanned work with a lower level of urgency, shorter sprints give you the opportunity to include the work in your sprint planning within a shorter time period. 

Time Dedicated to Scrum ceremonies

How much time per week should be spent doing sprint planning, retrospectives, backlog grooming, and demos? Shorter sprints mean more time is spent in these meetings. If you do not have dedicated roles (scrum master, product owner) this becomes even more essential. 

What we see in 1 week sprints is that teams can lose a full day (twenty percent of the sprint!) of each sprint to demos, retros, and planning. The shorter your sprints are, the more often you're having these ceremonies. 

Scope and Size of Tasks

Is your work small enough that it can be completed in the sprint length? If you are often not completing work in 1 sprint, a longer sprint may make sense (or you may just need to work on improving properly sizing your tasks).

Feedback cycle

How often do I want to see and evaluate completed work? Is it acceptable to go 4 weeks without a demonstration of the work that's being done? Do you need to know every week? Sprint length determines how often you'll see sprint demos and complete sprint retrospectives. 

Inspection and Adaptation

There's no one-size-fits-all answer to sprint length, and iteration is the key to scrum - so don't worry if your first choice doesn't work for your team. That's what your retrospectives are for, after all!

For more background on how we do agile, read our case study on how Praecipio Consulting takes on agile transformation

Topics: scaled-agile scrum
2 min read

3 Ways Atlassian Tools Help You Avoid Common DevOps Mistakes

By Morgan Folsom on Jun 4, 2019 11:42:00 AM

Using Atlassian tools for your DevOps endeavor sets your teams up for success. While there are many challenges in a new DevOps implementation, the tools you use don't have to be one. A quick search will show you that there are many ways to fail at DevOps - it requires massive organizational change and lots of moving pieces to function, so getting started can be tough. It might be a painful process to initiate, but as we've seen, it's absolutely worth it. With that in mind, while you focus on the big questions (Like how in the world can I deploy daily/weekly/hourly?), the Atlassian stack helps you out in some ways you may not have even considered. With one (or all) of these questions out of the way, you can get back to focusing on what matters: the people and processes that you're revolutionizing.

Below are a few common DevOps mistakes that Atlassian can help you avoid:

1. Failing to Automate Effectively

Automation is an essential component of DevOps - and one of the hardest. Rather than finding one product that tries to do a million things well, with the Atlassian stack you've got the killer combination of several awesome products that integrate seamlessly. The native integrations mean that in just a few clicks, your Bitbucket branch creation or pull requests, your Crucible code reviews, or even your Bamboo builds can move your Jira issues through their workflow. This is essential when you're working with several different tools - trying to keep track of where the work is will slow you down and has the potential to delay important milestones. Additionally, while the Atlassian tools work together like one product, if your team uses an alternative to one of the options, you can integrate them as well with the same ease.

Don't let your work tracker become just another bottleneck - make sure your tools are effectively integrated and refocus your energy elsewhere.

2. Ignoring HA Principles

The best systems aren't worth much if they're not up. When you're committed to High Availability (HA), you need your systems to be up as much as you (and your users) are - avoiding single points of failure, focusing on redundancy, and immediate failure detection. Jira and Bitbucket Datacenter products provide high availability so you can trust your systems will be up when they need to be (which is to say, always).

3. Mishandling Incidents

DevOps isn't just deploying quickly, but managing your code in an intentional way. This means making sure that if something goes wrong, you know it. Jira Service Desk has built in automation to keep work up-to-date and moving through its lifecycle. When you pair that with real-time build information, accurate visibility into things like pull requests and open incidents, then staying up to date is a breeze. Tracking incidents and development work in the same tool means you don't have to jump between issue trackers to know what's going on, and you can set up Jira Software and Jira Service Desk to keep everyone on the same page.

You'll often hear that DevOps is too focused on tools, and that you need to refocus on people and processes. This is absolutely true - the key is to work with tools that help you get out of your own way so you and your team can Get S@!# Done.

To read more about how Atlassian works with DevOps, read DevOps + Atlassian = Doing it Right by Senior Consultant Michael Knight or Top 5 Ways Atlassian Facilitates DevOps by Bryan Robison, Principal at Praecipio Consulting.

Topics: atlassian blog devops tips women-in-technology stem
7 min read

A Guide on How to Import Linked Issues into Jira from CSV

By Morgan Folsom on Nov 6, 2018 6:24:00 PM

This resource is for you if you've read Atlassian's documentation but are still confused on how to import linked issues.

Using the external system importer, Jira admins are able to import CSV spreadsheets into Jira to create new issues or update existing ones. This guide is an overview on how to use the External System Importer to create issue links. Note: This is not a comprehensive guide. Before reviewing this information you should understand Atlassian's guide on importing data from CSV. 

Requirements

Your file must meet the basic requirements described in the above-mentioned Atlassian reference material. For the different link types, any additional prerequisites are outlined below. 

How it works

When importing, each issue is assigned a unique ID, which is used when creating links. This ID can be the Issue Key, the Issue Id, or any Unique Identifier that you choose. Once the issues have been identified, you can link them in a variety of ways. 

What should I use for an ID?

  • Issue Key - Use this if the issue already exists in Jira. This is easiest if you are using data exported from Jira, as links export with Issue Key.
  • Other Unique Identifier - If the issue you're referencing doesn't exist in Jira yet, this is your option, which is particularly useful if you're importing linked data from another system that already has an ID assigned.

Examples

Sub-tasks and Parents

To create a sub-task/parent link, you use the Issue Id and Parent Id fields. Issue Id and Parent Id should each have their own columns in the spreadsheet. You can use whichever ID type you have decided on. In the below example, the issues are assigned consecutive numbers as IDs. This will work with any sub-task type issue types.

The spreadsheet should look something like this:

Issue Key
Issue Type
Summary
Issue ID
Parent ID
SCRUM-1 Story Ability to reserve an item for 2 hrs and return to it later 1  
SCRUM-2 Sub-task Create unit tests 2 1

When mapping the CSV columns to the fields:

Sub task and parent mapping in Jira

Importing Standard Link Types

If all of the issues in the spreadsheet are new (i.e., they do not exist in JIRA yet), you do not need to include an Issue Key. 

When importing issues using standard issue links (Epics, blocks, duplicates, etc.), you will follow a similar structure as before. You will still map Issue ID to a unique identifier, but instead of using Parent Id, you will use the specific link type. Each link type requires its own column, as shown below, allowing you to import multiple types of links at once. 

If any of the issues already exist in Jira, be sure to enter a value into the Issue Key field. You can import issues in any combination: whether all, some, or none of the issues already existing in Jira. 

Issue Key
Issue Type
Summary
Issue ID
Link "blocks"
Link "relates"
  Story As an admin, I'd like to import issues into Jira 123 456  
  Story As an admin, I'd like to link Jira issues 456   123

When mapping the CSV columns to the fields:

Importing standard link types in Jira

Here's an example of what one of the newly imported issues above looks like:

newly imported issues

It is important to note that Portfolio for Jira's parent linking functions differently than the standard issue links. Portfolio for Jira uses a custom field "Parent Link" to create the connection, and for this reason, it has different requirements for importing. 

For these links, you'll need to use the Issue Key, otherwise the field will not recognize any other IDs, which means that the issues must exist in Jira before you can create a Portfolio parent link via import. In this case, there needs to be a column with Issue Keys mapped to the Parent Link field. Note that all hierarchy levels above Epic use this same field, so you can have only one column. However, the Portfolio hierarchy must be respected; if you try to link an Initiative directly to a Story, for example, you will receive an error on import. 

The example below shows what it might look like if your hierarchy was configured as: Initiative - Epic - Story. The Epic would be linked to the initiative using the Parent Link field, but the Story is linked to the Epic through the Epic link. 

Issue Key
Issue Type
Summary
Link "Epic"
Parent Link
SCRUM-1 Story Make the server more efficient SCRUM-2  
SCRUM-2 Epic Blazing-fast server   SCRUM-3
SCRUM-3 Initiative World Class Product Experience    

 

Once imported, the issues appear in Portfolio like this:

Imported issues in Jira Portfolio

Now it's your turn to Import and Link!

Once you have your file prepped as described above, you can import issue links into Jira. If you run into any trouble, be sure to check:

  1. Your mappings -  Are the correct columns mapped to the right fields?
  2. Field values - Do I have the right values?
  3. IDs - Have I used the right type of ID mapping? 

As always, before importing large files, be sure to start with small amounts of data and test regularly. 

 

Now that you have your imported issues linked, feel free to check praecipio.com for other helpful tips on using the Atlassian tools.

Topics: jira atlassian blog how-to portfolio tips
4 min read

How to Report in Confluence with the Jira Issues Macro

By Morgan Folsom on Aug 27, 2018 11:00:00 AM

One of the most powerful integrations in the Atlassian ecosystem is the native link between Jira and Confluence. For users working in both tools, the transition can be seamless if you do it right, but clunky if you don't. 

Now, what if I told you there was just one Confluence macro you could start using today that will immediately make reporting in Confluence easier and help you (and your team) keep track of your work? The Jira Issues macro is the go-to when reporting in Confluence.

Here are some tips to get your team to live their Atlassian life-to-the-fullest.

Insert an issue count for a Jira filter

Let's start small. Insert a link to Jira with the number of issues returned from a Jira Query Language (JQL) query.

This is useful to pull up basic metrics for a high-level overview. The macro becomes a link to the filter, so if you want to review the issues in-depth, you can quickly hop over to Jira's issue navigator. The table below is an example of how our marketing team tracks employee blog post submissions.

 

To insert an issue count:

  1. Insert the Jira Macro
    1. Select the  in the top menu bar and select Jira Issue/Filter, OR
    2. Type { on your Confluence page, search and select Jira
  2. Enter in your JQL query
    1. To input an existing filter, type "filter = "Filter name", OR
    2. Type in the JQL directly
    3. Be sure to click on the Magnifying glass to execute the query
  3. Select 'Display Options' at the bottom of the dialog box to expand the options.
  4. Select 'Total issue count'
  5. Click Insert, and Voila!

Insert a single issue into Confluence

This macro can also link to a single Jira issue to a Confluence page. That means not only can you see what issues are important (and what status they're in) in your documentation, but you can also see who's talking about the issue when you're in Jira.

Take, for example, this blog post. My progress is tracked on a Jira issue, linked to this very page in Confluence. Below you can see how it looks on the Confluence page I'm writing in. 

If I click on that link, I'll move over to Jira where I can see all of pages in which the issue has been mentioned under Issue Links. Right off the bat, I can see that the issue has been mentioned on this page as well as another tracking Blog Content. 

To insert one issue:

  1. Insert the Jira Macro and enter in your query (steps 1 and 2 above)
  2. Select one issue from the list
    1. If you know exactly which issue, you can simply type the Issue Key into the search bar and hit enter. 
  3. Expand the Display Options and select 'Single Issue'
  4. Select 'Insert'

Use the Jira macro to insert a list of issues in a page in Confluence

Remember that filter you entered in above? You can insert that filter into your page, too. Filters inserted with this macro are dynamic - that is, as the issues are updated in Jira, the Confluence page will reflect the most up-to-date information. You can customize which columns appear in the macro just like you can in Jira. To head into Jira, you can select the individual issues, or click on the total number at the bottom ('2 issues') to pull up the query in Jira.

To insert a filter:

  1. Insert the Jira Macro and enter in your query (steps 1 and 2 above)
  2. Expand the Display options and select 'Table' 
  3. Edit the maximum issues and columns to display.
  4. Select 'Insert' to add to the page!

Create a Jira Issue from a Confluence page

If your issues don't exist in Jira yet, don't worry. This macro can create new issues in Jira if inspiration hits while you're editing a Confluence page. The issue will be created and you won't even have to leave the page. 

Additionally, you can also create issues from Confluence while viewing a page - simply highlight some text and then click on the Jira icon that appears.

  1. Insert the Jira Issue Macro
  2. Select 'Create New Issue' on the left panel
  3. Complete the form
  4. Select 'Insert'

This one macro can solve many of your reporting needs in Confluence. What's more, you can provide context around the data instead of just straight data. The Jira Macro is a great way to keep team members informed without navigating from Confluence to Jira and back again. 

Interested in learning more tips? Check out our blog Guide to Import Linked Issues into Jira from CSV.

Topics: jira blog confluence optimization process-consulting integration
4 min read

Five Ways to Make a Team Space in Confluence

By Morgan Folsom on Jul 16, 2018 11:00:00 AM

While creating a space for your team in Confluence may seem like a simple undertaking, creating one that users actually want to interact is far from easy. We know what can happen when you miss the mark: you've got a team space, but it's a mess - nobody knows where to find anything, there's no consistent structure, and nobody actually uses it. It’s not hard for a space to become a documentation black hole - documents enter, never to be seen again.

Confluence is an industry leader due to its revolutionary capabilities. A well implemented Confluence workspace breaks down team silos, is specifically geared for turning conversations between team members into action, centralizes all information in one space, and fosters and encourages a culture of open teamwork.

Here’s the good news: creating a team space doesn’t have to be difficult or time-consuming. With the right structure and out-of-the-box Confluence tools, you can easily create a space for your team that you don't have to bribe them to use.

5 Steps to a Collaborative Confluence Team Space

1. Create a landing page

The first page that you see when you go to your team space needs to be clear and appealing. If the space’s landing page is too cluttered, your user's eyes will glaze over before they get any useful information out of it. On the other hand, if the page is sparse with no useful information, why would they keep going?

For your landing page, you want to include information about the space: this is where you can throw in a bit of basic information about the team and its members, but you ultimately want to focus on what will be useful for your team. Using a Children Display macro on this page can give users a better understanding of where they can find information in the space as a whole. You can determine how many layers to show, and even include excerpts of the pages below. Similarly, you can link to commonly used pages or provide some navigation hints customized to your space. Now that you’ve got users in the space, you want to make the rest of the experience just as clear.

2. Establish a hierarchy

We recommend thinking about setting up the space as people will look at it - what do they see first? The top-level pages - so start there. They could be anything (and everything) from projects or training to team building. You’ll want to make sure you include any information you want your team to know, without flooding them with a ton of first-level pages. 

You can empower users to build this space with you by using the Create from template macro to help enforce your hierarchy. Including the macro on a high-level page allows your team to click a button to create the right page in the right location (if you customize your space templates, these pages can even include the correct macros and labels you need to report on them in other places). Once you've got an idea of how you want the space to be structured, you'll want to address the ever-important content that lives within the space (that's why we're here, isn't it!). 

3. Make it easy to find information

There are several things you can do right off the bat to keep users engaged and ensure they have what they need to do their jobs. Using the space shortcuts on the sidebar can call out commonly used pages - either in Confluence or external pages. Confluence also has some built-in macros that can improve your content with little effort:

Your pages look great, but who do you want to see them?

4. Restrict what you have to

Confluence allows permissions to be set by space and by page. This means you can lock down individual pages that may be more sensitive, and open up the important ones for viewing and/or editing by the team. Be careful not to lock the space down more than you need to - space and page permissions are great for security, but don't let them be a barrier to collaboration.

Once your space is set up, the next step is about keeping it simple.

5. Cut out unnecessary information

Knowing what doesn't belong in your team space is as important as knowing what does. We've all seen the overflowing wikis, filled with personal user notes or docs that have been around longer than you have. Personal spaces in Confluence are there for a reason - users can track information that isn't relevant to the team in their own space, without filling your space with irrelevant information. Archive information that isn't relevant anymore - Confluence pages track when they were last updated, and using the Attachment macro lets you track that for all of your space attachments as well.

Now you're ready to build out an awesome Confluence team space. Say goodbye to documentation black holes and e-mails from your team asking where to find information and hello to easy collaboration!

Still have questions? Let us know.

Topics: blog confluence teams tips collaboration consulting-services

Praecipio Consulting is an Atlassian Platinum Partner

This means that we have the most experience working with Atlassian tools and have insight into new products, features, and beta testing. Through our profound knowledge of Atlassian environments and their intricacies, we can guide your organization as you navigate these important changes.

atlassian-platinum-solution-partner-enterprise

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us