Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • Jimi Wikman
    Jimi Wikman

    Setup Jira and Confluence for success - Part 3: Defining Jira workflows

    • Like 1
    • Thanks 1

    In the previous articles we have defined what tool to use for what and what issue types we need. New it's time to define the workflows for those issue types. Before we can do that however we should first define what workflows are and how we should use them in Jira.

    Three types of workflows
    In short we can narrow down workflows to three types: sequential, state machine and rules driven workflows.

    Sequential workflow
    This workflow is usually chart based from one step to the next, always moving forward without ever going back. Each step depends on the completion of the activities on the previous step. You can think of this workflow as a connect the dots system: you have to follow the numbers correctly, one after the other, to complete the big picture.

    State Machine Workflow
    This type of workflow can be considered like puzzle solving, in which you’re constantly putting important pieces in place to complete a project. State machine workflow are frequently used when there are creative elements in the process, or products and services that require extra review or input from clients and management.

    Rules-driven Workflow
    This workflow is executed based on a sequential workflow with rules that dictate the progress of the workflow. This can be compared to following a blueprint to make one complete structure. Rules driven workflows are very useful when working on a variety of projects with clear goals but varying levels of specifications.

    We should also define what a workflow is NOT:

    • A workflows is NOT a process - A process is more then just a workflow as it includes data, forms, reports, actors and more. A workflow usually span over multiple processes as we hand over responsibility between different capabilities (requirement, development, test, acceptance).
       
    • A workflow is NOT a list of unconnected tasks - Unconnected tasks are task management and not a workflow.
       
    • A workflow is NOT a checklist - Checklists are binary. It's either done or not done. That is not a workflow.
       
    • A workflow is NOT a state diagram - This is probably the biggest issue I see when people try to design workflows. The idea that you need to track every single state in a workflow comes from a misunderstanding of who we actually build workflows for and what they actually need.

     

    "A state machine (panel (a)) performs actions in response to explicit events. In contrast, the flowchart (panel (b)) does not need explicit events but rather transitions from node to node in its graph automatically upon completion of activities." - Wikipedia


    Statechart_vs_flowchart.png

     

    Who do we build workflows for?
    In order to understand why state diagrams are not the best choice to design workflows in Jira we should understand who we build workflows for and what purpose they serve.

    The reason we use Jira is because we  want a good way to define and assign work. We also need a way to oversee, or manage, the work. This means that we want a way to track what work we are doing, what the current status is on that work and who is responsible for completing the work at the moment.

    So for developers and testers we want en easy way to see what is ready to be worked on, what is being worked on and and what have we completed. For managers we need the same, but over the whole chain of responsibility. We also want to connect the work to the need so we can follow up when the need is being fulfilled.

    So we have two basic need to fulfill:

    1. What is ready for me to work on?
    2. Are we on track to fulfill the need or do I need to take action?

    In the previous article we mentioned transitional and producing items when defining what issue types we need. We can match these theories with these two need as well. #1 is producing as we just need to track the actual work in a fetch and release process. For #2 we use transitional as we want to track all areas of responsibility.

    Based on this we can see that there is no need to see everything that happen in the work we do. We need to see who is doing what and if there are any impediments that could prevent us from completing the need in time. This is why we choose to work with flow charts and not state diagrams.

     

    "Design for collaboration, not control"

     

    If you feel that you must track every single step in the work, then I suggest you take a look at why you need that. Usually it is because you lack trust in your organization due to poor communication or that someone in the chain of management suffer from an unhealthy need for control. Either way you should fix that outside of Jira as we should design for collaboration, not control.

     

    What statuses do we need?
    So now that we know what types of workflows we have to work with and what the need is we need to fulfill, then it's time to break down what statuses we actually need. We start by defining the different areas of responsibility that we need to track in our workflows.

    • Development
    • Test
    • Acceptance

    First we start with adding a waiting status in each so we can fulfill the need of knowing what is ready for us to work on. This will also allow us to get statistics on waiting periods to see where we have resource issues. We name them the same to keep a proper naming convention: "Ready for <area of responsibility>".

    Secondly we add a status for when someone is working on something. Again we can track this for statistics, but most importantly we can quickly see what is being worked on and by whom. We name this the same as well: "In <area of responsibility>.

    We end the basics with setting a Closed status as the last status. This will allow us to set a resolution and indicate that the development work has been completed and is ready to be deployed. I often see people adding things like resolved or done, but in a workflow you should not have partial closure and there is actually no need for it.

    We now have the basics for a fetch and release process and we have fulfilled the first need.

     

    Skärmavbild 2019-09-01 kl. 14.05.29.png

     

    In order to fulfill the next need we need to add a few additional statuses, but first we should change the starting status. In Jira we have Open as the first status when a  new issue is created. This is a bad status as it is not clear what Open really mean and I have seen whole organizations failing due to this misunderstanding. So we will rename this status to New if we can do that for the whole organization. If not, then we create a new status and use that as our first status.

    In order to track when something is blocked or waiting for something we add a status called Waiting/On Hold. Even though we can use the flag function to visualize this I have found that a dedicated status usually make this far more visible in the boards.

    We will also add a Reopened status in the event that we need to open a closed status for some reason. This either happen because we close by mistake, but in the event that someone actually revoke a closed issue we want to track that. Adding this is a status allow us to define how we want to handle this situation later.

    Finally we will add a status mostly used for defect management, but it can be used in any development workflow. That status is Rejected. While this can sound like a very harsh status it's purpose is to revert something back to the reporter for clarification rather than using the Close status and then Reopen.

    With just these few statuses we can manage both need to see what is ready for me to work on (ready for <area of responsibility>), who is working on what (In <area of responsibility>)and if there are any issues that need attention (waiting/on hold). We can not take any issue type and look at what area of responsibility is involved in fulfilling that task and then map the statuses we have defined to that.

    All generic workflows will have the same statuses. This makes it very easy to work with boards and no matter what capability you work with you always have only 3 statuses to keep track of: ready for me to work on, I am working on this, ready for someone else.

     

    What about release management?!
    Another common question is how I handle release management since there is no statuses for release. The answer to that is that we do not need that since Jira has that built into the core system in the form or versions. Every development should be closed with at least one version in the Fix Version field to indicate what code package the code is placed in. Every defect should also have an Affect Version that indicate what version of the code the defect was found in.

    By doing this we can map what code is in what package, but Jira should never be master for this information. This information should come from Bitbucket, or similar code versioning tool. This is also the same for deploys, which we do not manage in Jira at all since that is a completely different process. This comes from Bamboo or similar tools.

    The idea of managing deploys as a status in Jira quickly become silly as you would have a separate step that happen long after development, test and acceptance has been completed. This task is unconnected to the areas of responsibility. It is not a producing step, just a transportation step that is done not on story level, but on code package level. Like we established above this is not a part of a workflow since it is an unconnected task. We will however keep track of deployment in Confluence, but we will get to that in later articles.

     

    Let's build the default workflow
    Let us take all the theories above and make it real by designing the workflow in Jira and see if it hold up for real work.

    Skärmavbild 2019-09-01 kl. 15.30.53.png

     

    Requirement & business processes happen outside of this workflow. The expectation is that the beginning of the workflow comes in the form of a clarified need as a story. Even in Agile way of working the story is clear enough to be worked on once put into the ”Ready for Development” status.

    Once a story is clear enough to be worked on and we have acceptance from Development and Test, then we move the story to the status "Ready for Development". Producing items are created for development and we start working on the issue  by transition the store to In Development.

    Once done we transition the story to Ready for development to complete the fetch and release process. This is repeated in the test and acceptance steps. In the event that we get a defect, then we create a defect sub-task and block the story from completion. We can use this for all development tasks as they all follow the same path.

    Let's see how we set this up in Jira.

     

    Building workflows in Jira
    In order to build global workflows in Jira you need Admin access to Jira. Go to Jira Settings ->  Issues. Here you will find the two sections we need to configure to build a new workflow and to assign it to a project. Under Workflows you will see the current active and inactive workflows. In the top right corner you will see a button with the text "Add Workflow" Click that and you will get a popup to enter a name for the workflow and a description.

    Skärmavbild 2019-09-01 kl. 15.41.46.png

    Once you have added a name and description you will come to the design view. Here you use the "Add Status" to add the statuses we want. We create them with global transitions to make the workflow as open and flexible as possible by checking the box "Allow all statuses to transition to this one".

    I usually have transitions between rejected and new, as well as for Closed to Reopen, just to make it more clear that the rejection is used in a certain part of the workflow. This way you can't go to rejected or reopened from other statuses than the intended ones. In a proper workforce where the users get education on how to use Jira this is not really needed however so you can skip that if you do not feel it is necessary.

    Skärmavbild 2019-09-01 kl. 15.54.24.png

     

    Add Workflows to a workflow schema
    Now we can go to workflow schemes where you find all your active and inactive workflow schemes. in the top right corner you have a button with the text "Add workflow scheme". Click that and in the popup you add the name and description of your scheme. You will then be taken to the screen where you add workflows to the scheme and map it to specific issue types.

    Click the add workflow button and select the workflow we created earlier. In the next screen you get to select which issue types you want to map to this workflow. Select the ones you like, which should be all of our development issue types and then click finish. Your scheme is now configured with a workflow that is mapped to the issue types you want. You can edit this scheme at any time should you add workflows and/or issue types.

    Skärmavbild 2019-09-01 kl. 16.03.27.png

     

    Add Issue Type Scheme to your project
    Go to your project and then click on project setting in the left menu. It should be at the bottom of the list of areas for your project, but if you can not see it then you may not have admin rights for your project and you need to get some help with this step. If you have access then in the project settings go to Workflows.

    Here you see your current workflow schema and the workflows attached to it. To change click on "Switch Scheme" and select the new scheme that we created above. Click associate and if needed map statuses on the next screen and wait for all statuses to resolve. Once done you have your new workflow scheme mapped and you can start using your new workflow.

    Skärmavbild 2019-09-01 kl. 16.09.44.png

     

    We now have workflows setup for our issue types, but we still have a few things to do before they are completely ready to be used. That is to define the screens and custom fields we will use in our setup. That will all be explained in Part 4: Defining Jira Screens & Custom fields that we will look at next.

     

    Edited by Jimi Wikman


    • Like 1
    • Thanks 1


    User Feedback

    Recommended Comments

    There are no comments to display.



    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Paste as plain text instead

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.


  • Similar Content

    • By ©Jimi Wikman
      As an Atlassian Platinum Solution Partner Enterprise and a Platinum Top Vendor in the Ecosystem, we’ve been working hard on enhancing the use of Jira Software for over 2500 business teams around the globe. This app adds Requirements, Test Plans, Test Cases and Test Executions panels to your software project in Jira and thus allows you to track the whole development process from collecting requirements to going to production in a single place.   Try the app out for free on the Atlassian Marketplace:    Follow us on other channels:
      https://www.linkedin.com/company/devi... http://twitter.com/deviniti_voice http://facebook.com/DevinitiPL
    • By + Michael Karlsson
      Michael is passionate about test, QA, requirements work and agile a way of working. He is happy to work hands-on as test leader / test coordinator / tester. Michael has worked on developing complex system solutions where quality in business and deliveries are important. In many cases, his work has led to an increased productivity for the test area.
      Michael is a problem solver where his dedication inspire the team. He like to support others and to share his knowledge. He thrives best when he can combine test management with testing and requirements work in close collaboration with customers and developers. Michael speaks and writes freely in Swedish and English and has extensive experience working in international environments.
    • By + Patrik
      I am a senior Test management consultant with proven ability when it comes to helping development teams deliver tested working software faster with minimal impact on time to market. I like to think I have a professional and humble approach with the ability to perform well under pressure and as a a person I have gotten feedback that I'm easy to work with and to gain confidence in. I like to set set goals and then achieving them.
      Areas of expertise: Acceptance testing, Business analysis, Team lead, E2E Testing using automation, Continuous testing and much more.
      I have:
      20+ years QA experience from retail, telecom, finance and travel industry.
      10+ years experience working as a consultant in agile projects
      6+ years experience from various E-commerce implementations
       
      On a personal note I live south of Stockholm with my family and I enjoy sports, traveling and movies.
    • By + Sundhar Manian
      Project Management | Quality Assurance | Service Management | Scrum Master | DevOps Project Manager
    • By ©Jimi Wikman
      Requirements in Jira has long been a wish for many Jira users. Many have tried it and many have failed because Jira is not designed to work with controlled requirements. Because of this I have always suggested to work with requirements in Confluence, but with RTM from Deviniti, I might change my mind about that.
      I am a certified requirements analyst and as someone who works in all positions in a development process I know the importance of good requirements. While good communication is key for a good workforce it does not remove the need for controlled requirements. In Jira you can setup requirements as part of a workflow or as a separate issue type, but the experience is far from controlled.
      When I saw RTM from Deviniti for the the first time I was intrigued. It looked very similar to older systems like HP QC (now Micro Focus Quality Center) in it's structure. I installed it on my Jira instance and have played around with it for a while now. So far I am very impressed, especially since Deviniti have confirmed that some of the things I miss are in their roadmap.
      Requirements & test management in Jira
      RTM comes with five main modules, plus a bunch of reports. The modules are all customizable so you can define what issue types you want to map with what module. This is great because that way I can map towards already existing issue types, or custom make new ones if needed. For Defects I can even map multiple issue types, which is great if you like me use both Defect and Incident. This is also possible for Requirements which is necessary for working with multiple types. In my setup I only have functional and non-functional requirements, but you can add more if you like.

       
      The RTM Requirements module
      This is the exciting part of RTM! Working with requirements in RTM feels just like in ALM or other older systems, but with the ease and great usability of Jira. You can quickly create a tree structure and rearrange the tree is easy and fast with drag and drop. Existing requirements can be imported using the import function that is located in the left column where the tree is under the three dots.
      You can customize the tree structure in the RTM configuration that is located under project settings. There you can select if you want auto numbering and if you want the issue number to be written out or not.
      While we still miss a few things (see below) this is really a great start. It is by far the best requirements app for Jira I have seen so far.

      The RTM Test Cases Module
      Test cases are reusable tests with test steps that you use in the test plans to perform tests. RTM is competing with some big shoes in the test department, but they hold up pretty good here. I like the configuration for the test steps that you have in the RTM configuration under project settings where you can modify the columns for the test steps. This allow me to define what columns I want with ease. You can also select what the starting status is, but right now you can not add or edit the standard statuses.
      As with all modules you can import existing test cases using the import function above the tree structure where you see the three dots.

      The RTM Test Plans Module
      Test plans are equally easy to create and manage. In the test plan you connect test cases and test executions to get the full overview of the test scope and result. In the overview of the test cases connected to the test plan you can change the order, create new test cases or add test cases.
      To me this gave a very good overview of the scope, what was actually tested and I have plenty of room to describe the test plan without cluttering things up.

      The RTM Test Executions Module
      The test executions module allow you to quickly execute test plans and you can structure them the same way as all the modules. You can re-execute test executions, which then create a new test execution that you can place in a folder directly. This is great for example smoke test that you want to run frequently.
      There are some things I think can be improved visually, but overall this works pretty well.

      The RTM Defects Module
      The Defects module give you an overview of the defects in the projects.  If you are adding RTM to an existing project where you already have defects, then you can easily import them using the import function. It is a bit hidden, but you find it in the left column under the three dots.

      The Good and The Bad
      There is not a whole lot to say on the negative side of this because it works very well. I tested this with Portfolio for Jira and the result is amazing. You easily get the structure you need for a full parent-child tree structure and the modules in RTM provides a great focus area for requirements and test.
      Version management
      What I miss are the version management that absolutely must be there. This is one of the things that are on the roadmap for the future. Hopefully this can tie into some form of approval process to better control changes. This is important for large organizations, but also for non-functional requirements that usually are global.
      Acceptance Criteria
      This is also a thing that is currently missing and also on the road map for future updates. If these could work the same way as the test steps work today, or maybe even having them as separate entities like test cases, then this would be amazing.  This would allow for really powerful connectivity between not just requirements and test, but also defects and requirements.
      Import from other projects
      One of the things I miss is the ability to import from other projects. This is especially useful for non-functional requirements that are often shared between many projects. I would like to be able to import these as read only so I can have them as part of the requirement structure, but not be able to edit for example legal requirements. I can make a requirement in the existing project and link for now, but I think import as read only would be a better solution.
      Quickfilters in Defects module
      The only thing I miss here is the possibility to add quick filters, just like in boards. This would allow me to better use this view based on my need. I found myself jumping to filters a few times to get a more focused view and with quick filters that would not be necessary.
      The Module Templates
      While the modules are not terrible in terms of visual they could improve a bit. Things are a bit cluttered and the tabs are not super obvious at first glance. Here I would like to see a slight update using Jira standards, but we also need templates to add custom data for example. Based of the structure with tabs I think it would be possible to use the standard view design and just split it in the different tabs for starters.
      Better integration with Confluence
      If I add a Confluence link directly into the issue itself, then it show up as just Wiki page. This is not very good as I want to see the name of the page so I know what page it is referring to.
      Other Apps support
      Right now I can't add other apps to the modules view, which is a bit of a problem for the requirements part especially. I often add designs using Invision prototypes and if that is not shown in the modules view, then I have to jump back and forth between the issue view and the module view. That is not good and I think this need to be added to the modules template designs.
      Test Executions UX and Visuals
      The test executions are a bit clunky when it comes to the UX. I find myself getting a bit lost as things happen without me being in control and I sometimes end up in the test issue view instead of the execution view. I would like to keep the execution summary in the header so it remain consistent and so I can come back to the execution overview instead of the issue view.
      The statuses are not tied into a workflow, which means that you need to skip back and forth to manage your test executions. A mapping in the settings would be nice so I can map execution statuses to workflow statuses. Also, there might be a good idea to separate statuses from resolutions to keep in line with Jira standard.
      Colorful folders
      This is just a cosmetic thing, but I like to be able to differentiate folders using colors and icons. This makes it a whole lot easier to quickly find the correct are, especially for large trees that often occur in requirements for larger systems. it would be very nice to have the option of selecting colors of the folders and special icing on the cake if I can select an icon as well. It would be easy to just use FontAwesome for example and allow the user to pick the icon from the font set.
       
      My opinion on RTM from Deviniti
      This is by far the most complete solution for a functional way of working with requirements and test in a controlled way. It still need some work here and there, but I will recommend this to all my clients as it stands today. Even without version management or dedicated sections for acceptance criteria it is still far, far better than what most people have today.
      When this product get more polished I think this will be one of the must have apps in pretty much every Jira instance.
      I like it. A lot.
×
×
  • Create New...