One of the biggest shifts in IT service management (ITSM) over the last half-decade has been the push for Enterprise Service Management (ESM), where proven ITSM capabilities are extended to other parts of the organization to improve operations and outcomes. You can read more about the benefits of enterprise service management here.

There have undeniably been great successes in many ESM strategies to date. That said, there’s one thing still holding it back — its name.

What’s wrong with “enterprise service management”?

The name makes sense, right? Right!

Well…

To a certain point, at least.

ESM is the use of ITSM capabilities across the enterprise, so “enterprise service management” is an easy sell to those who know what it means. However, that group may be smaller than some might expect, which is where the pushback starts.

Enterprise service management is unknown outside of IT

“Enterprise” is, simply put, an IT-way to refer to the organization as a whole. It’s not something that has caught on quite as much in all other departments, though, especially those where “enterprise” already has a separate, distinct meaning. This can make pitching ESM tough, as its success hinges on other business functions buying into it.

Ultimately, the business functions that are seeking help to improve their operations and outcomes aren’t looking for “enterprise” service management. Instead, they’re looking for digital transformation and a quick-and-easy way to introduce much-needed digital workflows to their operations.

An individual in human resources (HR) may not have read or heard about HR’s need for “ESM”. What they will have been subject to, though, is a constant push to “digitally transform HR operations” and that “new ways of working demand digital workflows.” This messaging is most likely coming from both external and internal sources, too, meaning the recipient is often very familiar with it. 

This is why it’s time to talk to potential customers of ESM in the language that they’re expecting — and wanting — to hear.

Let’s not underestimate the critical business need for digital workflows

Your organization and its many business functions, having so far weathered the storm of the global pandemic (and its commercial and operational impact), are likely looking for a solution to support new ways of working. For many, the need for this solution has doubtlessly been accelerated by now-distributed, rather than centrally-located, employees and teams.

For any business function needing help with issues or opportunities such as:

• The inefficiencies and failures of its manual operations
• Missing enablement elements such as self-help tools and knowledge management
• The workflow and working issues caused by remote working
• The lack of insight into demand, performance, service quality, and outcome delivery.

It’s time to think beyond “enterprise service management” and speak about the ready-made solutions to these needs using terms that non-IT personnel will know and understand.

These business functions, teams, and employees all need the power of digital workflows and everything that can come with them. Things like rules-based and AI-assisted automation, self-service catalogs and chatbots, knowledge management, notifications and alerts, platform-based bespoke workflow/app creation, and other capabilities that are readily available and extensible in modern ITSM tools will help to vault your functions and teams to the level needed — if you can get each to buy in. Check out this blog to learn how to create buy-in with teams in other departments.

Let’s talk about enabling digital workflows going forward

None of this diminishes the opportunity and power of “ESM” — it just comes down to how the solution is sold. It’s time to start packaging it as “digital workflows” or “digital enablement” instead, selling the power of ESM to other business functions using the language they expect (and perhaps want and need). This will ultimately be an easier way of helping each improve their operations and outcomes. Check out this eBook to learn about ESM use cases for diverse business teams including HR, Legal, Operations, Marketing, and Sales.

If your organization and its business functions need fast access to flexible digital workflows, then let's connect.

One of the more compelling reasons to use Jira Service Management (JSM) is to take advantage of its request management and service desk functionality. JSM is designed to streamline both the fulfillment and intake of requests, across all teams.

JSM works to remove the frustration of having to manage requests from multiple sources through multiple channels, increasing overall efficiency by automating repetitive tasks. Teams can even measure their performance with JSM, tracking how many total requests come in, and how long it takes to resolve those requests. 

JSM clearly simplifies the process of streamlining service support, but what does the process actually look like? How are support requests so easily managed? To understand that, you’ll need to understand the JSM design structure.

Understanding JSM

At its core, JSM was designed to be a highly customizable tool. Atlassian understands that service delivery teams can often have unique needs, particularly when it comes to communication.

JSM functions as a singular place where team members can go for help. By using a centralized customer portal, both employees and customers can quickly access every service desk across an organization.

On the receiving end, service request management projects come with request types and workflows that are easy to review and edit. They also come with:

• Flexible Service Level Agreement Settings
• Customizable Queues
• Automated Request Management
• Email Channels 
• Adjustable Notifications
• Real-Time Reporting Capabilities

How Service Request Management Works With Jira Service Management

Before we dive into the actual process, it’s important to understand a few key elements of the JSM design. 

Let’s imagine that the customer/team member has a problem they need support with. They would start by accessing their customer portal and submitting a support ticket. The user that interacts with the customer portal is defined as a “customer” and does not require an Atlassian JSM license in order to access that portal.  

Support tickets within the customer portal are batched into specific portal groups. For example, you might have one portal group specifically for hardware which would include any hardware-related requests.  This way, the customer/team member can continue to find more granular tickets under those options. 

While tickets are placed in a particular portal group, the tickets themselves are not locked to a certain portal group exclusively. Some tickets may belong in multiple portal groups, and JSM accounts can account for this requirement. 

Within each portal group are the request types.  Request types are the actual tickets that a customer will fill out.  A few examples of request types for an IT Service Desk would be: locked account, new hardware request, new software request, software outage, etc. Once the request type is entered, the request goes into JSM, which is what the internal user (or agent) will interact with the ticket.  

Internal users of JSM are referred to as agents within Atlassian.  Agents are often members of service teams that perform the actual work for the tickets to be resolved.  These users require an Atlassian JSM license in order to view and move tickets through the workflow.  

The agent receives the request type as an issue type, and it’s worth noting that you can have multiple request types linked to one issue type. For example, the agent you may have multiple different request types (software outage, server issue, security vulnerability,etc.) that link to one issue type of incident. 

Simply by looking at the design, you can begin to say what makes JSM such a useful tool to both customers/team members and agents. Customers/team members are able to interact with a customer portal designed to simplify the support ticket submission process. Agents, instead of having to sift through a variety of different channels and sources, are able to quickly and easily sort by request type and address problems efficiently.

The Power Of Automation And The Overall Utility Of Jira Service Management

When your teams are supported properly, they’re able to waste less time fixing what’s broken and more time on the tasks that matter. Likewise, when your support team has a simplified support process, they can address problems much more quickly and help keep your teams moving forward.

Now that we understand a bit more about how JSM was designed, it’s time to find ways to improve the experience for all your teams. That’s why one of the first action items you’ll want to focus on is finding ways to implement smart automation. 

When you’re able to properly incorporate automation into your service request experience, you’ll be able to reduce the frustration of dealing with common, repetitive tasks for your service team. 

A great example would be using automation to help agents quickly move through their follow-up communications. Not only will this improve the way your support team can communicate with customers and employees, but it will also help improve estimated resolution times.

This is what JSM does best, making support simple for the customers/team members and making it efficient for agents. By building a distinct workstream for service requests, your business can use JSM to help your teams focus on delivering more valuable work. By standardizing the process, you’re able to increase both overall efficiency and service quality. 

As an Atlassian Platinum Solution Partner, Praecipio understands what it takes to get the best results from your JSM deployment. Our experts are ready to evaluate your existing processes and get you started with JSM quickly. Plus, we’ll standardize and optimize your JSM implementation on day one, so you start getting great results as soon as possible.

Want to learn more? Give us a call; we live and breathe Atlassian!

To keep up with the fast-paced digital landscape, businesses depend on software for carrying out day-to-day business operations, connecting teams, and simplifying workflows. This probably explains why the global application development software market is anticipated to reach $733.5 billion by 2028.

After helping some of the world’s leading brands drive business innovation with our custom software solutions, we've learned a thing or two (or six!) along the way about building custom software that keeps teams and their tools connected. Specifically with Salesforce, our applications and integrations (whether those be specific customer use cases or general ones via the Atlassian Marketplace) have brought systems together, increased productivity, and empowered sales teams to win more deals. 

Through our experience with developing custom solutions for the world's leading CRM platform, we've identified some key things to consider to help get you started when building Salesforce apps.

#1 – Hit the Trail(head)

Salesforce is a big, well-established environment. There’s a lot you need to know about the REST API, the development process, and packaging and distributing your applications. The Salesforce Developer Training available at https://trailhead.salesforce.com provides free training courses along with sandbox environments to do the exercises. It’s a great way to quickly come up to speed on the topics you need to know more about.

The courses are not limited to development topics. If you need to learn more about using Salesforce or just want to understand the ins and outs of the Partner program, the Trailhead is the place to go.

#2 – The REST API is nice

The Praecipio development team does a lot of integration work, helping our customers improve their workflows by connecting different systems together. We work with many platforms, and have seen many APIs that are REST in name only. Often these are thin wrappers over an older XML API, or they don’t handle relationships in a RESTful fashion. Salesforce gets it right. The API is clean, consistent, and easy to use.

The API also provides a lot of useful metadata, which can help you make your software exceptional. When working with any object, you can get a list of all of the object’s fields, the labels for those fields (which may have been customized or localized), each field’s type, and whether a field is required or not. For any field whose value is selected from a list, there is an API call to return the list of valid values for the field.

#3 – Leverage a library for your stack

While the API is well-designed, it is large and feature-rich. Starting from scratch can be daunting, and you might not even be aware of some of its features. Instead of rolling your own code, take advantage of open source projects that wrap the API in your language. To achieve this, we use the Restforce Ruby Gem. Simple Salesforce is a well-regarded Python customer, and jsforce is available for JavaScript developers.

#4 – Deploy with the force (CLI)

Books, tutorials, and Trailhead courses on Salesforce development typically have you developing in the Salesforce GUI. There are times when that is valuable. The Developer Console provides a REPL that is handy for testing out ideas and debugging problems.

However, if you are like most developers, you have invested a lot of time getting your development environment just the way you like it. Fortunately, it is possible to integrate the Salesforce development process into just about any workflow. The folks at Heroku, a Salesforce company, have developed a Command Line Interface called Force, that allows you to interact with Salesforce using an API, instead of the GUI. You can upload and download templates and code, test snippets, view logs, inspect and change settings, plus much more. You can do just about anything you could do in the Salesforce GUI and while doing it in a scriptable, repeatable way.

#5 – Not all Salesforce instances have API access

Salesforce offers a number of editions, each with different pricing and features. One of the features that is not available on the lower cost plans is API access. Trying to access the API of an organization with the Contact Edition, Group Edition, or Professional Edition will raise an error. It’s also possible for the administrator of other Editions to turn off API access. Full details can be found in this article.

However, it is possible for a developer to get API access in these editions, which bring us to our final expert tip.

#6 – Managed packages and unmanaged packages. Choose wisely.

One of the topics that can be confusing for new Salesforce developers is Packages. It’s an important topic to understand because your choice can limit who can use your application and how.

Packages are ultimately bundles of customizations created by you that other Salesforce users can install into their organization. You customize a Salesforce instance and then, using a Salesforce-provided tool, you package up those customizations and publish them.

Once you have created a package, you can simply share a link to it. This is then considered an Unmanaged Package. Alternatively, you can submit that package to Salesforce for review, after which it will be published as a Managed Package, available in the Salesforce AppExchange.

Pros of Unmanaged Packages

• Free to create.
• Can be released at any time.
• You can sell them directly to your customers.

Cons of Unmanaged Packages

• Not in the AppExchange, you have to market directly to your potential customers.
• Some companies will not install Unmanaged Packages, preferring only Salesforce approved applications from the AppExchange.
• As noted above, API access is unavailable in some Salesforce Editions.
• No automatic upgrades. If you make changes, your customers will have to manually install the new version.

Pros of Managed Packages

• Customers can find you in the AppExchange.
• Automatic upgrades are available.
• Salesforce manages payments and licensing.
• Full API access for all Editions. Editions of Salesforce that are not normally allowed to use the API are granted access for Managed Packages.

Cons of Managed Packages

• Setup cost. The review process for a Managed Package includes a security review, which is expensive and time consuming. If your application will be free, this fee is waived, but you still must complete the security review.
• Review time. The initial review process can take several months.
• Salesforce takes a percentage of all sales through the AppExchange.

Ultimately, it’s a business decision. If you want to be in the AppExchange or have API access to all Editions of Salesforce, then you will need to have a Managed Package. However, if you want to move fast, sell directly, and avoid upfront costs, then an Unmanaged Package may be for you.

What's Next?

Still feel like you need some guidance on your custom development initiative? The award-winning team at Praecipio can bring our Salesforce expertise and software development best practices to your next project. Let us know how we can support your organization and help design innovative solutions that scale with speed of your business.

Workflows are the backbone of every process in every business around the globe. Efficient workflows can help your business scale effectively. However, flawed or fragile workflows can lead to issues within your company, disruptions to your bottom line, and more. 

• Create a request to solve this issue and make a business case for it
• Once approved, brainstorm with stakeholders on ways to improve the process
• IT had to create a development and test environment to code the changes and test them
• Documentation and training
• Launch with (hopeful) success

How long did this take? Days? Weeks? Traditionally, months.

Cloud shortens that time and provides several other benefits—such as reduced IT overhead, strengthened security, and more time spent focused on your customers and product. You can learn why you should migrate to Atlassian Cloud in 2022 here.

You can learn more about our approach to Atlassian Cloud Migrations and discover how we've maintained a 100% cloud migration success rate.

Your Cloud and digital improvements won't provide greater customer satisfaction, staff enhanced capabilities, or lower costs unless you begin to apply DevOps practices and tools.

How do we make it faster?

Using the concepts of IT service management, and leveraging the right software, you can automate creating and approving requests or resolving an IT issue (incident). This approach can be applied to other business tasks such as sales, HR, marketing, and essential accounting functions. Cloud-based software lets you implement these processes with a few clicks or by pressing a button on an online catalog. Atlassian and their partners like Workato are leading the way in creating business as a Service process. 

If we look at Onboarding, for example, one of the most common workflows companies have a strong desire to automate. The steps to source an applicant, store their CV, arrange an interview, track the responses, make an offer, track the request and organize the start date, training, and IT of the new employee used to take several days. Now software can complete your onboarding process by your morning coffee break.

The same is true for:

• Approval workflows – product or service improvements currently require many approvals from finance, security, users, operations, and even external suppliers. These hand-offs add days to time to market, which could be saved if you allow software to manage your approval process.
• Creating application environments – we have seen where the request for a new environment took 11 weeks. Coding the demand to deploy process allows an entire domain to be ready in less than 10 minutes. Taking advantage of this, you can even code the removal of the environment if not in use saving money.
• Automating payment of services (debit cards, online products like PayPal, online ordering) is nothing more than leveraging code for the cash flow from request to the supplier.

How do you take advantage of this new way of creating work?

• What work processes are vital to you, and why?
• How do they work today?
• What is wrong with them today?

This is where a partner like Praecipio comes into the picture. Leveraging lean techniques like value stream mapping (VSM) that have been embraced by DevOps and ITSM the world over, we can work with your teams to design for your future. Making collaborative decisions on improving the workflow or outsourcing the workload to a SaaS provider (see Praecipio SaaS blogs) can be agreed upon. The goal is to introduce innovation, speed, and scalability with a cloud service enabled by software workflow products. We bring context and expertise to the table turn your ideas into reality.

Free eBook: 6 Steps to a Successful Atlassian Cloud Migration

Learn how to assess, plan, and launch a successful Atlassian Cloud Migration with our new eBook. We explore what you should expect before migrating, how to avoid common mistakes, and how we partnered with Castlight Health to guide them through a successful cloud migration. Learn how we've maintained a 100% cloud migration success rate, download our 6 Steps to a Successful Atlassian Cloud Migration eBook today.

The goal is to have cloud-based operating models that can accelerate your strategy. Through 2020 and 2021, we've seen what happens to companies that do not react quickly enough. Ask for assistance and coaching, and go digital in 2022. Get started with your Cloud Migration by reaching out to the experts at Praecipio.

The popularity of Jira Software has skyrocketed in the last few years, thanks to its excellent features and easy adaptability to agile development models. If you are considering using Jira or are already using it, ask yourself a fundamental question. How do you make the best use of the various features Jira presents? 

Let’s start with Jira Epics. Often, development teams tend to jump right ahead into crafting user stories, sprint planning, and so on without huddling around Epics. While sometimes it could be because of the nature of the user story, it is often because the end-users are unaware of what an Epic is and how it helps organize your stories and streamline the development process. 

Here is a simple guide that will help you understand the concept of Epics and how to effectively use them in Jira.

What Are Jira Epics?

Epics are, in essence, a big goal or a task that can be broken down into related sub-tasks. While this is the general idea behind Epics, every team may have a slightly different way of implementing Epics. Some consider it similar to a project hierarchy. Some make it strictly goal-based, some base it on features, and so on. In Jira, Epics are created as special issue types similar to tasks and stories. Each Epic can have associated users, workflow, states, and so on.

Epic Vs. Story Vs. Task

So what differentiates a task or story from an agile Epic? While tasks and stories tend to be standalone pieces of work, Epics are more complex, with several tasks grouped under them. 

They have custom fields that help identify the issue hierarchies within the Epic, such as the parent-child tasks.

• The various tasks within an Epic could be executed in a parallel manner or may have dependencies.
• Epics also have data fields, such as a start date and a target date.
• Epics are coarser and span several sprints, whereas tasks and stories are more detailed and are planned for a limited sprint length.

What Is The Difference Between Epic And Feature In Jira?

Often used interchangeably, Epics and Features tend to confuse Jira users. While Epics and Features are similar issue types that can be broken down into smaller tasks or stories, the significant difference is how they are placed in the issue hierarchy.

Epics are much bigger and are are often the topmost parent in issue hierarchies. Epics can consist of Features, and these Features can further be broken down into individual user stories. Epics represent a more extensive set of requirements or project goals, whereas Features are more focused. 

Why Are Epics Important In Jira?

There are many reasons why using Epics is an excellent way to plan your agile software development projects. Let us list out a few:

Organized Project Outcomes

It helps organize project outcomes in terms and makes it easier to communicate project progress to concerned stakeholders. 

Not all stakeholders can have the technological knowledge to understand the project progress via individual user stories. Epics present an easy way to abstract the project’s status and quickly raise the measurable outcomes to stakeholders.

Helps Achieve Specific Targets With Ease

Lists of Epics allows teams to establish the priority goals and the necessary metrics to track such goals.

Facilitates Optimized Project Execution

Epics are organized to allow for a detailed design before user stories are taken to implementation. They, thus, help with an optimized workflow and flexible decision-making as the project progresses.

Allows For Better Innovation

By allowing DevOps teams to define and design their project via Epics, you can promote innovation and excellence in terms of product design and development.

How Do You Create Jira Epics?

Jira is well equipped to help you integrate Epics into your project planning phases with ease.

Here is how you can create an Epic issue in Jira:

• Create a new issue
• Select issue type as ‘Epic.’ Fill in the details such as epic name, description, and such. Click create.
• Once created, you can link other issues or create new issues from within the Epic view.

Cool Things You Can Do With The Help Of Jira Epics 

• Integrate Epics with project backlog for efficient project planning
• Track project progress with roadmaps
• Derive useful visualizations such as Epic swim lanes and Epic link on cards on the kanban agile boards.

So what else can you do to make the best out of this feature? Let us start with the basics. First, understand what an Epic is and know the various workflows and requirements uniquely available for Epics. 

Then, use these features to get on track with your agile project management and other methodologies.

Try not to create Epics that do not have a defined scope. Epics should close unless the Epic you are running is actually a theme and not new in reality. Make sure you're aware of the subtle difference so you can utilize Epics appropriately.

The sooner you implement Jira, the better your results will be. Jira is incredibly comprehensive, and many struggle to get the most from the platform. Praecipio can help you make use of the various automation and process optimization tools that Jira gives you. Having expert guidance will go a long way in helping you save costs, time, and resources. Reach out today!

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.

TL;DR: No!

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

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

Product Owner

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

ScrumMaster

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

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

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

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

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

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

Overall, not great!!

So what should I do then?

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

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

Looking for more information on Scrum best practices? Check out Sprint Planning - How long should sprints be?

Building Jira workflows can be overwhelming. As Atlassian Platinum Solution Partners for over a decade, we at Praecipio have spent a lot of time building workflows (seriously, A LOT). 

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

When do I use a global transition?

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

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

How to configure a global transition

Transition Properties

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

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

Conditions

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

Post Functions

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

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

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

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

1. A post function that clears resolution

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

Still need more help with your workflows? Praecipio is an Atlassian Training Partner with a robust catalog of training, including Workflow 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!

How many times is the number of clicks, fields or screens having to be navigated through used as a reason that work efficiency is low?  It is a main way to discuss lack of efficiency by users of any system.  Well, Jira Service Management has automation built in for just these type of issues. And when leveraged properly, Jira Service Management automation can help drive closing out issues for users as well as ensuring customers feel engaged and informed.  

While time is a focus of most people, as it is the one thing that never stops: being able to use it effectively on things that NEED your attention is key.  Yet, the first hurdle most people have is identifying what actions do not need to be performed by someone.  Automations are things that can be based on inputs by a person, and therefore are always going to be selected the same. For example, filling in a customer based on name or filling out a number field based on selection of priority.  Once these are identified and agreed upon, you can then start to figure out the next phase: how to build the workflow around these to aid in the automation. 

One of the keys to automation is how the workflows are set up in Jira Service Management.  The workflow, when configured with either the correct transition or status or combination thereof, can facilitate the automation. Having a workflow set up to allow for automation based on a specific entry into a status or trigger of transition will helps both agents and administrators of Jira Service Management manage their work more easily.  On the administrative side, the proper set-up will allow for focused automation(s) and ensure they are easy to link without writing out complicated if-this-then-that statements.  On the Agent side of the house, the simple automation UI makes it easier for them to understand their triggers. The Agent can then move on to another issue until the need for follow-up arises. For example, transitioning a request to Pending Customer may pause the SLA, but automating the transition back to In Progress based on a customer comment alerts the Agent they've received their feedback. 

At this point you may be wondering what are some of the items that can be automated in Jira Service Management to ensure efficient flow of information.  Here is a list of some of the ways to use automation for communication:

• Customer alerts for approval
• Alerts for review of information
• Alert them to closure of ticket
• Alert to lack of response

The first part of the communication is understanding what YOUR customers will need from your team to understand what is happening with their issue.  For the most part, customers want to be appraised of receipt and communication of progress consistently.  With this mindset and communication to customers, you will inevitably save time by eliminating constant customer inquiry on what is going on with their tickets or the "do you need anything from us?" question.  While this can be a bit overwhelming at first, at Praecipio, this is one fo the many items outlined in our Accelerator for Jira Service Management implementation.  We have gathered best practices from many different implementations to put together a "starter kit" on automated communications. 

The other side of the automation for Jira Service Management is automating information based on user inputs.  By filling in specific fields based on user input or spinning up linked tickets to connect to the current issue, the automation inside of Jira Service Management for tasks that, while not hard, can become tedious, is where the Agents and Customers see the benefit.  Remember, the users main complaint centers on the amount of time they take to get the issue closed and move on to another one.  So while remembering that fields can be adjusted is a good thing, spinning up another issue that is linked is even quicker, thus eliminating the time to move information and instead having it done automatically by selecting the correct workflow transition.  

Overall, the key to getting the most out of the automation in Jira Service Management is first figuring out where you can save time for the users of the system.  Second, determine how to communicate to your customers in an effective manner that can be automated, but also ensuring your customers' satisfaction.  This should be centered on letting them know what is happening with their ticket and drawing them back in to the solution when needed.  As always, anything to remove steps (clicks) from the user is going to not only get more out of Jira Service Management, but also drive a higher usage of the system, correctly, back into your organization. 

We are experts in Jira Service Management, and would love to help you make the most out of this powerful tool.  If you're curious to see if Jira Service Management is a good fit for your organization, drop us a line and one of our experts will get in touch with you.

Altassian’s Jira is perhaps the best issue tracking and software development management platform around. While Jira can be used in many, many ways, it’s found a sweet spot in the gaming industry.

This post assumes the reader has a reasonable understanding of Jira. The post highlights how Jira and Greenhopper – which collectively make up Atlassian’s Agile approach – can streamline game development. Check it out:

Quick-start projects. In Jira, you can start a new project in less than five minutes. That’s great for developers, since new projects can spawn at anytime during the production process.

Attach files for visual reference. Most developers use Adobe software to design game interfaces. During the development stage, there are usually multiple people designing and updating prototypes – so it’s easy to get off track. With Jira, designers can attach the a screenshot of the latest prototype to a project page, so every one involved with the project can see where the interface is at and stay on the same page. And since Jira allows users to attach files to projects, tasks, time log items, and more, it’s easy for designers to offer team members a visual reference of where they’re at – even if they’re not in the office.

Support and ticketing. Jira helps IT support organizations handle hardware and software support more methodically. Support tickets can be submitted by anyone within the company. From there, they’re assigned to a qualified expert, and either resolved or escalated. This obviously benefits all businesses and not just those in the gaming industry. But for game developers on a tight schedule, hardware performance is critical – and a fast ticketing process ensures minimal downtime.

Bug tracking. Bug tracking is critical in the gaming industry. Jira’s organized, intuitive bug tracking system allows game developers to track the details, status, etc of every kink in the development process – ensuring better performance.

Document repository. Jira can also act as a document repository for files of all types. With a powerful search feature and page indexing capabilities, game companies can ensure quick access to important files – so long as they’re organized responsibly.

Crucible. A web based code review tool, Atlassian’s Crucible (a “friend” of Jira and Greenhopper) allows multiple people to review code online instead of having to crowd around a desktop or overhead projector – the “Google Docs” of code-writing. For game developers, that kind of collaboration is worth its weight in gold.

Greenhopper task tracking. Drag-and-drop task management that associates tasks with Jira projects, items, files, etc, etc. Completely intuitive, remarkably fast. We needn’t say more.

Customize to your heart’s content. Jira is easily and extensively customizable. Most of its customizations don’t require technical knowledge – so designers and developers with different skillsets can configure Jira with ease.

Insanely easy workflows. You don’t have to be a programmer to set workflows up in Jira. Develop workflows quickly to automate repetitive tasks.

Integration with non-Atlassian tools. Jira users can develop their own plug-ins to import and export data to and from Jira. This is crucial, since no software can tackle every need within an organization, and since game developers usually need to leverage multiple tools throughout their production.

That’s how game developers are leveraging Atlassian tools to streamline operations and production timelines. Again, it’s worth noting that much of what’s covered above applies to business of all types – not just those in the gaming industry. Check out our Jira blogs to learn more about how Jira (and “friends“)  can boost your operations.

Special note: If you’ll be attending South by Southwest (SXSW) in Austin in March 2011, stop by our booth at the SXSWi Trade Show. We’ll have a Jira demo live, and have our developers behind the table!