Are you “penny wise, pound foolish? ”If you haven’t heard the phrase, it means that someone is careful with small sums of money but wasteful with large sums. Unfortunately, this situation happens when companies go through implementing and using an IT service management (ITSM) tool. Why? There are lots of places where a plan can get off track and end up costing your organization time and money.

This blog explains 4 mistakes your organization could make and how to avoid them. Additionally, it will help you avoid pitfalls where money is saved upfront in tool selection and implementation, but ongoing costs (including opportunity costs) are higher than necessary.

You might also like: ITSM, ESM, or SM? What is Service Management and How Can It Help?

Mistake #1: Not appreciating the total cost of ownership (TCO) of an ITSM tool

The critical thing here, whether using an ITSM tool for just ITSM or as part of a broader enterprise service management approach, is to appreciate that the “sticker price” of the tool is just a tiny part of the overall TCO. For example, there are also the:

• Implementation and set up costs, including process redesign, tool configuration, customization, and integrations
• Training costs
• Ongoing administration/management costs
• Ongoing support and maintenance costs (if an on-premises tool)
• The customer cost of upgrades, including changes to integrations.
• The impact of underestimating the TCO of an ITSM tool is that the above costs might not be sufficiently budgeted for with the associated activities minimized or omitted as a result.

One of the biggest mistakes we see is insufficient investment in tool implementation. Such that I’ll often state that “the best tools get bad reputations from bad implementations.” Failing to invest appropriately in tool implementation is likely to limit the usefulness of the delivered solution and the benefits realized.

Mistake #2: Making a tool decision based on price rather than value

This is an extension of Mistake #1, but given its importance, it deserves its own “time in the sun.” Here, choosing the cheapest possible tool that “does the job” might also bring with it additional ongoing costs that far outweigh the initial “sticker price” savings.

For example, an organization might not implement a tool to their specific needs to save money – installing a “vanilla” version. This then leads to the organization using the device to run counter to what it needs. Unnecessary costs are then incurred elsewhere, perhaps due to a lack of automation, and there are the opportunity costs of forgone capabilities (and the associated benefits).

Ultimately, the customer hasn’t spent the time entirely understanding the implications of implementing and then using the tool. Whereas engaging an experienced professional can keep organizations from stepping on easily avoidable implementation and cost, land mines.

Mistake #3: Not including enterprise service management needs into the tool selection process

Avoiding this mistake might also help your organization avoid Mistake #2 – with the various needs of enterprise service management and individual business functions helping to ensure that the selected tool has the required flexibility.

Notably, it’s about involving the relevant business stakeholders as early as possible in the requirements gathering/agreeing process. The IT organization shouldn’t be assuming what different business functions need from what will now be a pan-enterprise ITSM tool.

• Missing capabilities
• Difficulties in extending the solution to other business functions,
• Low adoption levels
• And more

Mistake #4: Sticking with an ITSM tool that’s unfit for enterprise service management

This one’s pretty simple to explain. It’s where – due to financial restrictions or the fear of change – an organization attempts to execute their enterprise service management strategy using an existing ITSM tool that’s unable to deliver against their needs.

It’s the proverbial “trying to fit a square peg in a round hole” – with it similar to the earlier mistakes in that your organization has an ITSM tool that can’t do what you need it to do. Or at least not without extra effort and costs. Here, even if ESM strategy execution is possible with the existing tool, it’s likely to be both suboptimal and more costly than it needs to be.

If you want to know more about avoiding these and the other common mistakes made when using your ITSM tool for enterprise service management, then reach out and talk to an expert.

Are you interested in enterprise service management but unsure how to generate buy-in from the rest of your organization? Then, we’ve got a blog for you here. Also, you can find 5 things to look for when selecting an enterprise service management tool here.

Enterprise Service Management solutions are beginning to make their way into every part of the organizational structure, breaking down silos and improving how teams work. Service Management uses IT Service Management (ITSM) capabilities in other business functions to improve operations and outcomes.

The best way to understand how Enterprise Service Management solutions can transform your organization is to discuss the value that a Service Management approach brings to your teams.

3 Benefits of a Service Management Approach

While Enterprise Service Management might still be relatively new in people's minds, despite being a "thing" for over a decade, ITSM has been evolving for over three decades. There are many reasons for its success, including the following benefits that apply to both ITSM and Enterprise Service Management scenarios:

1. Service-based thinking moves service providers from a supply view of the world to a demand-based view. This allows them to be better aligned with business wants and needs, including consumer-like services and support.
2. The use of best practice Service Management guidance – using ITSM bodies of knowledge such as ITIL 4 – helps service providers to optimize their service delivery and support capabilities. After all, we've discussed how ITSM and ITIL aren't that different. This framework will help your business function to be all three of "better, faster, cheaper" in terms of the better operations:
   • Providing better outcomes and service experiences
   • Realizing efficiency gains and reduced operational costs.
3. The consistency of operations leads to better outcomes and helps to improve employee morale and satisfaction.

These benefits are all then enabled and enhanced by using fit-for-purpose technology in the form of an ITSM tool that offers capabilities such as digital workflows, self-service, service request catalogs, knowledge availability, automation, and orchestration, collaborative abilities, and anytime and anyplace access.

Enterprise Service Management not only delivers optimized capabilities and a better service experience but also allows the service provider/receiver "dynamic." Service provider capabilities are now designed around the employee's needs rather than individual corporate service providers, such as human resources (HR), facilities, IT, etc.

6 Benefits of Using an Enterprise Service Management Tool

There are many enabling capabilities provided by an Enterprise Service Management tool, as outlined earlier, that can be directly translated into benefits for service requesters, service provider staff, and your organization as a whole. For example, employing fit-for-purpose technology allows you to:

1. Facilitate the optimization of practices/processes and the people that work within them. The available digital workflows allow work to flow faster, as do technology-enabled knowledge management capabilities. This results in better outcomes and experiences, with associated productivity improvements for both service provider staff and the people they're serving.
2. Offer a greater choice of access and communication channels to employees. With consumer-like omnichannel support available via chat (and chatbots) and self-service/help capabilities as well as the traditional telephone, email, and potentially "walk-up" channels. The use of self-service/help capabilities also increases the speed of resolution and minimizes the associated business function "handling" costs.
3. Help manage demand for service and support. With self-help and chatbots, along with knowledge management, in particular offering the opportunity to deflect new requests and calls for status updates.
4. Provide greater visibility into business function operations and performance, with the ability to better understand what has been achieved and what still needs to be accomplished. Plus, the identification of continuous improvement opportunities across operations, services, outcomes, and employee experience.
5. Offer improved collaboration capabilities. Making it easier for work to be passed between, or worked on collectively by, various people and even across teams in different business functions.
6. Provide a better return on investment (ROI) for the corporate ITSM tool. The more the ITSM tool – or what now might be called an Enterprise Service Management tool – is used to save time and money, the better the ROI for the tool.

ESM & AI

In addition to the traditional people and process technology-enablement, the growing availability of artificial intelligence (AI)-based capabilities in enterprise service management tools provides even higher levels of available benefits. For example, through intelligent automated ticket triage or chatbots as the first customer touchpoint. The impact of AI on enterprise service management will be covered in more detail in a future blog.

To Wrap Up

As you can see, the benefits of employing an Enterprise Service Management tool cover a broad spectrum of areas that impacts overall organizational performance. Like you, we examined business professionals about their adoption and thoughts regarding Enterprise Service Management tools. You can download the 2021 State of Service Management report here. Additionally, if you're still unsure if you should be calling it ITSM, ESM, or SM, you can check out this blog.

If we've convinced you that Enterprise Service Management tools can help you reduce friction, increase transparency, and increase your return-on-investment, then reach out, and we'll be in touch.

Jira is a great tool to help development teams manage their work. Because flexibility is one of many "flexes" (pun intended!) that Jira has, each Dev team can easily configure their boards to best suit their workflow. Jira currently offers two types of Agile boards, Kanban and Scrum. 

Scrum is a more structured Agile approach. Scrum sprints have a quicker cadence, which forces more significant projects to be broken down into smaller stories/tasks. In addition, planning, review, and retrospective meetings are spread throughout. Check out our Scrum Master Basics series to get the low down on how to become a Scrum Expert.

Kanban boards are all about remaining flexible and improving on the iterative process. As a result, Kanban boards are better for teams with various changing priorities and projects. Unlike Scrum, their sprints are less rigid in length and allow you to shape its structure depending on team needs. Learn how to set up the best Kanban boards here.

Both boards can use backlogs, but Scrum boards also allow the teams to track their work in Sprints. Keep on scrolling to learn step-by-step instructions on how to create a sprint in Jira and set your teams up for success with Agile project management.

Do You Have Permission?

Creating sprints is controlled by the Jira project's "Manage Sprints" permission. It is a good idea to limit how many users have this permission. Typically, this permission is reserved for Jira Admins, Project Admins, Product Owners, and possibly Scrum Masters. The "Manage Sprints" permission controls which users can create sprints, edit the sprint properties, start sprints, complete sprints, and delete sprints.

Creating a Sprint

Once you have the "Manage Sprints" permission and are ready to create a sprint, go to your board backlog and click Create Sprint. If you do not see the Create Sprint button, chances are you do not have the Create Sprint permission for that project. Check with your Jira Admin or request "Manage Sprints" permissions.

After you click Create Sprint, the Sprint will automatically be named after your board, Board Name Sprint 1, and each subsequent Sprint will increment the count by one. 

Starting a Sprint

Go to the backlog and look for the Start Sprint button when you are ready to start the Sprint. Traditionally, teams will only run one Sprint at a time. You can change this in the Global settings if your group allows parallel sprints. Once you click Start Sprint, a window will appear for you to check or set the start date and the duration.

Completing a Sprint

Complete the Sprint as scheduled. Any unfinished work or work not in the far-right Done column will be added to (rollover) the next Sprint. If future sprints have already been created, you will see the next sprint name. If no future sprints are available, Jira will create one using the Board Name and the next sprint count. There is a reason why they call it an Agile transformation journey.

The constant evolution of teams, marketplace demands, and business requirements is certainly an adventure. Let us be your guide as you navigate this journey! Reach out to us and see how we can help your organization implement best practices for building Agile teams.

Praecipio Consulting is frequently asked about migrating from various software version control systems to Git-centered tools such as Atlassian’s Bitbucket. Excellent news time: this is definitely possible and can be done in a painless fashion! Some organizations confidently plan and migrate by themselves. But … there’s always a “but” … be forewarned - there isn’t an “easy” button. Your success depends upon investing the effort, both in planning and in communicating with your teams. However, many organizations prefer using experienced 3rd parties who will focus on doing something not considered an organizational core competency. Praecipio Consulting often assists clients in their migrations: our approach is based upon proven tools and processes honed by multiple engagements over the past 15 years. 

Nonetheless, there still isn’t an “easy” button and the client’s involvement is integral to the final outcome as unique aspects are often uncovered.

If you still use Subversion - also known as SVN - as your software version control tool, you can be forgiven in believing that you’re alone. Searching the web yields many documents from circa 2012 which often containing phrases similar to “… 90% of developers have already migrated to Git …”. However, as recently as 2018, literature also indicates that SVN is still used because its users value its strengths over Git.

So say your organization has a business need to switch from SVN to Git. This might be because your organization has distributed development teams, or maybe the usage of SVN negatively impacts attracting new developers who expect a distributed version control tool such as Git or Mercurial.

Bottom line: you need to adopt Git and also migrate some or all of the information contained in SVN to Git; this blog assumes this means a codebase.

To better understand the implications of a migration - I suggest Stefan Holm Olsen’s explanation. Stefan led the migration of an 11 year old SVN, commercial grade codebase to a new Git codebase. All while continuing active development (https://stefanolsen.com/posts/migration-from-subversion-svn-to-git/ and https://www.atlassian.com/blog/git/atlassian-svn-to-git-migration-technical-side).

Atlassian documents a simpler case of a single SVN subfolder being migrated to a new Git repository (https://www.atlassian.com/git/tutorials/svn-to-git-prepping-your-team-migration) This may be sufficient for some do-it-yourself organizations.

In either case, it helps that the migration team understands how Git works and also the differences between Git and SVN. (If not, I suggest a quick detour to https://docs.github.com/en/github/importing-your-projects-to-github/working-with-subversion-on-github/what-are-the-differences-between-subversion-and-git and https://git.wiki.kernel.org/index.php/GitSvnComparison.) Most software engineers and developers are already familiar with Git - hence the examples address the potential SVN knowledge gap.

Stefan described a 5-step general process. The following 7-step process results from adding a preliminary step, because similar to Agile, the human aspect is primordial. Having an internal champion or two will certainly help increase the odds of a successful migration. An intermediate Git repo step is also added, although the brave may choose to go directly to the final destination. Like any undertaking, communications and scheduling are critical.

1. Plan your migration including the often overlooked human considerations:
    - What can remain in SVN? What can / can’t be lost?
    - Understand the impact to release notes and governance
    - Identify the impact to your CI/CD environment
    - Determine the timing of the actual migration (weekend, overnight, etc)
    - Train users on how to effectively employ Git
    - The comms plan: who’s communicating, how, and the regularity of the updates
2. Identify users and their correct names pre & post migration
3. Choose a location for your Git repository
4. Prune the SVN codebase
    - Address multiple folders in SVN repositories
    - Thoughtful pruning of folders, files, old and unneeded branches
5. Create an intermediate repository to support the migration
6. Migrate from SVN to the intermediate Git repo
7. Migrate from the intermediate Git repo to the target production repo

Migrating from SVN to Git should not be feared. There are known processes when migrating from source code systems. Some planning and a lot of communicating will go a long ways towards a successful migration. If you need an expert hand in planning and executing your migration, contact us, we would love to help!

Atlassian's Confluence is a powerful collaborative tool for teams to track information and content that may not make sense on a Jira ticket. One of the most powerful pieces of functionality in Confluence is the ability to use templates. While there are many templates provided out of the box, you also have the ability to create your own templates either globally or at the space level. Today we'll focus on creating a space template, and show you a few tips to get you started.Let's walk through some basics so you can hit the ground running on a space template.

Creating a Space Template

Before we talk about best practices, here's a quick overview on creating a space template.

The required permissions for creating a space template are Space administrator or Confluence administrator

An easy way to get to your space templates is to select the plus sign on the left navigation while viewing the space where you'd like to create the template.

Then simply select "Add or customize templates for the selected space" and it will bring you to the space administration page to work on your template.

Getting Started

Confluence is a great collaborative tool for sharing information, and templates should be used to make sharing that information easier.  When creating your templates a good best practice is to start with the end in mind.  When a page is created from the template, the page should be easy to read and the most important information should stand out. 

Now that you've got a blank template in front of you, think about how you want it to be used:

• What is most important about this page?  
• What info do we need to share/display?  
• Who is the intended audience?  
• Where would you expect to find the info you are looking for?

Once you've considered the above, we recommend starting with the layout. The template can be very easily organized using the page layout to space out information differently. Creating sections in the layout to divide up the information can be helpful when starting. You might end up combining some of the sections in the future, but this will give you some buckets to start sorting information into. On a similar note, we also have the Panel macro at our disposal. The panel macro provides a visible container for the information, and allows you to use color coded boxes and icons to call out specific information on the page.

Once you've sorted the information into sections, you can start guiding the user on how to fill out the template. We like to do this by using placeholder text. Placeholder text is only visible while editing the page created from the template, and can be used to provide tips to users (how to insert a macro, for example), or act as more detailed guidance on the purpose of the page.

Placeholder text can be added by selecting the + sign in the template editor, and selecting Placeholder text. Once inserted, it will appear as grey text, as we see on the right side of the page. 

Below you can see what that same page looks like when published - the placeholder text doesn't appear at all. 

Now what do I do?

The hardest part is over - you don't have a blank page anymore! Now you can explore things like macros, tables and labels to spice up the template even more. If your team is working with Jira data, don't forget you can use a Jira Issues macro to display it in Confluence. If you need to think bigger, check out our blog Five Ways to Make a Collaborative Team Space in Confluence.

And if you still have any questions on anything Confluence or Jira, or want to find out how to make your company the best version of itself, contact us, and one of our experts will get in touch!

So, your organization is investing in an Enterprise Service Management (ESM) strategy. It’s a great move! But could it be doing more? Well, if your organization is doing what most organizations do, the short answer is a resounding “yes.” Now, you might think that the opportunity here is the wider use of IT Service Management (ITSM) capabilities across your organization – in other business functions – which will, of course, be beneficial when executed well. But instead, I’m referring to the wider use of available ITSM best practices. Especially since the new version of the ITIL ITSM best practice guidance – ITIL 4 – introduced so much new Service Management guidance.

Looking at Service Management adoption levels

The world of ITSM doesn’t see as much statistical data as it used to, unfortunately. This is also true for Enterprise Service Management, where any adoption-level statistics usually refer to how many organizations are “doing” ESM.

This, however, is a difficult percentage to pin down because of the likelihood that apples are being compared to oranges rather than other apples. For example, the corporate ITSM tool might be used by another part of the organization to fulfill a need, but there’s no Enterprise Service Management strategy. Or where there is a strategy being executed, it might be for half a dozen other business functions, but it could also just be for just one. It’s very similar to where an organization can quite rightly say that it has adopted ITIL when it’s simply using a small part of just one of the 34 management practices in ITIL 4.

What’s more interesting and relevant for this blog post is the relative level of ITSM/ITIL process adoption as part of enterprise service management strategies, i.e. the ITSM capabilities that are more likely to be shared and perhaps adapted for other business functions such as human resources (HR), finance, legal, facilities, security, procurement, and customer services/support.

The adoption levels of Service Management processes by other business functions

During Praecipio Consulting's recently published State of Service Management survey, we saw fairly broad adoption of some Service Management practices outside of IT. In fact, more than half of respondents told us that the top six practices were implemented in their organizations. That's a great improvement from previous surveys on this topic, but it shows there's still plenty of room to apply the power of the other Service Management practices. 

To download the entire report for a detailed look into Service Management adoption across a wide variety of organizations, follow this link:  2021 State of Enterprise Service Management Report - Praecipio.

Of course, the above percentages are also influenced by the relative adoption levels of each ITSM capability by IT organizations themselves. For example, if only 60-70% of IT organizations claim to employ problem management best practices, then it’s highly unlikely that the third of organizations that don’t use it would try to share the capability with other business functions.

The key focus is that Enterprise Service Management strategies or approaches are sharing ITSM capabilities that can be considered the domain of the IT Service Desk, such as the ability to deal with requests for help, information, service, and change, all while enabling capabilities such as knowledge management, self-service, and workflow automation/platform-based capabilities.

Hence, while we talk of Enterprise Service Management as the sharing of ITSM capabilities with other business functions, it’s only a small subset of ITSM capabilities that are commonly shared. And organizations and their various business functions could further benefit from the greater adoption of other ITSM capabilities.

Taking enterprise service management beyond the service desk

There were many opportunities to extend the use of ITSM, or ITIL best practice in particular, with ITIL v3/2011. The introduction of ITIL 4 not only increased the guidance content from 26 processes to 34 management practices, it also:

• Presented the guidance from a Service Management, rather than an ITSM, perspective such that it’s more easily understandable and accessible outside of IT
• Built the guidance around the concept of the co-creation of value through Service Management

The latter of these in particular is something that should now be included in the extension of Service Management capabilities – including the use of ITSM tools – to other business functions. The obvious caveat is that it’s highly unlikely to happen without IT itself transitioning from ITIL v3/2011 to ITIL 4 first.

This future transition offers up a suitable decision point for the ongoing focus of an organization’s Enterprise Service Management investments: if the IT Service Desk’s capabilities are changed in light of the new ITIL 4 guidance, then the same would also benefit the other business functions that currently operate their variants of the original ITSM capabilities. It’s also a great opportunity to understand which other ITSM capabilities – both old and new – would additionally benefit the operations and outcomes of these business functions.

Examples of enterprise service management beyond the service desk

Even before the release of ITIL 4, some existing ITSM/ITIL capabilities were readily suited for and would have benefited other business functions. Problem management is a good example, with Customer Service/Support departments and Facilities teams able to employ similar problem management capabilities to IT – across people, processes, and technology – to identify and remove the root causes of regularly seen/reported issues.

Another good example is Continual Service Improvement (CSI) – which is now simply “continual improvement” in ITIL 4. After all, every part of your organization would likely benefit from having a formalized approach to the improvement of operations, services, experiences, and outcomes.

With the broader scope of ITIL 4, there are many additional practices that can be shared with other business functions to drive improved operations and outcomes, such as organizational change management, risk management, service design, strategy management, and workforce and talent management.

So, your organization’s Enterprise Service Management strategy could encompass far more than the IT service desk elements of ITSM – where the benefits outweigh the costs.

Hopefully, this post has you thinking about your organization’s current Enterprise Service Management successes and the potential for even more going forward. If you would like to find out more about the opportunities to improve the operations and outcomes across your entire organization - or if you need to get started with Enterprise Service Management - get in touch with us at Praecipio.

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.

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.

No, seriously: can we please take a moment to talk about spreadsheets? I have a very large bone to pick with them. Spreadsheet is a four-letter word to me; and don't get me started on workbooks! I recognize spreadsheets have their place in the world. I'm always in awe when I see the most complicated and fragile spreadsheet being used to manage a simple set of data to provide "insights" into the business. Even better, a spreadsheet that helps manage prioritization, planning, and execution reporting on a regular cadence. I've seen complex CountA and SumIf formulas, and Concatenate, and pivot tables, and everything else people can throw at them. And while I'm impressed at the craftsmanship, I'm also incredibly frustrated. The time it took to create and iterate on that reporting could have been spent having conversations about the work or checking in with a team or removing blockers. Instead, the extraction, manipulation, and reporting of easily-accessible, real-time data takes precedent. 

While it was published in 2014, I still reference an article when discussing data and reporting with our clients: This Weekly Meeting Took Up 300,000 Hours per Year. Yes, you read that right: 300,000 Hours. Per. Year! A single team extracting data, then aggregating it across several teams, then teams of teams, then programs, then everywhere else, all to be reviewed in a 30-minute executive meeting where the conversation was, "Are we on track? Yes? Great."  <sends weekly update deck to recycle bin>.

I hold no ill-will to the spreadsheet warriors out there. Instead, I view it as a simple case of "We've always done it this way." Well, what if I could show you a different way? What if, through the power of Atlassian, I could provide you real-time analytics? What if I could show you how to integrate Jira with a Business Intelligence solution? Or provide Program and Portfolio Management including planning and execution data in Advanced Roadmaps or Jira Align? How many hours would that save you or your organization when providing in-depth analytics to executive management? I promise you, this is all possible. 

Individual Team Metrics: Scrum and Kanban

Individual Team metrics are available for both Scrum and Kanban Teams under Reports in a Jira Software project. For Kanban Teams, both the Cumulative Flow Diagram and Control Chart provide flow metrics for the Team. While it may have been a while since you've taken a statistics class (if at all...I confess I tried hard to avoid them), spending ten minutes reviewing these reports will provide information on bottlenecks, flow trending, and backlog growth. Adding Quick Filters to your Kanban Boards will allow you to drill down into a specific subset of data on your board. Want to focus on Stories or Bugs only? Create the Quick Filters. 

Scrum Teams have nine (yes, NINE) reports available on their boards. Are you using the Burndown during your Daily Standup? Can you predict your release of an Epic or Version based on the throughput in those reports? Have you reviewed the Sprint Report to see what was added or didn't complete during the Sprint and asked why? The Scrum Reports will tell you what is happening during the Sprint (or happened, during the Retrospective), but it's up to you and the Team to ask why it happened. 

Need additional assistance to understand what these metrics are telling you? There's a training class for that. Praecipio Consulting is happy to help!

Program, Product, or Teams of Teams Metrics

Client: "Hey, Amanda, we're pretty good on the individual team stuff. Is there another way we can aggregate team data together?" 

Me: "How much time you got?" 

Three solutions come to mind for this one:

First, let's talk about Advanced Roadmaps for Jira. As always in the Atlassian tools, flexibility is key. When creating a Plan in Advanced Roadmaps, tying the work to the Teams by pulling in the scope of work is the first step. Whether it's a Board, a Project, or a Filter, aggregating data across multiple Teams, then tying the source to the execution team, provides you predictable velocity and capacity planning as well as execution reporting. 

• You want Progress? You got issue count and story point or time-based progress.
• You want to predict a milestone (read: release) date? You got milestone dates.
• You want dependency maps? You got dependency maps.
• You want to look at the Plan in a capacity view or a release view or a specific timeframe? You got custom views. 

Sharing all this information from Advanced Roadmaps in Confluence is amazing. While native in Confluence Cloud Premium, you can download and install the free app from the Atlassian Marketplace for Data Center. If you would prefer to simply share a link to the specific view of the Roadmap, that's available to you as well. 

Second, EazyBI. We constantly hear of clients looking for a more robust way to cube and concatenate data across their Jira instance. However, our clients tend to revert to what's comfortable: the spreadsheet. Instead, using an OLAP analysis and multi-dimensional calculations, EazyBI can provide the complex reporting when Jira's native Reports and Dashboards just won't do. EazyBI started as a purpose-built solution for Jira: it recognizes Jira's data structures and surfaces field data you may not be able to work with in native Jira. Since it's a unidirectional sync, EazyBI will not change your Jira data either. EazyBI can also integrate with other data sources including (sigh) a spreadsheet. 

Third, Jira Align. Here at Praecipio Consulting, we love Jira Align. The Program Room brings together all the information from multiple teams, i.e. an Agile Release Train. Every bit of data from Jira Software is aggregated to provide a clear understanding of the pace of the Train. The Program Board, the current implementation Roadmap with risk indicators, the investment data, the actual execution data, all of it is available in the highly-configurable Program Room. Burnups, Burndowns, progress by Epic, this is all available in Jira Align. In fact, there are over 180 reports available in Jira Align. And if that's not enough, Jira Align BI extends the already-robust reports into your existing visualization tools or your enterprise data lake. 

Enterprise Business Intelligence Integration

You may already have a Business Intelligence solution. Quite frequently at Praecipio, we hear our clients mention PowerBI, Tableau, or data lakes such as Hadoop or Snowflake. These powerful solutions are likely already embedded in your organization. And there's probably a SME out there just waiting to assist. Enterprise organizations usually have an integrations team to help connect Jira and other data sources. In fact, we worked with a large organization to consolidate Jira instances to better connect data to their business intelligence platform. In just 12 short weeks, they were able to analyze and report on their current execution progress simply by being able to feed consolidated Jira data into their business intelligence platform. 

At Praecipio, we have extensive integrations experience across a wide-range of technologies. We can recommend Atlassian Marketplace apps as a fit-for-purpose solution or we can work with third-party integration engines to help you map data for enhanced metrics. 

Take a moment to step back and really examine your use of spreadsheets. While, again, they have a purpose in this world, to a hammer, everything looks like a nail. The spreadsheet is dead. Long live the spreadsheet.

We think you may also like this webinar by the author: Proving Value: How Business Leaders Use Jira Align to Connect Strategy and Execution.

Welcome to Trello 101! In this post, we'll be talking about the basic functionality Trello has to offer that can get you up and running quickly and start managing work for you and your team. We will explore the basic features of Trello and define some of the terminology used. To help illustrate some of these points I've created a template board you can copy over to get started and use to follow along with.

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!

Migrating to the cloud can be a challenging move for any organization: there are many moving pieces to keep track of, and with the threat of negatively affecting both internal and front-facing operations, failure is not an option! Here are some key blockers to keep in mind when migrating to Atlassian Cloud from on-premise instances, so that you can review ahead of time just how prepared for a successful migration your company is:

• User Management
• Automations
• Size of Attachments
• Apps

User Management

User Management and how users are set up is a major difference when operating in Atlassian Cloud versus on premise. This is an important obstacle to understand and address, as the approaches for user management are different between cloud and on-premise. Key to this is how users are created and managed; equally important is identifying any users with missing or duplicate email addresses, since these cause problems with data integrity and users being able to use Filters and Queues in Atlassian Cloud. 

Automation

Automations are critical to research, as some automations may not be functional or even allowed in Atlassian Cloud: these will need to be identified and assessed to determine the balance between the value they bring and the level of effort of recreating them. 

Attachments

Size of Attachments becomes critical when using the Jira Cloud Migration Assistant, as this does not support migrating Jira Service Desk projects, which may require importing data via Site Import that forces attachments to be uploaded separately in 5 GB chunks, one chunk at a time. This alone will drive the migration of attachments to exceed a typical outage window, as the Site Import process must first conclude prior to uploading attachments. 

Jira Service Management utilization is tied to the size of the attachments as noted above. While JSM is used heavily it is currently not able to be migrated using the Jira Cloud Migration tool. With that being said this drives the use of site import. With this comes having to migrate the users and attachments separately. This becomes more moving parts during the migration outage and the coordination and timing will become even more critical.  

Apps

Jira Suite Utilities (JSU) / Jira Miscellaneous Workflow Extension (JMWE) / Scriptrunner are apps available in the Atlassian Marketplace that may be used in one or more of your current workflows. While these apps have helped to drive the creation of workflows and processes to automate certain transitions or enforce proper data collection, there is also no current migration pathway to Atlassian Cloud. While JSU has become part of the native cloud, JSU along with the other two apps must be manually fixed in all workflows migrated up to the cloud. You must run a query on your on premise data base to ensure you map out all transitions affected by the apps. Then once the migration to cloud is complete, they must be reviewed and recreated manually to ensure they are all working properly. Where possible utilizing the out of the box options, that mimic JSU, can help to move away from at least one app. 

Specific to Scriptrunner, one common scenario is the use of it in filters can cause them to no longer function, potentially causing boards and dashboard to render incorrectly. These filters must be rewritten using the Scriptrunner Enhanced Search functionality. One good example is any filter that contains the phrase "issueFunction not in" will need be rewritten as "NOT issueFunction in". It would be advisable, when doing the migration to Cloud, to open a ticket with the vendors for advise on how to fix scenarios with JQL that worked in Server/Data Center that no longer work "as-is" in Cloud.

Overall these key obstacles will get you on the correct path to understanding what you know will need to be done in preparation for starting the migration. This by no means is a complete list of the only obstacles that you can encounter, but we hope it will help you to be proactive in fixing obstacles before they become a blocker to the migration.

We are Atlassian experts, and understand how the move to cloud can be fraught with unpleasant surprises. If you have any questions, or are in need of professional assistance, contact us, we would love to help!

Have you heard of Jira Align? I feel like we've told you about Jira Align. Maybe a few times. We here at Praecipio can't say enough about it. Its ability to manage agile-at-scale for enterprise organizations is unmatched. 

When implementing Jira Align or expanding your footprint, however, it's important to understand the objects in Jira Align, as well as their definitions. It's also critical that your organization agrees on these definitions as a whole. With that in mind, let's discuss the Portfolio in Jira Align. What it is according to the product, and more importantly, how to define it in your organization. 

What is a Portfolio in Jira Align? 

A Portfolio supports a value stream. What is a value stream? It's a specific set of solutions that deliver value to your customers whether internal or external. Where a lot of organizations make mistakes is thinking that a Portfolio is a grouping together of projects that need to be complete in a fiscal year. There is no regard for strategic alignment to themes, no consideration for investments, and may follow a business-unit-esque structure. This is NOT how agile-at-scale frameworks define Portfolios, nor how Jira Align defines them. In addition, Programs (aka teams of teams or Agile Release Trains) support a Portfolio. This ties the execution to the strategy in Jira Align. 

In Jira Align, a Portfolio has the following things: 

• A Strategic Snapshot
• One or more Program Increments (PIs)
• A budget for the Snapshot
• Strategic Themes with allocation to PIs
• PI budgets established
• PI budgets are allocated across the Programs
• Blended rate established for the PIs
• PI budgets, per program, have been allocated to Strategic Themes
• Portfolio Epics are created and have been connected to a Strategic Theme, scored, swagged, budgeted, and targeted to one or more PI

Ok, that seems like a lot, right? And it is. In the words of Antoine de Saint-Exupéry, "A goal without a plan is just a wish." While you may have established goals (e.g. increase new subscriptions by 15% over last year), without tying goals to the PIs, allocating a budget, then creating Portfolio Epics, you have a wish, not a plan. 

How Do I Define a Portfolio? 

Depending on your organization, you may have to take a step back and really examine how you operate. There are many questions to ask your organization: how do we deliver value to our customers? Which programs support the value delivery? Are these programs truly cross-functional and able to deliver from idea to value in the hands of the customer? 

At Praecipio, one of our Portfolios is Client Delivery. This Portfolio delivers value to our clients by providing professional services around the Atlassian products and complimentary technologies. The solution (professional services) drives the definition of the Portfolio. Our Client Delivery organization is the delivery mechanism and is grouped into two delivery programs: technical and process. While these are not mutually exclusive, they do require specialization on the part of the teams depending on the services needed from the client. 

Can you break your value delivery, solutions, and execution mechanisms in the same way? If you're struggling to do so, it may be time to reevaluate your organization's definition of a Portfolio before defining it in Jira Align. 

Once the Portfolio is defined in plain language, then examine which Program(s) will execute against the Portfolio. Remember, a Program is a team of teams organized around the value delivery of the solution to your customers. The Program operates in their cadenced PIs, creates and ties Epics and Stories together to the Portfolio Epics to estimate and complete work. Without these links, you will not be able to understand your progress, investments, or overall health of the Portfolio in Jira Align. 

Reporting on the Portfolio

I know I've said this before, but there are over 180 reports in Jira Align. However, the most commonly used object is the Portfolio Room. There are three tabs in the Portfolio Room out-of-the-box: Financials, Resources, and Execution. In all three views, you will always see the Program Increment Roadmap. This gives you an understanding of the planning and progress of the PIs.

• The Financials tab provides Budget by PI, Estimates, and Actuals in a single glance as well as Theme Effort vs. Value and Theme Budget Allocation against the ranked Theme Priority. 
• The Resources tab provides allocated resources by theme based on estimated work in the PIs as well as team-week allocation Theme Effort Distribution against the ranked Theme Priority. 
• The Execution tab provides Theme Progress, Points, and team-week efforts as well as Theme Burnup based on the number of points accepted. 

Of course, the Portfolio room is configurable based on the KPIs relevant to your organization. And a Portfolio manager can drill into any or all of the items listed above in further detail either by a specific PI or multiple PIs. Simply update the Program Increments you'd like to focus on and the Portfolio Room will update the data specific to those timeboxes. While Jira Align will suggest reports under the Track section of the navigation menu, again, you can simply ask Jira Align to provide the report you need under the full Reports section. 

Jira Align makes it simple to understand the health of one or many Portfolios in your organization. Best Practice is to start with one, iterate until you get it right, then expand across other Portfolios when ready. Praecipio's deep expertise with agile-at-scale frameworks as well as intimate knowledge of Jira Align can provide you the needed support when you're ready to take your teams to the next level: check out our comprehensive whitepaper,  The Connected Enterprise: Close the Gap Between Business Strategy & Execution for a deep dive into how the tool can help you transform your organization or contact us and see if Jira Align is a good fit for your organization.

Jira has a multitude of ways to group and categorize similar issues, such as through projects, requests types, or components. Many of these are aimed at issues that exist within one project, though, making it a bit more difficult to track items across your entire Jira instance. This is where labels can shine.

Labels are basically tags on issues. If you have 4 different projects that may all see tickets related to the same customer, then a label for that customer would give you a great way to quickly gather an overarching view of everything that exists for them. You can also have multiple labels on an issue, allowing you to easily catch it in any number of buckets.

Like with many things in life, though, a watchful eye and steady hand are needed to really use labels effectively. With that in mind, we’ve identified a few best practices to help.

1. Labels should be used for informal grouping.

In other words, don’t count on just labels to be the driving factor of important reports or anything else you need to be accurate 100% of the time. Because new labels can be created by users from the issue screen directly, they are not and should not be viewed as a source of truth. They’re great at what they do, but be careful to limit the importance placed on them.

2. Try to limit the number of labels you have.

Labels are shared globally, which means the list can get very long, very quickly. To make them more effective, try to come to a consensus internally on the whens and whys of new labels.

3. Set up clear naming guidelines.

Limit the number of labels by making sure you have clear naming guidelines. This will be different from organization to organization, but we encourage you to discuss and decide on these guidelines early and to then check in periodically to make sure they're being adhered to. If you’re looking to label issues from ABC Law Firm, for example, you could quickly end up with labels for abc, abclaw, abc-law, etc. Without naming standards, you will dramatically decrease the efficacy of the labels as an informal(*) grouping tool.

4. Routinely clean them up.

Even with clear naming guidelines and a company decision to limit the number of total labels, you may still end up with some that are no longer relevant down the line. Set a regular time for somebody to go in, check them out, and determine if there’s any room for clean-up. Even better, cleaning up labels is as simple as entirely removing them from all issues, giving you the opportunity to swap them out for another if needed.

5. Don’t overuse them.

This one really echoes all of the points above, but it bears repeating: Don’t overuse your labels. If you’re looking for something to track issues for a very-important, super-vital, must-be-accurate report? Labels are likely not the answer. Have a certain issue type that can have 30 different permutations? Again, labels are likely not the answer.

Jira as a tool has many options for tracking related issues. And labels, in the right hands, can be a great means of doing just that — if they’re handled intentionally and in moderation. Don’t be scared to give them a try, but do keep these best practices handy to keep your labels as helpful as possible.

Contact us if you have any questions on labels, or in anything Jira: We are experts in all things Atlassian.

Let's make something clear: my.atlassian.com (MAC) is your best friend. Never heard of it? It's Atlassian's central license management platform. On the MAC website, you'll be able to see your license information and history, update technical & billing contacts, access license keys, and generate development keys. 

Over the last 6 years, I have helped hundreds of customers (from small businesses to Enterprise companies) with their license management. There are a few questions and frustrations that I see time and again, and based on that feedback, here are some of my top suggestions that will save you from future headaches.

Track your SEN’s

Your Support Entitlement Number (SEN) is a unique identifier that follows the life of the license. Even if the user tier or product name changes over time, your SEN never will. Consider it your “source of truth”. SEN’s can be found in your my.atlassian.com account, and are visible to all technical and billing contacts. I recommend sharing your SEN list with colleagues and procurement to make renewals more transparent. You can either export your license list from MAC, or include additional technical and billing contacts to open up visibility across teams and departments. 

Centralize your visibility

Once the Atlassian products gain popularity in an organization, I receive requests from different business units asking for their own instance or app for specific functionality. Logically, it makes sense to assign the technical contact as the person in charge of that instance or app. However, if you do that for each license you can splinter the visibility across the organization, making renewals complicated and time consuming.

I work closely with a global video game company who renews over 300 Atlassian licenses annually. Their organizing method has helped procurement streamline renewals, decreasing the amount of time it takes to identify who owns the license and what needs to be renewed. Each time a new license is requested I use the same technical contact email associated to the procurement department. After purchase is complete, procurement adds secondary technical contacts to the licenses in my.atlassian.com, giving the end user access to license keys. This allows procurement to see ALL licenses in MAC, understanding the entire license footprint and centralizing visibility when it comes time to renew.

Proactively transition your licenses

Life happens and people switch jobs all the time. I get a lot of requests from end users who inherit licenses but can’t see any of the licensing information or access license keys. How do you make sure the handoff is seamless before leaving? If you oversee the Atlassian licenses in my.atlassian.com, change the technical contact to the new employee information, or transition to another colleague who can retain access in the meantime. This will ensure continuity and give your organization a change management process for your licenses.

Co-term your end dates

Co-terming your license end dates can save you time during procurement cycles and allow you to plan for and estimate your annual licensing budget. If you have a variety of end dates it is best to co-term everything at once, allowing some licenses to be renewed for less than 12 months. Any new license purchased throughout the year can be co-termed (as long as the term is for 12 months or more). If this requirement makes the order too expensive, you can purchase your license for 12 months and realign to the co-term date on your annual renewal.

Co-terming is only possible for on-premise licenses (server and data center). Atlassian’s cloud licensing automatically “co-terms” the licenses on each cloud site to the same end date. However, at this time, if you have multiple cloud sites or Atlassian Access, they will have different end dates.

License Management doesn't have to be stressful: Praecipio Consulting's extensive experience can help you better navigate and manage your licensing landscape. Contact us, we'd love to discuss your options.

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, we have the experts that can help you implement ITSM best practices across your entire organization.  Contact us, we'd love to help!

When we're in the process of creating a product, we want to see the end result. We have a vision of what the product will look like and how we want to get there, so it's tempting to try to get the product running as quickly as possible. However, if and when the product breaks or needs to be updated, we are going to be responsible for fixing it. With that in mind, we look toward Test Driven Development (TDD). 

Nobody likes folding laundry. It takes time, and not everyone appreciates the results (at least not initially). The next morning is a different story: When you wake up to a crisp stack of folded shirts, choosing an outfit is easy - there's no rummaging through a laundry bin and you know exactly what's ready to wear. Sometimes, an initial time investment such as folding laundry, can help us out in the future.

Testing the Feature

We could test manually, going through our list of features and testing each feature to make sure the product is operating as intended. Or, we might write automated tests once the product is finished. But like rummaging through a laundry bin, working through this retroactively can be complicated and we may miss important information.

Many developers use TDD to prevent dealing with this "laundry". Instead of writing tests during the QA phase of development, developers write automated tests before anything else. Imagine a developer adding a new feature to software that allows the user to change the color of the background. The developer first writes an automated test to check whether the background color is changed once a button is clicked. The test may initially fail. They would then add the functional code and use the automated test to make sure the feature works.

Why would a developer want to spend extra time writing tests before building a product?

First of all, TDD keeps development simple and goal-focused. Features are added only when they can pass a specific test. This means that the developer has to make sure that each feature is necessary and the objective of that feature is clear. With no objective, it's impossible to write a test to pass your objective.

The TDD time investment leads to time savings in the future. Although it takes more time to include automated tests in the initial development of a product, there is potential for time savings in the future. When a product breaks, it's clear which part of the code is causing the failure. This means that QA may go more smoothly as bugs or product upgrades arise.

Conventional development vs. Test Driven Development. Using TDD requires an initial time investment but can lead to time savings long-term.

Of course, TDD processes aren't the best for every team. When there are too many possible test cases (often seen in GUI development) it can become impossible to write tests for every functional situation. Like any set of processes a team uses, think about what makes sense for your situation. Does the product have finite requirements? Has QA testing used eaten away hours of time due to buried bugs? Making an early time investment can keep things orderly. Even if your sock drawer is destined to be a mess, think about how you're building your products.

Want to learn more about testing? Book a technical call with an expert.

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!

The short answer: Not really. Stories and bugs are both software development items by different names. As such, the vast majority of activities and controls that we model for a story are applicable to bugs. The key distinction between stories and bugs often comes down to data. Bugs should include Affects Version/s, Steps to Recreate, Expected Behavior, and Actual Behavior. How and when we require this data relies on what practices we're observing.

For teams using Kanban practices where there is a Backlog status and a Ready for Development status, the transition to Ready for Development can be used to capture required data based on issue type. In this simple case, we would have two transitions from Backlog, Ready for Dev and Ready for Dev - Bug. For each transition, include a transition-specific screen to capture the appropriate fields.  Example: SDLC Ready for Dev - Bug Transition Screen will include: Affects Version/s, Steps to Recreate, Expected Behavior, and Actual Behavior in addition to any other fields needed in both cases. Then, leveraging your workflow conditions allow the Bug issue type to only use the Ready for Dev - Bug transition. All other issue types can default to the Ready for Development transition by explicitly checking that the current issue type is not a bug.

The considerations above work well in workflow cases where you have gated controls as a function of status change. This might apply to teams that include requirements definitions and design efforts within the story or bug life cycle (as might be the case with Waterfall). Additionally, this logical approach allows for workflow reuse which in turn decreases administrative burden and increases process consistency.

Scrum teams view Ready for Development a bit differently. Good Scrum practices dictate that product owners will refine their backlog as items are prioritized upward. Refinement provides all functional details necessary for the scrum team to be able to work the ticket including validation of bug reports and associated details. Once prioritized, the development team will review stories and bugs at the top of the backlog to make sure they understand the requirements. The work is considered Ready for Development at the moment it is accepted in to a sprint.

I hope this explanation helps you avoid unnecessary workflows!

Performance and uptime are crucial when hosting any application. For the Atlassian suite, the use of apps can have a major impact on these hosting aspects. There are many third-party developers as well as Atlassian developed apps that are available to be installed within the Atlassian tech stack. Depending on the app installed, each of these apps will have its own impact on the application and its health. Many apps that may be installed are considered lightweight and the impact would be very minimal; however, there are apps that are resource intensive and can cause significant impact of application performance. The apps that tend to cause the largest impact on application performance are those that allow customization of scripts and manipulation of data within those scripts, especially if these scripts are capable of running on a particular cadence or during certain issue functions. Other app types that are frequently found as the culprit for performance issues are those that return long running database queries. Common impacts from these resource intensive types of apps are high CPU usage and high memory usage. When either of these metrics begin to rise, the server is forced to work harder in order to operate the application, which then can cause the application to face performance degradation, manifested in slow page loads, timeouts, or outages. 

There are best practices you can implement in order to prevent your apps from having an impact on your application's performance. It is highly recommended that you install apps that are supported and developed by a trusted developer. Be sure to also read any documentation and truly understand what the app does before installing. It is extremely important that the apps are always up-to-date as well: apps may have bug fixes in releases that are ahead of yours, and even though you may not be currently facing any issues with your release, it is best to be sure you are on the latest version so that you can prevent any issues that may already be known by the developers. We also recommend that you thoroughly test any app you are considering installing within a non-production environment. Running User Acceptance Testing in a lower environment will allow you to capture any performance issues that may come from the app. Following this approach will strengthen your instance and help prevent any potential impacts your apps can have on your Atlassian applications.

If you run into any trouble with your Atlassian apps, let us know, we'd love to help you make the best of your tools.

Custom fields can be an over-looked configuration point in Jira, and it's easy to see why: they're easy to create, modify, and make available for your users. Although Jira ships with several system fields, it's inevitable that teams using Jira will reach a point where they require additional fields to input specific information into their issues. But in order to maintain Jira's performance as well as instance hygiene, it's important that Administrators take great care when it comes to custom field creation. That's why today we're sharing with you a few custom field insights we've gleaned over the years. Read on to learn three things no one tells you about custom fields. 

1. Technically, there is no limit to the number of custom fields you can have. BUT...

Custom fields do impact system performance in Jira. Below are some recent results breaking down each configuration item's impact on Jira. Here, we can see that custom fields have an impact on the speed of running a large instance. Your teams may feel this impact in the load time of issue screens. As an admin, one indication can be having a long page of custom fields to scroll through. Additionally, this is often accompanied by longer than usual load time for the custom field Administration page. 

To combat this, Jira Administrators should partner with the requestor and other impacted users to determine some guidelines for creating custom fields. For instance, requiring the requestor to submit an example of how they plan to report on the custom field or having the Administrator ensure the custom field can be used in the majority of projects (>=80%). Execution is crucial here: once the guidelines are aligned with management and stakeholders, it's crucial they are followed to prevent your custom field list from unnecessarily growing.

2. There are native alternatives to custom fields.

There are a few usual suspects to look for when reviewing custom fields. Duplicate custom fields ("Additional Comments" as a supplement to the "Comments" system field), variations of custom fields ("Vendor" vs "Vendors"), and department specific custom fields ("Company ABC" vs "Vendor") are a few custom fields that can needlessly drive up your custom field count. To prevent this from happening, Admins can offer their business partners alternative suggestions to creating a custom field by looking at the following:

1. Utilize an existing custom field that may be more general, but is fit for the purpose to get the most out of what is already in place.
2. Rather than implementing a custom field, Labels or Components can be used to help organize issues and categorize them for future reporting.
3. Apply a custom field context to help maximize the potential for picker, select, checkbox, and radio button custom field types. Adding field context enables Administrators to pair different custom field select options or their default values to specific projects or issue types within the same project.

3. You can proactively manage custom fields.

Rather than waiting for custom fields to pile on and create a lag on the instance speed time, proactively scheduling time to scrub your instance for stale custom fields will help Administrators keep on top of their custom field list. This can be a visual check to understand what fields aren't associated to a screen- those are good candidates for removal- or if there are similarly named fields- those can be good candidates for consolidation. More information from Atlassian on how to identify and clean up these fields can be found here.

Ultimately, a well-maintained Jira instance includes a good understanding of custom fields and their overall impact on the system. As your instance grows overtime, the guidelines around custom field development will become all the more important. Bringing these tips to life will help your instance run at top speeds for your users. 

Need help making the best out of your Jira instance? Our experts know Jira inside-out: contact us and we'll get in touch!

When thinking about Jira administration, or really administration of any software, project, or endeavor, the old idiom “too many cooks in the kitchen” often comes to mind. There’s a fine line between empowering your user base and setting the stage for mass hysteria and confusion within your instance. Fortunately Jira offers some out-of-the-box options to help with setting up boundaries for those users who need more control over the instance but keep them from wreaking too much havoc.

We’ll start with the bottom, Project Admins. There was a time in ancient Atlasssian historical records when those who were managing projects almost had to be System Admins as well. This was because the permissions needed to make necessary regular changes to the projects these individuals were maintaining required as such. Atlasssian has been improving upon this incrementally as of Jira 7. Since that update it is possible for Project Admins to add Components and Versions to their projects and even as of 7.3, expanded with 7.4, make adjustments to the workflow among other things. So if you’re evaluating your System Admin group and discover that many of the individuals are really only responsible for maintaining specific projects it would behoove you to re-assign those you can to the Project Admin role within the projects they are responsible and get them out of your kitchen.

The next level of administration is the Jira Administrator. Now this is where things can maybe become a bit confusing because the powers granted to that of the Jira Administrator are very similar to that of the System Administrator, but there is a very key distinction which we’ll explore. Those within the Jira Administrators group are not able to make changes related to the server environment or network. This would prevent them from making changes to things such as configuring mail server settings, export/import data to and from XML, configure user directories, as well as many more functions related to the system as a whole. Where this could be useful is delegating out some of the more regular tasks such as creating new projects, creating users, etc. This gives larger organizations a way to separate out the tasks without increasing the risk of potential hazardous changes to the application.

After having covered the last two, the final role should be somewhat obvious. The System Administrator permission is for the Grand Poobah of the Royal Order of Buffalos. This role allows unlimited access to all aspects of the Jira instance. It is recommended that only 1 - 3 people maintain this permission as needed. Again, the idea is to ensure that there is concise and regulated changes being made to the instance as well as accountability. With great power comes great responsibility. When in doubt, opt for the lesser of two evils when granting administrative permissions. You can always bump them up If it’s not serving your needs. Again, the goal is to empower your user base, not have them overpower you.

For question on admins, or anything else Jira, contact us, and one of our Jira experts will get in touch.

Permissions are one of the most important things to “get right” in Jira. Sure, having the right fields, screens, and workflows are all vital pieces of the puzzle as well, but they can easily be tweaked along the way. While permissions can also be updated as needed, a user who can’t see or edit the issues they need may have their work completely blocked in the meantime.

And then there is the group of permissions so important, so crucial, so absolutely imperative to get right that they earned a blog dedicated solely to them: the delete permissions.

“Well, of course,” you may be thinking, “everybody knows that.” But even if it may seem like common sense to you, it can easily slip through the cracks — it’s happened to others before, and let me tell you, it doesn’t always end well.

You see, delete permissions are so incredibly critical for one reason:

There is no recycling bin in out-of-the-box Jira.

This means that if something is deleted, whether through intent, accident, or malice, it’s gone. Poof. And while the loss of one item may be easy to recover from, the loss of tens, hundreds, or even thousands? Even I can feel the sweat dripping down your spine now.

So, to summarize: Delete permissions? Very important.

TYPES OF DELETE PERMISSIONS

To begin, it’s important to understand the delete permissions structure. Within Jira, there are four groups of delete permissions: 

• Delete Worklogs
• Delete Comments
• Delete Attachments
• Delete Issues

And then within those permissions, there are two types:

• Delete Own
• Delete All

DELETE OWN PERMISSIONS

The Delete Own permissions, as the name implies, will allow a user to delete content tied to their specific user account. These permission types exist for most of the above-mentioned groups, with the exception of Issues.

Delete Own Worklogs applies to any time that's been tracked to an issue, whether through Jira's native feature or through an app like Tempo Timesheets. As such, it is an innocuous permission and can be assigned to any users with access to a project, unless you have strict requirements otherwise. It will likely primarily be used for clean-up, and the ripples it can cause are limited.

Delete Own Comments is also often used for clean-up, and again, its area of effect is a bit smaller. However, just because a comment is deleted doesn’t mean that people haven’t already seen it, or even acted upon it. It may be better to instead point users in the direction of comment editing, or have them enter new comments entirely, even if it’s just to say, “Disregard the last.”

Delete Own Attachments is another permission that can be used for tidying. This feature might be useful were someone to, say, accidentally upload an adorable picture of their dog rather than a spreadsheet for the project. It’s fairly low impact as well and can likely be given out to any users within your project, especially if you’re following the Backup Rule of 3 or similar internally.

DELETE ALL PERMISSIONS

Each of the Delete Own permissions has a Delete All counterpart. Delete Issues exists here as well, though the naming convention differs from the other four. Delete All permissions give a user access to delete items associated with any user account. As such, we generally recommend these permissions are limited to only certain groups, such as Project or System Admins.

Delete All Worklogs, Delete All Comments, and Delete All Attachments can each only be performed in a single issue at a time. This barrier helps to protect against mass deletion, but in the interest of data integrity, you’ll still want to restrict who is allowed to perform these actions.

And as for Delete Issues? This will also give a user the ability to delete from within a single issue, but unlike the three mentioned above, this permission gives a user access to Bulk Change as well, which allows actions to be taken across multiple issues at once. As such, ask yourself if you even need to grant this permission at all. Sure, there could feasibly be a time when you need to mass delete issues, but it’s likely to occur so rarely that, should those stars align, the permission can be assigned when needed to system admins and then removed as soon as the job is done. This extra step will save you from being the organization that just lost a years’ worth of tickets. 

Remember: when something is deleted in Jira, it’s gone forever. This permanence can be a nightmare for many, especially those in organizations with heavy audit requirements. Rather than leaving yourself open to a very unpleasant surprise, do your team a favor and review your permissions now.

Stop worrying about Jira and make full use of its powerful features!  Explore more ways we can help your team succeed with our Consulting Services, or contact us with a question or request and one of our experts will be in touch shortly.

Atlassian's Jira is a powerful tool to promote best practices of internal processes and provide efficiency to development teams within your organization. The powerful nature of the tool is not only with the features offered by Atlassian but with a vast variety of options at your disposal to customize the instance. These customizations can come from the native features and options available as well as the apps brought to you via the Atlassian Marketplace. While these can all be great in building your Jira instance to get the most out of it, they can also have the potential to be detrimental to the health of the instance and negatively affect your organization's teams. 

Marketplace apps

Following best practices when configuring your instance as well as proper control over the integrations added to your instance is critical. If not properly managed you can experience system issues resulting in downtime due to a number of reasons but most commonly high memory or CPU. While installing apps through the marketplace may seem trivial and rather safe, keep in mind that each install of these apps does modify the database and can also be creating items such as custom fields in your instance. Make sure to properly vet all apps, check the reviews in the marketplace for any reports of impact to the instance. Also, review any documentation for the app to see how the application integrates with your instance. Most importantly it's highly recommended to install any apps in a lower environment (Dev or QA) before installing it in production. Thoroughly testing all new installs will give you the best idea of how the application will impact your instance once installed into production. 

Configuration

In addition to the configuration items created by apps are the ones created manually. Being mindful when adding items such as custom fields, statuses, workflows, etc. can save headaches long-term. It's important to reuse configuration items wherever possible. Having numerous, similar or duplicate, custom fields and statuses will create an administrative burden. Having a large number of these items will also have an impact on exporting issues and projects as well as for instance performance when loading reports, project boards, and dashboards. 

User Management

Proper user management will help to keep licensing costs to a minimum as well as give better control over access to the instance. Use groups wherever possible in permission schemes, boards, and filters. Provide only Jira administrator access and Service Desk agent licenses to those that need it. All users may not need Service Desk agent licenses and since these are billed separately in the instance, assigning all users to the Service Desk group can incur unnecessary charges going forward. Frequent review of active users is important as well. Based on business rules, users who have not logged in for some time (3 to 6 months) may be able to be made inactive. Frequent review of these types of users will also allow you to keep access to a minimum, save licensing counts, and in turn reduce user tier costs.

Stale Data

Review stale or old data is critical in maintaining a Jira instance as well. Instances will begin to grow over time and as your organization and teams grow, so will the ticket count in your instance. The larger the instance size, the high likelihood for performance degradation and instance issues. Analyzing your instance for stale old data is a key step in maintaining a healthy instance. For stale data, take a look at any unresolved tickets as well as any older tickets that have no resolution or that are not in a "Closed" status. You will also want to review any projects that have not had a ticket created in them for a long period of time (we generally recommend 3 to 6 months). After thorough analysis, you will want to close any stale tickets and archive any projects that are deemed to no longer be in use. 

Praecipio Consulting's Managed Services

Praecipio Consulting offers guidance and services to help maintain your Jira instance and provide you with industry best practices. Through years of experience, we at Praecipio have developed a wealth of knowledge in properly configuring and managing Atlassian products that will ensure you get the most out of the product for every use case in your organization. As part of our Managed Services offering, we deploy our proprietary Health Checks. These Health Checks include a thorough review of various aspects of maintaining your instance. Praecipio's Health Checks are split into two main categories: Infrastructure and Process; and include topics such as Licensing, Database Health, Security Vulnerabilities, User Management, Upgrade Readiness, Performance, Process Consolidation, Stale Data, apps/App and Workflows. With these Health Checks and working with Praecipio Consulting's Managed Services, your instance will be in an optimal state for growth and longevity.

"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!

Projects come and go, and sometimes what we once thought was a great idea may no longer be relevant or you've evolved your thought process. Since we're all undoubtedly great at documentation, chances are every one of your projects or endeavors has been noted or tracked in some fashion. Confluence, of course, is a great tool to do this with, especially if you organize your project all within the same space. But what do you do with that documentation when it's time to hang up the towel?

Usually, some record of your success or failure must be kept for posterity or perhaps, compliance. Whatever your motivations, archiving is important and Confluence allows us an easy way to do this natively. In this post, we'll focus on the native feature to archive spaces and also share some apps that could help you to organize archived content at the page level.

There are several reasons you might want to archive content in your Confluence instance, and it all depends on the life cycle of your projects or groups. To give an example, I worked for a game publisher for many years, and we would archive spaces after sunsetting (a term used to shut down a game product) one of our games. The major advantage to archiving is the content is still available in Confluence for reference purposes but won't show up in any page searches you perform nor will it appear in the Space Directory. This keeps your daily traffic from being cluttered with content from spaces that are no longer relevant to your business.

So you've reached a point in a project where it's officially time to move on, but the leadership team wants to keep the space for reference since some good ideas came out of the endeavor. Archiving the space seems to be the way to go, but how do you do that? Atlassian has put together a great document that details the steps for archiving in a cloud environment. To briefly summarize the process, you navigate to the portion of the space tools that contains the details and edit them, set the status to archived, and save. Pretty simple.

If at any time after archiving the space there is a request within your organization to review the archived content, you can link to the pages directly, and they will still be accessible. The search functionality within Confluence will automatically allow you to specify if you want to search through archived content in the case that the content available.

Atlassian also gives guidance on how to archive specific pages, which you can accomplish through a combination of manually moving pages and adjusting permissions to achieve similar results for the space archiving functionality. There are also third-party apps available, such as Better Content Archiving for Confluence, which gives you an increased toolset to make the archiving processes a bit less work. I recommend installing any third-party apps you wish to try into a dev or test environment before running on your production instance. One last thing to note, if you end up archiving a space accidentally or perhaps want to revisit an archived project and need the space to be active, you can easily change the archive setting to make the space available again.

If you need help managing your Confluence instance and want to learn how your organization can take full advantage of this tool, get in touch with Praecipio.

Are You Ready to Scale Agile? 

You are an Agile evangelist. You have championed the shift to Agile at your organization and have coached several teams successfully. Your organization is delivering quality product faster to your internal and external customers. But there's still a struggle to coordinate across different parts of the organization. And you get pulled into meeting after meeting to coordinate across teams. As a result, your most successful teams are expressing frustration with each other and, and now, quality has slipped. Something has to change. 

You've heard about scaling Agile. You may even have an idea of some of the well-known frameworks, such as SAFe, LeSS, Scrum@Scale, etc. But are you ready? Is your organization ready to scale Agile? 

Organizational Readiness

While this is not an exhaustive list, ask yourself and your organization these questions to assess your readiness to scale Agile. 

• Which framework is best for your organization?
• Do you have management and executive buy-in? 
• Do you have funding for external training and certification?
• Can you group teams together to support strategic initiatives?
• Can you identify your change agents and champions?
• Can you identify a set of teams to pilot the change?
• How much time are you willing to commit to the change?
• How much time do you have to commit to the change? 
• How much time are you willing to commit to continuous learning? 

Iterate Your Framework Implementation

Just like the scaled Agile frameworks themselves, you approach their implementation iteratively. One of our clients chose and implemented SAFe for a single program and scaled iteratively. They started with one Agile Release Train and in three years scaled to four Agile Release Trains with the intention to launch an additional train before the end of the year. They also reorganized the Trains once they realized they were no longer organized around value and instead were structured in a traditional resource-management way. 

The implementation of SAFe within this client's organization, while it had a specific start date, was implemented iteratively and over time. It also took the backing of management and executives and a devoted set of change agents willing to take the steps for scale.

We here at Praecipio Consulting have assisted our clients in their journeys to scale Agile. Let us know how we can help you take your first step. 

NOTE: Jira next-gen projects are now named team-managed projects, although all the valuable features that have made them an indispensable tool for managing your team's work for years remain the same.

Atlassian has always held the concept of the team in high regard. As you may know, even their stock ticker is TEAM. And with many organizations pushing to Atlassian Cloud from their Server or Data Center solutions, it's no wonder Atlassian is removing barriers to entry for first-time users and admins. Whether you choose Standard or Premium, Jira Software adds the ability to create next-gen projects.

What is a next-gen project? 

Jira Software next-gen projects are a simple and flexible way to get your teams working. With some limited delegated administration, next-gen projects are created using a pre-defined template (Kanban or Scrum). These projects also come with three pre-defined roles: Administrator, Member, and Viewer.

• Administrator: Updates project settings and can add other Administrators
• Member: Can perform most functions such as create, edit, assign, and transition issues
• Viewer: Can view and comment only

By default, if a user is added to the Jira Cloud site and provided access to Jira Software, they automatically become a member of every next-gen project (also known as Open). However, a next-gen admin can change the settings to be either Limited or Private. Limited puts all users of Jira software into the Viewer role and Private requires the admin to add a user to perform actions in the project. In addition, setting the project to Private hides the project from any search results. 

Each next-gen project operates similarly to a Classic Software project. You get either a Kanban or Scrum Board based on your project template as well as the reports you've come to know and love from the Server and Data Center products. One key difference is the addition of a Roadmap. Each next-gen project and board comes with a Roadmap. This allows teams to track start and end dates of the epics and better communicate with their product owners and stakeholders. 

The benefits of a next-gen project

Next-gen projects are flexible and delegate administration to the Administrators. This means the Administrator can create new Issue Types and Workflows, add unique fields, assign access to individuals or groups, and can enable or disable specific agile features such as enabling backlogs. This provides the ultimate flexibility for newly formed agile teams to work out their processes and data needs while performing their daily work. Let's take a closer look at each of these elements. 

Issue Types can be created on the fly at any time. As an Administrator, you can add up to 30 unique issue types to your next-gen project. By default, next-gen projects come with Epics, Stories, Bugs, Tasks, and Subtasks. If you remember, these are arranged in a loose hierarchy with Epics at the top; Stories, Bugs, and Tasks in the middle; and Subtasks on the bottom. Currently, any additional issue types will be added at the same level as Stories, Bugs and Tasks. If you'd like to add your own Subtasks or parent issues, feel free to submit feedback to Atlassian. 

Workflows are configured directly on your Board. Simply add a column to add a status to your workflow. That's it. You may also add rules such as assigning an issue or updating a field. Other Marketplace Apps can add automation triggers and the like to next-gen projects as well. 

Administrators can also add Custom Fields for your project. While Jira already comes with a robust set of Jira-created fields, you may choose to add checkboxes, people fields, numbers, dates, dropdowns and more. You can even change the order of the fields on the issue view to put the most important information at the top. 

Notifications on certain events can also be tuned to suit the team's need. For those already familiar with notifications, these events include: Issue Created, Issue Updated, Issue Assigned, Issue Deleted, etc. In a next-gen project, you can notify All Watchers, Current Assignee, Current User, Reporter, or a Project Role. Simply select the event and the people you'd like to notify, and Jira will take care of the rest. 

Last, but not least, there are nine separate Board features you may choose to enable for your next-gen project. This includes things like the Roadmap, Reports, Backlogs for Kanban, and more. 

There's no doubt that next-gen projects provide your team the ultimate flexibility in managing their work. With easily navigable menus and a simplified Administration interface, next-gen projects can be great for you and your team. 

The disadvantages of a next-gen project

One of the things we love about the Atlassian products is that they are super flexible and you can do pretty much anything you'd like with them. One of the things we hate about the Atlassian products is that they are super flexible and you can do pretty much anything you'd like with them. The same is true of next-gen projects. With ultimate flexibility and delegated administration, it becomes difficult to aggregate data across multiple projects. As a product manager, project manager, Release Train Engineer, or other person over several teams, you may find next-gen projects frustrating. 

Because the configuration of a next-gen project is unique to the individual project, gathering a status update is difficult. Not impossible, but you need a solid working knowledge of Jira Query Language (JQL) and good discipline from your teams to ensure they're transitioning tickets through the workflow. Creating custom Filters and Dashboards is your only way to aggregate data across projects. In addition, since each team can create their own custom fields, you risk data bloat. For example, one team may create a field called Bug Type using a dropdown and another may create Bug Type using checkboxes. While both are correct, to understand where Bugs are located, you have to add both fields to your filter. And the values may be unique per project as well. 

Work can only be estimated in Story Points, regardless if your project is Kanban or Scrum. This is also regardless of Issue Type. If you enable estimation on either a Scrum or Kanban next-gen project, every piece of work should be estimated and estimated in Story Points. Tasks, Bugs, and Stories all need points to establish a consistent velocity for predictability. 

Since there is a single workflow for all Issue Types, the team cannot split processes between types of work. If a Task follows a simplified process (To Do, In Progress, and Done), but a Story needs more detail (Backlog, Selected for Development, In Progress, and Done), the team cannot split these items into two distinct workflows. Every type of work must follow the same path through the board. 

There are additional technical considerations as well for things like Cloud merges (bringing two instances together) and Cloud to Server or Data Center migrations (moving off Atlassian Cloud to an On Premise solution). While these efforts are few and far between, all next-gen projects must be converted to Classic projects before these efforts start. 

Are next-gen projects right for you? 

At Praecipio Consulting, we believe you must use the right tool for the right job, and the same goes for next-gen projects. That’s why our team offers a variety of Product Services to ensure that your team can leverage these tools as effectively as possible to meet your goals. 

Not sure what exactly your team needs? Contact us today and we can talk about what strategy would work best for your specific needs.

Michael Porter, a former Harvard professor, is one of the founding fathers of business strategy. He lent credence to the field by developing several ideas, frameworks, and theories around strategy that have been utilized, debated, and taught for four decades now. You may be familiar with his 5 Forces model, which is used to analyze the competitive landscape of a given industry, or his course titled “Competition and Strategy”, a requirement for all first-year Harvard MBAs. Though his ideas and theories are certainly not perfect and have evolved over the years, they laid the groundwork for modern businesses to think about their strategy, their position in the market, and their ability to move forward.

And when you think about it, it’s weird that some consider Enterprise Service Management to be a new business process management trend. Let me explain. 

In 1985, Porter co-authored an article with Victor E. Millar in the Harvard Business Review titled “How Information Gives You Competitive Advantage”. In it, he laid out a central argument that said with the explosion of computer usage, companies would have access to a ton of information, flowing freely through the organization, that would allow managers to make more informed decisions faster. This, Porter argued, would fundamentally change how business was done and provide new ways for companies to stay ahead of their competitors. 

Consider this excerpt from Porter’s article:

“The value a company creates is measured by the amount that buyers are willing to pay for a product or service. A business is profitable if the value it creates exceeds the cost of performing the value activities. To gain competitive advantage over its rivals, a company must either perform these activities at a lower cost or perform them in a way that leads to differentiation and a premium price (more value).”

In other words, to gain an advantage over competitors, companies must perform their value activities at a lower cost or in a way that adds more value. Porter foresaw the drastic increase of information that would be available to businesses with the shepherding of the digital era. He logically concluded that such information, if used and communicated correctly, could be advantageous to managers looking to make decisions around the value-added activities in which their business engages.

The prediction of a sharp increase in the amount of information has certainly come true. In the era of big data, companies gather, store, process, and use more data than ever before. The problem is that typically this information is siloed, only about one particular subject, or only accessible and understandable to a few highly-skilled workers. This is the problem that enterprise service management will solve to bring Porter’s 35-year-old vision to fruition once and for all.

Enterprise Service Management (ESM) holds that the (mostly digital) processes that have been championed and used to gain efficiencies by IT teams for so long apply to the business as a whole, as seen by the adoption of similar processes and technologies in departments like HR, Facilities, and Procurement. ESM suggests that an organization should have a tool, which typically takes the form of a piece of software, that allows information to flow easily, quickly, and freely through the organization (sound familiar?). At Praecipio Consulting we have grown fond of referring to this as an operating system for business - one central piece of software that is used nearly ubiquitously in the organization, one that allows work to flow from division to division, team to team, teammate to teammate, with no loss of information and an attached, rich history.

Consider the typical lifecycle of the development of a new offering by a business - whether that be a software feature, physical product, or a new service offering. Marketing will research the market and determine where gains can be made. They will pass intel along to Product, which will develop these insights into a new product idea. The Product team will work with Development to create requirements, Dev will build it, QA will test it, and then it will be released to the market. Along the way, Marketing will generate buzz, Sales will sell, Legal will validate legality, HR will manage employees working on the offering, so on and so forth. In short - it takes a village, a coordinated effort among teams from different parts of the organization to deliver the new offering to market. 

The logic of a single system which transmits work in this lifecycle with no loss of info and rich history is apparent, as is the cost savings garnered from a single license paid to a single vendor, maintenance and training for one system instead of several, and usage of an efficient process unmarred by clunky handoffs to other systems.

To achieve this business process nirvana, we have long advocated for the usage of Atlassian’s Jira, Jira Service Management, and Confluence products. Similar to Apple, Atlassian set out to develop products that work together seamlessly, but unlike Apple, Atlassian has retained that characteristic and further developed it to the point that these three products work together in harmony. The malleable and flexible nature of these products has helped them evolve from those used exclusively by software development teams for bug tracking to those used by IT, HR, Legal, Marketing, Customer Service, and several other business units. The ability of these products to merge these disparate units within a business shows an exciting step forward and potentially a culmination in Porter’s vision of a connected and integrated business.

In the next articles that will form part of this ESM blog series, we will further explore the logic and numbers behind enterprise service management, and why and how it can help your company. 

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.

“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).

HipChat has long been the beloved messaging application for Atlassian users, developing integrations with Confluence and Jira to increase the seamless nature of the SDLC process with notifications and team and project-specific rooms. With the success of these integrations, Atlassian is raising the bar for HipChat functionality, offering up their API for other software producers to code their own connections to allow even more tools to team with HipChat. Recently, Atlassian held a HipChat Dev event in San Francisco for a handful of popular and innovative tech companies to dev and demo their HipChat plugins, opening the door for an all new level of HipChat functionality. New Relic, Salesforce, Tempo and other Atlassian-inclined software makers came together to tweak the HipChat API to get their products talking for an even more robust integration offering in the messaging system. With many new options becoming available, excited HipChat users can expect to see these plugins available soon, making HipChat a real-time communication hub for all aspects of the software development life cycle.

HipChat, Meet New Relic

New Relic, maker of integral tools to gain insight into the operation of your business processes, becomes a critical component of IT management when paired with HipChat. Using New Relic products like APM, Browser and Synthetics, companies gain real-time analytics for their SaaS applications to ensure that their platforms are running optimally for the best user experience. When integrated with HipChat, New Relic provides teams regular status updates, allowing issues to be addressed efficiently and expediently. Create a HipChat room for New Relic applications and stay up to date with your application performance leveraging the constant monitoring of New Relic with the constant communication of HipChat. 

Build Your Own Add-Ons

Atlassian enables users of Jira, Confluence, and yes- HipChat, with the ability to build customized add-ons for Atlassian tools and corresponding applications. The provided documentation allows the use of any web framework and any programming language to build with Atlassian's REST API to get the applications talking with remote operation over HTTP. With the unlimited possibility of integration, HipChat becomes a true force of functionality as more and more applications are tied into the tool. Give each dev team their own HipChat room built around their products to get the latest updates on their in-flight projects. Create a marketing room to allow your bloggers to see immediately when a new page view or comment comes through. With HipChat customized add-ons, your teams get the information they need, when they need it. 

Video courtesy of Atlassian

It's in the Numbers

Need more reasons to expand your company's collaboration beyond just Confluence and Jira? Atlassian has the stats the make the case for HipChat!

Statistics courtesy of Atlassian

Chatting cuts down on unnecessary, efficiency-draining emails, enhances collaboration between teams and delivers a platform for easy communication. Using Atlassian HipChat, your teams run at the speed of business with application integration, video chatting, and file sharing -- everything they need to work smarter and faster! 

Get Chatting

Revolutionize the way your teams work with HipChat! It's as easy to get as it is to use; simply contact Praecipio Consulting to learn about our extensive HipChat services, including: managed services and hosting, implementation, customization and licensing. HipChat is your central source of better business practices and Praecipio Consulting is your one-stop-shop for all your HipChat needs. Collaboration has never been easier, so get HipChatting today!

No matter the size of your organization or your industry, the end game of any company is to deliver the highest quality product to customers at the greatest market value, with the lowest cost of production. This school of thought drives the Agile methodology of software development, pushing for faster delivery of better products with the least amount of risk, and has fueled the scalable Agile solution for enterprise-level organizations: Scaled Agile Framework (or SAFe). Operating under the principles of Agile development, SAFe aligns the development and initiatives of all levels of the enterprise company- from agile teams to executives- for accelerated value delivery at a reduced risk. Leveraging short feedback cycles organized into sprints and release trains, the cost of deployment decreases as deliverables have clearer direction and requirements to ensure a better fit for purpose. 

How does Atlassian support SAFe?

What are the core values of SAFe?

How does Atlassian support SAFe?

The Atlassian product suite was created (and is continually innovated) to support best practices in the Software Development Lifecycle. To that end, the use of products like Jira Agile, Confluence and Jira Portfolio integrate to bring maximum traceability to every release, enabling teams to hit their deadline and their budget with the highest quality product. With Atlassian, you unlock the power of SAFe, leveraging Jira Agile, Confluence and Jira Portfolio to achieve the following objectives (and much more): 

Want to learn more about SAFe?

Ready to learn more about how Scaled Agile brings best practices and delivers the greatest results to your enterprise organization? As Atlassian Platinum Solution Partners, Praecipio Consulting is here to help! 

First, check out our webinar on SAFe®, Agile in the Enterprise, presented by Senior Solutions Architect, Certified Scrum Master, and SAFe® Program Consultant Amanda Babb to get a more complete introduction to implementing Agile practices at the enterprise level.

Next, contact us today to see how our Consulting Services can help you meet your goals.