Category: JIRA

New JIRA users often run into a predictable set of problems when they jump in to build a workflow. If you are new to JIRA, I encourage you to get some training before you move beyond learning and start pushing workflows to users. If you want to get going quickly, here are some guidelines that can help

Some common problems are:

• Starting with a custom workflow. Before you do this, set up a project and send real work through the default workflow. By doing this you will gain an understanding of what workflows do and more importantly, what they do not do. Jumping into a custom workflow guarantees starting over at some point.
• Dead ends in the workflow. It is not unusual to create a status that transitions responsibility for the item out of your organization. An item can sit there for quite a while, but make a path to return. There should never be a status in your workflow (including closed) that has a transition in but not out.
• The opposite extreme to dead ends is when every status can lead to every other status. This is often a new JIRA user’s response to the frustration of a poorly designed workflow. This is a cop out, take the time to understand the work and build a workflow to support it. Think through your workflow and build a natural path that covers the primary use case. Work has a purpose and is not scattered, your workflow should reflect this.
• Confusing statuses and transitions. First, a status is, as named, a state. It is a resting point in the path through the workflow. A transition is a move between two states and represents specific actions. Second, here are some analogies that might help: Statuses are to transitions like nouns are to verbs or cities are to highways.
• Reverse paths are very important to users. Even if it does not make sense from a workflow perspective, users will make mistakes and move an item forward accidentally. Give them a quick, easy way to fix it, unless you want to be fielding a series of requests to manually move items between statuses. Always make a way out for a user that accidentally clicks a transition.
• Once you learn how to build restrictions on transitions use them sparingly. This is a common mistake in many areas of IT. Over-restriction ruins what might be a positive user experience.
• Minimization is important. It is very common for new workflow designers to lay out statuses where an item will never land for more than a few minutes. Take a look at your workflow, and unless it is a critical point to log, do not make a status of this type. I use the following rule: if an item will never spend the night in a status, the status should not exist. If you have a status that is really important and the user must take action, consider making it a field on a screen that pops during a transition.

JIRA is an enterprise class application and as such requires a certain level of training to be effective. Find a mentor who has used JIRA extensively, take a look at any of the online training resources available. If you would like a quick formal training that will get you running, you could consider our class at http://jirabootcamp.com. If you would like a deep sequence of training on specific topics, Atlassian has some great courses available here.

Update: Jira Jumble, and a wide range of Jira-related training and services, are now available through our sister company Expium.

---

At Oasis Digital, we teach a Jira class in which students learn hands-on how to build workflows, administer Jira, and overcome common challenges. While writing the course material, we realized that it is difficult to fully understand the features unless you have a significant amount of data in Jira: issues, projects, users, with important dates in a range of dates near the date of the class.

One obvious way to obtain this is to use or copy a real (“production”) Jira instance, but students are wisely hesitant, as are we, to bring up a copy of a production Jira instance (full of proprietary information) to use in class. Instead, we need to be able to generate a populated Jira instance with random but useful data. In the past there have been tools for this from Atlassian or other makers, but we found none of those tools are available for the current (as of 2014) Jira versions; and they had been packaged as Jira plug-ins for Jira Server, which means they cannot be installed into Jira Cloud (formerly called Jira OnDemand).

We solved this problem by creating Jira Jumble, a random data generator tool for Jira. We then realized that it would probably be helpful to many other people using or learning Jira so we made it available online. We expect to add additional features and enhancements over time based on the class needs and the feedback we receive.

Please give it a try, we are eager to hear what people think of it.

As a reminder, this test data generator is intended to be used to populate a new, empty, throw away Jira instance for testing and learning. It works with both Jira Server and Jira Cloud. Do not import its data to your production Jira Server or Jira Cloud instance!

(photo credit)

I was reflecting on my time at the Atlassian Summit today and put some pieces together. Throughout the conference I would hear the keynotes (mostly Atlassian leadership) and session speakers wax on about the improvements in the products and where things were going. (On a side note, this was one of the best events I have attended in my career. Well run, excellent content, and great participation from attendees that came in from around the world.)

I have found the Atlassian products to be very effective and on the mark in terms of enhancing productivity. The message I heard loud and clear from the Atlassian speakers was that they are streamlining their toolbox, making it easier to use, more efficient, and more intuitive. I am impressed with the persistence they have shown in this increase of efficiency as I have watched the product develop over the last few years. It has not succombed to the mind-numbing massive feature infusion so prevalent in our industry. There are countless examples of this phenomenon, led very obviously by Microsoft products.

[box type=”note” size=”medium” border=”full”]Other JIRA Resources

Other JIRA Articles:

JIRA Training 102 –The Little Things 
JIRA Training 101 – Workflows
Using JIRA – Be a Winner not a Loser
Adapting a Microsoft Project mind to a JIRA world

Our JIRA Training Course:
JIRA Boot Camp

[/box]

What I find interesting is how this attractive message was diluted and changed not far from the main stage. I spoke to various business leaders and speakers at the “Bash” and in the halls. For the most part I heard a lot about process improvement, amazing new features, visibility into teams, improved (increased) reporting, and better (more) documentation. These can be good things, but they miss the point of the tools’ creators. It reminds me of how hard it is to change mindsets and habits. Business leaders have been conditioned to want more data, more information, deeper analysis. Often this runs counter to a business’s primary mission and, if uncontrolled, can be very destructive.

Lets slice it this way: if you want your organization to be profitable and successful you need to maximize the output of your organization. This means that the supporting pieces around the core work (the part that makes a profit), need to be as small as possible and the core work needs to be as massive as possible in your workflow. Successful managers think this way and the Atlassian tools are built to accomplish this. Reporting, timekeeping, and yes, even user stories are supporting mechanisms to the core work, yet the expansion of these was the focus of many of the non-Atlassian speakers and attendees at the Summit.

Stay Focused

The focus starts at the usage and configuration of your workflow in JIRA. With a good workflow, important actions and reporting metrics can be automatic or at least reasonably simple. Some of the new features like automated transitions and integrated dev tools facilitate this well. As you lay out your workflow, be sure to deconstruct your processes to understand what is critical to your business productivity and what is not. Spend the extra time to keep your staff in that highly productive part of your workflow. Focusing on improving the productive capacity of your team will not only help you but it will help your staff feel empowered and successful.

Looking Ahead

The incredible efficiency offered by JIRA and other Atlassian tools has opened up a whole new set of markets for the company. The relentless focus on productivity has pushed JIRA in particular into the forefront of workflow management. It is quite simply flexible enough to run most organizations better than very high dollar systems employed by corporations. I think we will see a transformation in the coming years. What started out as a developer’s issue tracker could very well be the engine that drives business for many years ahead.

When I observe various JIRA installations, some common problems tend to bubble to the surface. Many cases of poor adoption or user interaction can be traced back to inadequate setup. As a JIRA Admin or champion you can send a clear message to your users by how you approach the system in the first place.

Other JIRA Articles:
JIRA Training 101 – Workflows
Using JIRA – Be a Winner not a Loser
Adapting a Microsoft Project mind to a JIRA world

Our JIRA Training Course:
JIRA Boot Camp

JIRA is a platform that supports extensive customization. Some of these include:

• UI

• Project

• Fields & Screens

• Workflow Transitions and Statuses

• Dashboards and Agile Boards

• Security and Notification Profiles

I am not suggesting paralysis until all of these areas are customized, but I am suggesting that some thought regarding each of these areas is important. It is also very important to show continuous iterative progress toward a system that will provide maximum value to the leaders and users in your teams. Let’s look at each of these areas and touch on what value they have to your organization.

UI

This is the easiest and most of this should be done prior to launch. Add your logo, adjust the color scheme to match your other internally created tools. Help the user recognize it as important. The flexibility here can also ruin your instance. Use colors in a non-intrusive way, mainitain contrast and readability, and most of all, be subtle. We often overdue it on the first pass of customizing the UI. Less is more, seriously.

Project

Show the users that their project is important. Categorize your projects, some organizations have hundreds of them. Use the tools available to organize and group similar initiatives. This can have substantial value and create important conversations across multiple teams. Add a custom image for the project. The team members identify themselves with their work, help them make that connection. Clearly identify the project lead and give them the ability to modify, assign and lead their project in JIRA.

Fields & Screens

Create fields that apply across different aspects of the organization. Also be ready to use custom fields especially for fields you want to ensure are populated. A user is more likely to notice custom fields that pertain to their project over generic names. This one is a bit of a challenge because without restraint and planning, custom fields can create a mess over a number of projects.

Also be sure and organize your screens. Avoid the mistake of piling all your fields on every edit screen and transition screen in your instance. Work with your users and design the screens to be effective. Doing this can drive user interaction and productivity.

Transitions and Statuses

As with Fields and Screens, above, work with your users, name statuses and transitions well. Build workflows that lead to increased productivity. One additional way you can help your team is by paying attention to the display of transitions on the issue screen. Avoid making users dive through the menu to find the transition they typically need. Put the “happy path” right there in the main toolbar for their ready access. Get regular feedback from your users.

Dashboards and Agile Boards

After a project has been running for a while there is a mountain of data available. Dashboards, Wallboards and Agile Boards can be very useful to leaders and team members alike. They can be used to communicate real time progress, identify problems, and monitor workloads. They can also be a point of pride. A team gets a lot of satisfaction from releasing an Agile Board, and this can improve productivity and engagement. These tools can become hubs around which your teams operate, take the time to implement them and make them work for the team.

Security and Notification Profiles

These are often overlooked but can provide a level of privacy with transparency that can enhance the work environment. Often JIRA is implemented in a very flat way where most information is accessible to all the members of the team. In many cases, this can be problematic. By applying some specific limitations to what coworkers can see about each other, you can help users focus on the work at hand and thereby increase productivity. You can also assist managers by giving them the option to have some control regarding information flow. A variant of this approach is to limit individual access to some information while making it available in a centrally published wallboard.

Managing notifications is also important. If not managed, JIRA notifications can flood email boxes and become a drain on energy and attention. Work with your managers to establish who should get which of the dozens of possible notifications. In some organizations you may need to turn email notifications off completely.

Conclusion

Show your users that JIRA is important to you in addition to the organization. Take the time to understand the little things that can make a big difference to your users. I want to reiterate that there is no need to hit all of these before you launch. Hit them one at a time over successive weeks. Continue to improve the system until you get through all of these areas. Users will notice that you are making an effort to improve the system. This will improve their view of you and JIRA. Once you are running smoothly, regularly get feedback and make adjustments to keep the system relevant to how your teams change. Also keep an eye out for team leads and managers creating spreadsheets to track items that could be handled in JIRA. This kind of fracturing can become a serious problem. When you run across such a spreadsheet, work with the individual, it is rare that you cannot meet the need within JIRA.

Atlassian’s JIRA is a powerful tool to manage your team and your projects. Having a tool and bringing a tool to bear on a problem are two totally different things. I teach a JIRA Boot Camp class that is three days long and focuses on skills, like workflow configuration, needed to be successful implementing JIRA.

What is a workflow?

Atlassian’s Definition

“A JIRA workflow is the set of statuses and transitions that an issue goes through during its lifecycle.”

I think of it more for universal use:

“A JIRA workflow represents the actual value being produced by your team.”

Taking it back to this level helps us to visualize what a workflow needs to be. This is a process explored extensively in many systems over centuries. Process management and workflow diagrams have been around for a long time, I have some very old drafting templates that would prove my point. In fact you can buy them on ebay and they make for great technical nostalgia pieces in an office.

Click here to see the listings on ebay

In essence any work process can be represented in a JIRA workflow. I use it personally to track our marketing and sales efforts at Oasis Digital. It took me an afternoon to build a good tracking workflow and we now use it exclusively to track our opportunities. Atlassian even describes how to use it to track blog post creation as an example. The trick is to recognize WHAT should be a workflow and what should not.

How should I view workflows?

I believe you should have a workflow for anything that could make or break your team. A workflow will allow you to monitor, visualize, measure and redirect a process. Your time should be spent monitoring, measuring (often through visualization), and redirecting your team regarding any critical issue. A workflow in JIRA will help you do just that. Viewing workflows in this way allows you to not just apply them to the problem of software development, but the success of your organization.

Issues of secondary importance are usually not worth building into a workflow. Without the momentum of constant attention, systems that monitor secondary functions fail at a very high rate. It is usually not a good idea to invest a lot of time in things that do not add a lot of value.

Making an effective workflow

 

To make an effective workflow we need to step back from a process and identify how many “states” or “statuses” a piece of work goes through. It usually takes a few iterations to get this down, most organizations have this kind of knowledge in a manager’s head and not on paper. Once you have a feel for the statuses then you look at the actions that get it there.

In the sales example a project will go from a prospect status to a proposed status with the submission of a proposal. This is referred to as a transition. When drawing out your workflow there are lots of arrows connecting statuses. Every one of these arrows is a transition. Some transitions move an item forward in the workflow and others move it back.

When you have a complex workflow, I think it is good to use the visual tool in JIRA to make “stages” for the item. To continue the sales analogy, all of the presales statuses are grouped together and the item can jump to the next stage when it is proposed. There is then a final stage where the item lands and is either sold, lost or delayed. This can be seen in the diagram below.

An Ever-Changing Core

 

Most organizations that use JIRA use it in at least a partially agile way. The concept of iterating to ever improve needs to apply to your JIRA workflows as well. It will take some time to accommodate all the fringe cases within your workflow. The system is designed to allow you to make rapid changes to the workflow, use it! Do not sit on needed changes for more than a day, discipline yourself to jump in and improve. Every day that a needed change is not made hurts the adoption of your workflow, there is a critical need to be responsive.

Also try not to over-regulate your team in the beginning. Work slowly towards things like required fields being entered in a transition. Only disallow backtracking in a workflow if absolutely necessary. Making it easy for your team to interact with the system will allow you to use it to its fullest potential

What about Workflow Add-Ons?

There are a large number of enhancements available in the Atlassian Marketplace. These add-ons can be very powerful and a great fit for many teams. I would encourage pushing the stock tools as far as you can before installing any of these. As a general rule in any system, master the base tool before installing third party products. In the first rounds of improvement it is not unusual to radically change your approach. It is best to evaluate enhancements in the context of your educated approach, not an initial attempt.

Conclusion

JIRA workflows are feature-rich and capable of great complexity. Do not allow yourself to be intimidated. By following some of the lessons noted here you can tackle even the most complex workflow and start to take what can be opaque process and make them transparent and manageable. JIRA is a powerful tool and workflows are its heart, bring their power to bear in your team.

Atlassian’s JIRA is a powerful tool to manage your team and your projects. Having a tool and bringing a tool to bear on a problem are two totally different things. I teach a JIRA Boot Camp class that is three days long and focuses on the skills needed to be successful implementing JIRA.

If you want to learn more please visit:  http://jirabootcamp.com

When using a tool like JIRA to curate your project management processes it is important to use it effectively. It is very easy to move off of the “happy” path and into the weeds that cycle a project into chaos. I want to touch on a few of the pitfalls and also highlight a couple of creative ways to use it.

Pitfalls

#1 Death by Ambiguity

When putting your work into any issue tracker it is always tempting to create items that are not only unhelpful but ultimately damaging to your project. If you are early in a project and dividing large chunks of work for future definition, items like “Email Notifications” or “User Profile Page” are not good for the project. Items like this feel good at the time, a list of them covers the breadth of the project, but they will hurt even in the short term. How can a developer know where to start with these? They span major components of an application, UI, server, client, and more. In many teams the same developers will not even work on these different components of the software.

Later in the project these can be damaging as well. For example, a few months down the road a developer is now taking on responsibility for the administrative screens in your shiny new application. They keep noting the need to work on email notifications but do not know where to start. The naming of this ambiguous item gives them the false sense of security that it is noted and will be handled, when nothing is further from the truth. Preliminary design work may desperately need to be done for the notifications to be ready in a future chunk of work (milestone, sprint, release), yet nothing moves. Developers that do not have the responsibility for other parts of the system touched by the item cannot, on their own, break it up into pieces.

Some forethought and design need to be taken early in a project to avoid these problems. Use a standard that works well for your organization. Break it up into meaningful chunks that will match up with your development team structure. For example we might enter the item as a part of other related work tied to the client, server, administrative screen design. This way the feature heads into the design process without cluttering and confusing future waves of work. Another solution is to specifically identify a design item for the feature. This is valid work and is worthy of being tracked as a part of most projects.

#2 Death by Stagnation

Another major pitfall is not breaking up larger items that are well defined. A large irritant to a customer (internal or external, there is always a customer) is seeing the same item stagnant and not moving for months. We try to keep most of our items at a size that can be completed in a week. This way the customer can see progress on a continuous basis. This often means that a particular item might be broken down into many parts, yet there is often resistance to this extra work. Not breaking up these components can leave your progress hidden from your customer.

All customers want to know when their shiny new application will be finished. This is a normal desire and one we challenge constantly in the custom software world. We all know we cannot control outside factors that impact or drive a customer’s business. In the course of a project, stresses and pressures will often come and your customer may begin to scrutinize the project in a different way. The game changed and you are still moving along. When the customer comes to look, will you have 20 large items moving slowly or 150 moving quickly through your process? I would much rather have a large number of items being clicked off weekly. The customer can see steady (sometimes daily) movement. They can predict themselves when the application might be completed.

#3 Death by Silence

Any system is only as good as the information flowing through it. The natural human tendency (especially for developers) is to only communicate when it seems important. Just like your marriage, your project needs good strong communication to be healthy. This seems so obvious, but I have watched this kill projects time and time again in my career.

JIRA specifically is a platform that is well suited to capture the story of a feature or item as it goes through its life-cycle. If used properly, you can come back years later to make a change and be up to speed in a few minutes. On some projects we have design, workflow, commits, and technical discussion going back ten years. Our detailed data predates most of the employees at the customer, providing a historical perspective that adds yet another layer of value.

Capturing this data takes a culture that requires effort to build and diligence to maintain. Ask each developer to comment on their progress on a regular basis, establish some guidelines. Have Project Leads check this as a regular part of their work process, build a culture of positive accountability. Find places to establish checks and balances that will protect these guidelines and give you the confidence they are occurring.

Outside the box

While just avoiding the issues identified above will make your project better, we have found a couple of creative things that are quite beneficial when working with our customers.

#1 Screenshots/Video

Media is powerful. We have recently started looking for screenshots on any resolved issue that is customer-facing. Having these available paid dividends immediately. Pictures are not only worth a thousand words, but more importantly they apply clear context to all the words you did write. Many of your customers are visual learners, use this to your advantage. Providing a screenshot or demonstration video beats a live demo every time.

#2 Feature based agile board

A quick and easy way to make a customer understand you value their priorities is a custom filter and agile board in JIRA. Simply add a label or a component, customize a filter, and create a board. Nothing will please decision makers more than seeing their high priority item flow through to completion. Giving that visual on the board can also eliminate those challenging schedule questions. They can see for themselves and begin to approximate completion. Do not underestimate the value of that last sentence. Giving customers the ability to answer their own questions quickly is powerful.

Conclusion

While not comprehensive, these ideas and concepts should help many who use JIRA or are considering the product. Staying on the good path takes effort but will pay off in improved communication with your team and your customer.

Over the last two years I have been steadily transitioning from project based, hardware-centric systems, to the world of software development. This transition has required me to adapt in many ways, some were easy and some were quite difficult. As I prepare for the Atlassian Summit in San Francisco this week I am reminded of the journey my mind, priorities, work habits, and expectations have made this last two years.

First and foremost, the people are quite different. Network Engineers and Audio Visual Techs tend to work on short term projects (relative), and they are expected to bring a system to a point of completion that is concrete in nature. The system needs to simply run with only user input. Their minds are focused on wrapping up every loose end, labeling every connection, locking down configurations, essentially sealing the system in a sort of capsule. They need to move on to the next project and follow the same process there. It is the nature of the business. It is the rare system that can afford to have one or more staff constantly tweaking and improving the system in perpetuity.

Software Developers live in a world of incompletion. Sure, there are regular feature deliveries, bug fixes and the like. But software is simply never finished. This industry is not for those who are easily frustrated. Where I see a solid sense of urgency in a good network engineer, I see an almost maddening patience with the software developer. There is certainly room for a sense of urgency and a desire for completeness in the software industry. In fact, the preeminent developers I know understand WHEN to switch into an urgent, completion focused mode. Much the same that a truly preeminent network engineer knows when to relax and not panic in the midst of project chaos.

Work habits and team expectations are also radically different. In a network installation, almost every aspect is known prior to the kickoff of a project. You have completed a network diagram, acquired all the hardware needed, the gameplan is ready. The focus is on execution, documentation, efficiency, and quality. Essentially you have a 95% understanding of what you will face during the project.

On a software project it is much more of a journey. You know how the system needs to interact with data and users. You know the technologies you will use (mostly). If you are fortunate you have a fairly good understanding of the components that will go together to make the system work as specified. It is expected that many challenges will be faced in the process. Problems to solve, approaches to choose, and compromises to be made. In all honesty there is roughly a 25% understanding of what you will face during the project.

Throughout my career Microsoft Project has been a go-to tool for me through thousands of projects large and small (wow, I feel old). When I was first charged with managing some projects in software, I immediately leaned on this old familiar tool. The reality was quickly apparent, it was useless for the management of software projects. There is an expectation using Project that you can map the vast majority of the implementation and use its tools to manage the project. I am sure there are plenty of people who have successfully forced this square peg into the round hole. I quickly realized I needed a new approach.

Very early on I was pointed to JIRA by Atlassian software as the leading solution in the space. It took us over a year to decide to pull the trigger and implement, but we got many processes in place in preparation of the move. I have now been working for the last month to set the system up for our team.

The tools and systems are specifically built for workflow, not project completion. There are “micro-projects” where completions occur, but the focus is on managing the work coming in, breaking it down into manageable pieces, and getting them done. I love the swim lane analogy used by the software, it is very analogous to the feel of the software projects.

I will close with an analogy I found very appropriate. Completing a hardware based project is like a hike across town. You know your destination, you can see the path, the obstacles, the spots you will rest along the way. Sure, a big bloke with a club could jump from behind a building and attack you, but you will likely see him coming. Completing a software project is like swimming across a channel. It looks straight forward to an observer but you never know what is lurking under the surface. The process is much more fluid and changing.

I am heading out for some intense training at the Atlassian Summit. It is a very exciting time, one that I have been preparing my mind for these last two years.