Opinions, thoughts, and ideas on leadership, management, software development, and people development.

Category: Thoughts

How To Create JIRA Workflows – Beginners Guide

Creating workflows in JIRA might be a daunting task if you don’t get the foundation right. As a beginner, you need to understand first some basic concepts before implementing your first workflow or adjusting an existing one. I’ll share with you 3 easy steps to create your JIRA workflow.

I’ll explain below these basic concepts and will also provide a step-by-step guide on how to set up a basic workflow in JIRA. Keep in mind that in order to create workflows in JIRA you have to have JIRA administration rights, otherwise you won’t be able to manage workflows. Also, I created this tutorial for JIRA Cloud because it’s the most recent and accessible JIRA version. Most of the ideas presented here are also applicable to hosted versions of JIRA.

The use case I’ll use as a base for this tutorial is that of person who has a project in JIRA with a default JIRA template workflow and wants to replace it with a new one customized to her team’s needs.

Basic Concepts

The work flows from a series of steps, starting at an initial step and then moving forward, and sometimes backward, step by step until its completion. A step in JIRA is known as a “status”.


A status in JIRA represents the current situation for a particular issue on a given time. This one is easy to understand. For instance, we can say that a particular issue in “In progress” or “In Review”. Ths situational representation is what we call “Status”.

You can have as many statuses as you want in your workflow, but keep in mind that the less the better.


Transitions are the bridges from one status to another. A transition is an action and represents the movement of a particular work from one state to another.

For instance, one might want to “Start working” on a JIRA issue. Once you sign that you want to “Start working” on a JIRA issue, you’ll also execute a transition from the current state to a new one which says that now the issue is “In progress”.

On JIRA cloud, transitions will appear like this:

JIRA Cloud – Transition example on issue screen

On JIRA Server, transitions will be usually represented as buttons at the top menu of the edit issue screen.


JIRA has three types of work category:

  1. To Do: Work that is waiting to start.
  2. In Progress: Work that is being worked.
  3. Done: Work that was finished.

No matter which status you create, you’ll have to define to which category the status belongs to is it has to be one of the three listed above.

Each category has its own colour as well. To Do is grey, In progress is blue, and Done is green, as seen in the image below:

Image showing three different categories, each one with a different colour.
JIRA Cloud – Issue Catetories

Why this is like this? Well, I don’t exactly what was the reason, but it’s easy to infer that it was done this way to simplify a lot the way they do their reporting calculations. But that’s going off-topic. Let’s get back to the workflow creation topic.

Just as a curiosity, on JIRA Server, the colour representing the “In Progress” category is yellow and not blue as in JIRA Cloud.

Create Your First Workflow In JIRA

Step 1: Start With Pen and Paper

Before jumping into implementing the workflow in JIRA, start with pen and paper and do some research in order to understand which workflow you’ll have to create. Ask someone in the team to verbally describe their workflow. Take notes of the words they use and convert that into a list of steps.

When creating workflows in JIRA, the best way to start is with pen and paper. Talk to people and ask them to verbally describe how they work. Take notes of the words they used and convert that to a draft workflow that you can use to start… Click To Tweet

Example of a conversation that you might have

Alice: Hey Bob, I’d like to design and implement the team’s workflow in JIRA, but first I’d like to understand how the team works. Could you describe to me which steps you usually do from the moment you get something to do to the moment you consider it done?

Bob: Sure, well, usually after our planning meeting we have a set of issues we selected from our backlog as the ones we’d like to implement during the week. Then, we assign ourselves to one of the issues we’d like to work and start the development. Once the development is done, I submit the code changes to code review, then I interact with people base on their feedback and fix any issue that might be reported to me. When the code review is done, then I integrate the code. This is the last step where I do the integration of the code into the main branch, wait for the feedback from the tests, check our internal dashboards and then if everything goes well I consider this work done.

Alice: Great. I think I got it. Thank you very much for your time.

Bob: No worries

From the chat above, Alice might come up with the following list of statuses (steps):

  • Backlog
  • Selected for Development
  • In Progress
  • In Review
  • Integration
  • Done

With this list at hand, Alice can then layout the flow between these statuses and define the transitions as well.

Backlog => Selected For Development => In Progress => In Review => Integration => Done

Step 2: Create A New Workflow In JIRA

In order to create a new workflow, go to the JIRA Settings > Issues > Workflows:

Bottom left JIRA menu bar highlighting the settings option.
Bottom left menu bar
JIRA cloud settings menu with the Issues menu option highlighted
Select the “Issues” option
JIRA cloud Issues menu with the Workflow menu option highlighted
Select the “Workflows” option – If you have trouble to find this expanded menu, press [ on your keyboard or click on the hamburger menu at the top left to expand the Issues menu options.

Now that you know the hard way, I’ll share with you the shortcut. By typing the following URL you can easily access the workflows configuration screen:

https://[YOUR ID].atlassian.net/secure/admin/workflows/ListWorkflows.jspa

If you landed on the screen below you’re in the right place.

JIRA cloud workflow configuration screen
JIRA Cloud – Workflows Configuration Screen

Now, click “Add workflow” to start creating a new one.

JIRA Cloud - Workflows Configuration Screen - Add Workflow highlighted
JIRA Cloud – Workflows Configuration Screen – Add Workflow

Give a name to your workflow and add a description for it and click “Add”.

Once add your new workflow you’ll be presented with the “Workflow Editor” which will be similar to the one below:

JIRA Cloud - Workflow Editor - Newly Created Workflow
JIRA Cloud – Workflow Editor – Newly Created Workflow

Now let’s have some fun. I usually first add the statuses I need. In this case, they are:

  • Backlog
  • Selected for Development
  • In Progress
  • In Review
  • Integration
  • Done
JIRA Cloud workflow editor - adding a new status
JIRA Cloud workflow editor – adding a new status

Don’t mind clicking the “Allow all statuses to transition to this one”. We won’t need that. You’ll notice that for some statuses you’ll have to create new ones since they might not exist yet on your JIRA instance. Don’t worry, just click “new”, provide a description and set the correct category as exemplified below:

Adding an inexistent status
Create New Status Screen

After you added all the statuses, it’s time to wire them up using transitions.

JIRA Workflow with all statuses in place

Click “Show transition status” at the top bar on the workflow editor and let’s move on. Now, reconnect the “Create” transition that is connected to “Open” to the “Backlog” status and delete the “Open” status by selecting it and clicking on “Remove status” as highlighted below:

JIRA Workflow - Removing a status
JIRA Workflow – Removing a status

We’re almost there, don’t give up! Now, create the remaining transitions between the statuses. Do that by hovering over the origin status, in this case, “Backlog”, and dragging your mouse until one of the connection points on the target status, which in this case will be the “Selected for Development” status. See the images below for an example:

JIRA Workflow – Connection point when hovering over a status
JIRA Cloud - Linking statuses through transitions
JIRA Cloud – Linking statuses through transitions

Now, give a name for your transition and add a description that will help people to understand what will happen when they execute this transition. Once that’s done, click “Add”, and Voilá! You just created your first transition.

JIRA Cloud – Add Transition

Now repeat the same process for the remaining transitions and in the end you’ll have created your workflow and it should be similar to the one below:

JIRA Cloud – Example workflow

If you reach this far, congratulations! Now you’re very close, just a few more steps and you’ll achieve what you want.

Step 3: Changing And Publishing the New Workflow

Changing The Workflow

Now we have to go to our project settings to change the project’s workflow to the one we just created.

Go to your project and click “Project Settings”.

JIRA Cloud - Project Settings
JIRA Cloud – Project Settings

Once in the project settings, click “Workflows”.

JIRA Cloud – Project settings – Workflows

You have now two options, you can either change the workflow scheme or add an existing workflow. In our case, we want to add an existing workflow. So, click on “Add workflow” > “Add existing” and choose the one you created in the previous step on the selection screen.

JIRA Cloud - Project settings - Workflows - Add Existing Workflow
JIRA Cloud – Project settings – Workflows – Add Existing Workflow
JIRA Cloud - Project settings - Workflows - Add Existing Workflow - Selection Screen
JIRA Cloud – Project settings – Workflows – Add Existing Workflow – Selection Screen

Now, click “Next”, assign all the issue types to the new workflow and click “Finish”.

JIRA Cloud - Project settings - Workflows - Add Existing - Assign Issue Types
JIRA Cloud – Project settings – Workflows – Add Existing – Assign Issue Types

Great, now you should see the workflow screen again with the new workflow being displayed! Great!

JIRA Cloud – Workflows – Changed but Unpublished Workflow

Publishing The Changed Workflow

Now, click “Publish”. You’ll go through a two-step process. On step 1, click “Associate”. Wait for step 2 to finish and click “Acknowledge”.

JIRA Cloud – Workflow changed – Acknowledge step

Congratulations! You did it!

Step 4: Check The Result

I usually check after every workflow change if everything is working as expected. I advise you to do the same. Create a test issue and make sure it can flow through your workflow as expected.


Creating a JIRA workflow might not be as hard as you think if you just get to know some basic concepts and understand how to wire things up in JIRA. To make things easier, I prepared a one-pager that will help you with this task. You can download it for free below.

If you’re working with a different version of JIRA, perhaps JIRA Server and are having trouble to figure out how to do it, just let me know on the comments below and I’ll do my best to help you.


I’m not affiliated with Atlassian, the owner, and creator of JIRA, nor receive any benefits for creating this tutorial from Atlassian. This tutorial is totally independent and based on my own experience. Any mistakes, inaccuracies or misinterpretations are my own.

You Don’t Lose Your Job. Your Company Loses You.

One of my fears was to leave my country and go to another country to learn about human development and technological entrepreneurship. I pointed out that this will imply into losing my current job and will affect my comfort levels (I was in the comfort zone).

From everything above, I’d like to highlight the word “losing” in “losing my job”, because today, 6 years later my immediate feeling when I read this word was not a feeling of loss but a feeling of winning. I might have been a losing situation for my forme employer, but for me, what initially seemed as a loss was indeed a win, but at that time I couldn’t recognize that. And I’m curious to explore why did that happen and happens from time-to-time still today with me and I bet with many other people as well. Why do we say “I’m afraid of losing my job” instead of “I’m afraid my current employers will Lose me”? Why do we have so low self-esteem and we see ourselves highly dependent on our jobs?

I’m not a scientist or an expert on this matter but I have my empirical knowledge that helped me to understand some perspectives or triggers that usually led us to think like that.

The first trigger or constraint to different thinking is without a doubt: Income. If your only source of income is what you get paid as a result of the work you provide to your employer, then you might think that if you can’t provide this work anymore you Lose your income, and that is what makes you state that you’re afraid of losing your job, when in reality you’re afraid of losing your income.

If you think about this topic, the only strong bond that ties you to your employer is your income. If you somehow make you less dependent on that, you’ll start seeing things differently.

Now let’s explore other perspectives that might establish a different mindset.

Companies don’t exist without employees. The levels of dependency might vary, but they’ll depend on your services provided by people in order to exist. So, you’re the most important asset for the company followed by the company’s product, which is also created by the services you provide. Just that should be enough to give you the frame you reference you need to see yourself as key for the organisation and your organisation should see yourself the same way as well. Because we’re now facing more and more shortage of workers, it’s becoming every year more and more clear that if companies don’t start treating people well they’ll lose, and will Lose badly.

Another perspective is that you own the skills you acquired, you worked hard to assimilate them, learn them, put them in practice in order to acquire experience, and this is the value you provide to the company you’re working for. The ability to use what you know to build the company’s vision. You’re renting your services to the company and the company is paying you in exchange for your knowledge. Let’s say the company don’t need or you don’t want to provide your services to this company. That’s a perfectly fine situation, looking just at this perspective, and you should see as a natural evolution of yourself. You’ll now use your skills to help other companies that will still need your services and will pay for it.

There are a few variables that might influence your ability to make these transitions easily. If you are a specialist in an area that it’s not in high demand or it’s a very specific area, you’ll probably won’t have too many companies in that area where you can move to. That becomes a constraint for you that that’s something you should evaluate how to mitigate in order to reduce its influence on your ability to stay dependent on your current company. Another variable would be if you’re entering the market. You might not have too much experience yet, that means your options might be limited as well. Age, industry, your personal situation, all are also variables involved in the equation of employability.

What about low skilled jobs? People should aim to improve their skills. They should not accommodate and don’t improve their skills. Governments should support them to improve either by subsidising training, supporting in career planning, and through better public policies that incentivise professional development alongside social support. And they should own the responsibility to improve themselves as well. Just waiting for a magical solution that will make you more valuable in the market won’t happen.

What can employers do to help? Stop exploring people as resources. We’re not resources anymore. We’re people and we need support to grow and be fairly treated otherwise “You’ll Lose me” because I’ll find a place where I do have such conditions.

What about high skilled jobs? People should not focus only on getting money, but focus on what they really want to do professionally and take advantage of this great situation to create the best version of themselves.

In summary, there’s always a way and something you can do without depending on anyone that will minimize the impact of constraints and potentialize the influence of variables, such as experience, domain knowledge. These actions might increase your chances of having a higher level of work mobility to a point where you can say “I’m afraid this company will Lose me” instead of “I’m afraid of losing my job”. Stop for a while and do some research on how to overcome fears, how to do career planning, how to do goal setting, etc. These tools might help you a lot to adjust your frame of reference around this topic.

A Frog or A Horse?

What do you see on the picture below?

What do you see in the image below?

And now, if I turn the image 90 degress clockwise, what do you see?

Most people will see a frog on the first drawing and will still see the same frog in the second drawing, but some people will be able to see a horse in the second drawing, and a few people will recognize both the frog and the horse already when looking at the first drawing.

Which one is right? Why some people see first a frog and why others see first a horse?

Our perception of the world that surrounds us can change as quickly as we learn and absorb new knowledge and experience. And that it’s totally ok!

The way you see or understand a situation presented to you is based on the frame of reference you have at that moment in your brain. It doesn’t necessarily represent reality. What you get is an interpretation of the reality based on your beliefs and experience, your mindset.

Another person with a different background and life experience might interpret the same situation at hand differently and build a different reality. That’s the reason why is so important to be super careful about what you think and really reflect on how these thoughts and interpretations are influencing your actions and behaviours.

The problem is when you don’t recognize this dynamic and believe that the map you have, which most of the times you don’t even know that exists, is the only one that matters and the truth. That’s when people start to become pushy, dictatorial, etc.

When you don’t accept that there are other maps and consequently other interpretations of the same reality, you’ll not advance yourself as a person. You’ll be a prisoner of limited interpretations. Yes, some maps are better than others. They have a better representation of the terrain and the key for me is that one can develop a mechanism for recognizing such better maps and improving her own maps.

Acknowledging this natural law and being open to evolving your maps, your frame of reference, is what will really make a difference in terms of personal and professional evolution over time.

If you want to know more about this topic, I highly recommend reading this book: The 7 Habits of Highly Effective People.

An extra challenge for you: What do you see in the image below?

Did you see the young and elegant lady? Or…

The Truth Is In The Past. How the UNIX design philosophy inspired nowadays software development

I watched Jez Humble’s talk at Agile 2017 and among many insights, one particular thing caught my attention.

He based his continuous delivery philosophy on the UNIX design philosophy.

I’m a big fan of UNIX and everything it powers nowadays. However, this connection between UNIX’s design philosophy and Jez’s Continuous Delivery approach was very intriguing for me. You can watch the talk here. Skip to minute 4:30 to watch the UNIX part of it.

I’ve read the referenced paper on his slide and surprisingly enough I discovered it very up to date as for what we’re having nowadays as trends in IT. You can read the paper UNIX Time-Sharing System: Forward. (McIlroy, M.D.; Pinson, E.N.; Tague, B.A.) here.

A quick Look at UNIX system design style and some parallels I made

Make each program do one thing well. To do a new job, build an afresh rather than complicate old programs by adding new features.

This principle could perfectly be a description of the overall idea behind Microservices. Also, I can related two of the SOLID principles with it: Single Responsibility and Open Closed.

Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.

This sound a lot like an API and its relatives like Design by contract, APIs first.

Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.

Impossible not to remember of a Prototype reading the principle above. Also, Iterations, Sprints, Fast feedback loops, Spikes.

Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them.

Workflow automation and supporting tools for software development such as IDEs, Analysers, CI/CD, Platforms, high-level languages, etc.


An insight I had while reading the paper was realizing how pretentious or arrogant some inventors/creators are when they believe that they truly invented something revolutionary or even when we master certain skills that we ignorantly think is new but are nothing but old very good software development most of the times with a cool name or wrapped up on a framework.

This kind of material should be more available to every developer. I’m sometimes concerned with people that take courses on HTML, CSS and JS and assume they’re good developers right after finishing the course. They have so much to learn as I do even after all these years of software development. Also, all the agile movement should acknowledge that in the great majority of the cases they just made smart things invented in the past more accessible or sellable.

So in general, I started to believe that part of the truth on how to build quality and sustainable software resides in the past and it’s just waiting for us to discover it. Perhaps this will reduce a lot of the hype we’ve seen lately and we’ll be able to focus more on what we really like, well at least the great majority of us: Software Development.

3 Statements That Don’t Leave My Mind

Recently I’ve read some statements that keep coming to my mind at least once a week maybe more.

1 – Make it work, Make it write, Make it fast

I’m a big fond of the concept of “Right first time” but lately I’ve seen so many time being wasted trying to figure out what would be the “Right” thing to do. Many unnecessary conflicts, concerns, non-validated assumptions, etc. This made me think more often about extreme interpretations or even shallow interpretations of such concepts that when not fully understood or discussed could lead to inefficiencies everywhere.

When I have such thoughts I remember of this concept that says: Make it work, make it right, make it fast! I don’t remember exactly when I’ve heard it for the first time but I’m sure, unless my brain is tricking me, that I’ve heard it during some research about game development (which is something I kept coming back to from time-to-time) and it was related to Blizzard, one of the big players in the game industry.

Later, after some additional research, I discovered that this term is actually attributed to Kent Back and it was part of the UnixWay for a long time.

You can read more about it here: http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast

Anyway, the whole idea is that when solving a problem in an iterative way you should consider to first make something that works, even if it’s not the right perfect solution. Ship it and learn from the feedback you’ll get in order to go to the second step, make it right. After rounds of improvement based on feedback then you’ll have to at some point make it fast. That will be the last step. That’s at least the intepretation that makes more sense to me.

I just feel that many times this simple and pragmatic approach will bring much more value than trying to use a sophisticated one just because everybody else is doing. But that’s just a feeling. I don’t have any data or experiment that can prove that, so maybe in the future, I can experiment with this approach and see what happens.

2 – The tiniest thing shipped is better than the best thing planned

This was something I’ve read on a blog post published by Amy Hoy on how to overcome procrastination.

You can read it here: https://stackingthebricks.com/how-to-overcome-procrastination/

This statement resonates with me because it sounds very responsive and lean, which is something I like. Also, it has a connection with the first idea as well, I believe. Living in the world of ideas and planning is super comfortable and can make you feel in control of things, but the truth is that the time will pass and all you’ll get is pure fantasy.

I spend so many hours planning stuff. I do that every day as part of my job, and I do that every day as part of my personal development. I try to make it as lean and efficient as possible. However, my feeling is that last year I tried to have the “best thing” planned instead of just shipping stuff to the real world, even if it was something small. Although I shipped, for instance, an email plugin for JIRA named Issue Events Mailer, a crap todo list style bookmark app, and another small attempts into the real world, I just have the feeling I could have done more if I had this “mantra” in my mind every time I questioned myself if what I was doing was of any value.

3 – A good plan is worth its weight in (future) gold

This one came from the same article mentioned above and also resonates with me because I learned that no plan survives contact with enemy

Also, I learned during these years of professional contact with lean and agile methodologies how bad too much planning can be. I’m not saying that plans should not exist, but we have to understand how much effort we should put on them before actually putting it in practice. At some point more planning is pure waste of time and energy that could be used for other valuable actions or tasks.

In the past things were so expensive that a well-thought plan was mandatory. The cost of repairing an error was too big. This is still true for some industries or fields of knowledge nowadays but for the great majority of software-based projects, for instance, I see these practice of thorough planning not optimal. Today is cheaper to quickly iterate, ship something, learn from it and use the feedback as input for a new iteration. That’s the base of lean and agile product and software development. Very quick cycles of plan-do-check-act. This makes me think that often just having alignment and shared understanding around the problem we’re trying to solve will be enough to a team or a person to start developing something and especially delivering something that can be used and criticized – in a constructive way – early and often.

Yes, I might have generalized things a little bit. Reality might be not as sweet as I’m painting above, but in general I believe that this principle and the previous ones should be taken more into consideration when we do or plan our plans.

© 2019 jcfausto

Theme by Anders NorenUp ↑