Morgan Folsom

Morgan Folsom


Recent posts by Morgan Folsom

3 min read

How to Effectively Communicate Across All of Your Tools

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

2021-q4-blogpost-Why more tools does not mean better communication_1

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 best-practices confluence workato workflows culture slack
2 min read

Work Should Be Pulled, Not Pushed

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

2021-q4-blogpost-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: 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

2021-q4-blogpost-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 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

Agile Tips: The Purpose of a Sprint Retrospective

By Morgan Folsom on Jun 1, 2021 10:15:00 AM

2021-q4-blogpost-Purpose of a Sprint Retrospective_1

A sprint retrospective is, in practice, a meeting scheduled after every 1-2 sprints in which the team comes together to discuss how to improve the way they work. The meeting can follow several formats, with the most common consisting of each team member sharing what is working well, what isn’t working, and any new ideas they have to improve. Some examples of takeaways from the meeting might be “Our daily standup is helping to keep everyone on track,” “We need a better process for reviewing tickets after QA is finished with them,” or “Let’s try estimating with story points instead of time values.”

Retrospectives were introduced to make sure the team is constantly in communication about how to improve. This process is commonly known as a feedback loop, and is one of the hallmarks of any good Agile process. Feedback loops have been discussed as one of the most important parts to becoming successful, either as a team or as an individual, a claim backed up by copious amounts of business literature full of research and examples on the topic. A prime example of this can be found in Talent is Overrated by Geoff Collins. While not a perfect book by any means, Collins does a wonderful job of explaining the importance of feedback loops. The argument posits that the way humans improve at anything is to do the thing, look back on the thing and analyze it, figure out how to improve performance of the thing, then do the thing again. The retrospective helps teams to do the middle two parts of that process.

Here are some tips for running a successful sprint retrospective:

Get on a consistent cadence

Doing retrospectives too often will lead the team to resent them. Doing them not often enough will greatly reduce efficacy and result in an inability to put into action the ideas brought up in the meeting.

Prepare ahead of time

Before the meeting, encourage team members to spend a half hour thinking of what is working well, what isn’t working so well, and ways to improve. That way the team can most efficiently use everyone’s time when they come together for the retrospective.

Bite off what you can chew

Instead of trying to implement all the new ideas after every retrospective, focus on determining which ideas are the quick hitters: those that have a big impact, but are easy and quick to implement. By adding the one or two best quick hitters each week, the process will evolve at a sustainable pace. Over time, the team will likely run out of quick hitters, giving you a chance to implement the more intricate ideas. 

Are you making the most out of your teams? If you need assistance with Agile, get in touch, we'd love to help.

Topics: optimization process process-improvement sprint agile
3 min read

Jira Service Management Request Types Best Practices

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

types-best-practices

Since 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 best-practices tips request jira-service-management
3 min read

Can a Product Owner also be a Scrum Master?

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: 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 tips training workflows configuration atlassian-solution-partner
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 confluence migrations server cloud data-center
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: flatwater-foundation do-good pledge-1% global-climate-crisis treefolks green-team
4 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. Contact us today to request a demo and receive more information.

Free eBook: 6 Steps to a Successful Atlassian Cloud Migration

Learn what to expect before migrating, how to avoid common mistakes during the migration process, and how Praecipio Consulting used these six steps to guide Castlight Health through a successful Atlassian Cloud migration. Download our 6 Steps to a Successful Atlassian Cloud Migration eBook here.

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

How to Solve Too Many Jira Email Notifications

By Morgan Folsom on Aug 20, 2019 8:03:00 PM

“Jira sends too many emails.”

When I tell people I consult on the Atlassian suite, this is usually one of their first comments. I’ve worked with many clients who set up filters in their inboxes just to reduce the amount of Jira emails they see. 

Getting Jira to send fewer emails is actually surprisingly simple. Here are 3 ways to do it effectively:

How to Create a Jira Notification Scheme

If you’re receiving too many emails from Jira, the first place to look is the notification scheme. Notification schemes tell Jira when to send a notification and to which recipient. For example, an effective best practice is to send an email to the Assignee when an issue is created. A good Jira environment, except in rare cases, will only alert users who are directly involved in the issue, such as the Assignee, Watchers, and the Reporter. 

To check your notification scheme, go to Project Settings, and then to Notifications. Make sure to note if the scheme is being used by any other projects so you don’t accidentally change any of that project’s settings.

Check if Add-ons are Sending Emails 

Automation for Jira (one of my all-time favorite Jira add-ons), Enterprise Mail Handler for Jira, or JEMH as it’s commonly known, as well as a host of other add-ons in the Atlassian ecosystem can be configured to send emails. This is a commonly used practice to get highly specific emails to a targeted audience. Visit the Add-ons (also known as Apps in some later versions) portion of the Jira Administration page and check out the configuration of these add-ons. You may find that there are outdated, redundant, or unnecessary rules resulting in extra emails.

A good way to recognize an email from an add-on is that it will typically not look like a regular Jira email. It may have different formatting, include different pieces of information, or have a note describing which add-on sent it.

Batch your Email Notifications

Starting in the Jira 8 version, Jira notifications can be batched. Batching email notifications means that changes within the same ten minute period will trigger a single email. Therefore, if a user updates an issue field, then adds a comment, then adds an attachment to the same issue within a ten minute time frame, only one Jira notification email will be sent, instead of three. You can read more about this behavior on the Atlassian Support confluence.

No Need to Stop Emails from Jira

Atlassian Jira can easily be an important application that is part of your daily workflow. Don’t let Jira take over your inbox - With these simple steps, you can take control of your Jira email notifications (and your sanity).

Interested in more Jira tips? Check out our blog “Guide to Import Linked Issues into Jira from CSV”. If you’d like more information, contact us today and our expert consultants will help you get the most out of Jira and your Atlassian tools.
Topics: jira best-practices how-to email-notifications
7 min read

Our Guide for Importing 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. 

 

At Praecipio Consulting, our team of accredited and certified Atlassian experts can help your organization meet its goals efficiently and succinctly. To learn more about how we can partner with your team, visit our Consulting Services page to explore just some of the Solutions we can help implement, or contact us directly.

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

5 Ways to Make a Team Space in Confluence

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

5 Ways to Make a Team Space in Confluence Header ImageWhile 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: 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

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us