Practical Customer Participation in JIRA Workflows
This second part of our blog series continues with the topic of direct involvement of customers and gives some practical examples of when, where and how to introduce and include your customer into JIRA. We will then discuss two of mgm’s proven real-world workflows and use them as case studies about appropriate modes for successful customer participation. You will also learn about our recommended ways of keeping the complexity of huge JIRA projects from the customer.
Let’s begin with how JIRA can be utilized during the initial project phases. The main steps here are to prepare a more detailed business modeling and to complete the technical and business concepts. These steps are tightly connected with the compilation of the requirements and the requirement management phase. The requirement analysts of the project and the responsible project manager will interview all the necessary stakeholders to get a complete picture of the required solution that the business modelers and architects need for their work.
Capturing Requirements as JIRA Tickets
During this requirement management phase all the collected functional and non-functional requirements will already be stored as JIRA tickets to control their content and impact and to prioritize them with respect to the solution and its implementation order (planning process). And exactly this phase can be used to create a first contact point for customers with JIRA: Involvement in the compilation of new requirements and detailing of already filed items.
But as the customer is not yet very familiar with JIRA in this very early stage, we typically choose to create all the new requirements tickets ourselves instead of the customer. This is not just to unburden the customer: we also want to avoid the additional work of correcting imprecisely formulated requirements.
The descriptions of requirement tickets should always be unambiguous and complete. Thus, the responsibility to verbalize requirements usually remains with us. But the customer can be involved at any time to contribute details and he can (and should) be an active part during the elaboration phase and deliver his input and expertise through comments to the respective tickets.
Another very important point in requirement management is the used terminology. It is very important to always talk (and to write) the customers’ domain specific language. Use only terms that can be understood by the customer! We find it very helpful to maintain a glossary of all domain specific words and terms together with the customer.
Customer Involvement in the JIRA Requirement Process
In addition to detailing the content of requirements and ensuring their correctness, the customer can take over two other important tasks in the requirement process:
- Assignment: Once a requirement is elaborated, the effort estimated and it is ready for realization, it has to be assigned to the supplier (us) for release planning and implementation.
- Approval: When the requirement is implemented and approved by the development team and our internal quality assurance, the realized requirement is ready for approval by the customer.
Both of these steps (assignment and approval) can be realized as workflow steps for the issue type “Requirement”. Dependent on the character of the project and customer, mgm runs projects with different levels of integration.
Proven Workflow Implementations
Let’s take a look at two requirement workflows that we designed for our projects, each with a different integration level of the mentioned steps.
This first workflow (shown above) contains a dedicated step to alert the customer that the requirement is “READY TO ASSIGN”. On his dashboard the customer has a portlet listing all these ‘marked’ requirements as a working queue for assignments!
It is not strictly necessary that the customer himself executes the transition “assign” in JIRA. We have projects where the requirement assignment is officially sent via mail or e-mail by the customer. In these cases, our requirement manager performs the transition on behalf of the customer. But we also have projects where the customer himself pushes the “assign” button in JIRA.
Following the implementation part with the steps “IN PROGRESS”, “RESOLVED” and “CODE-REVIEWED”, the requirement workflow contains the steps “READY FOR TESTING” and “VERIFIED”. During the software approval stage the customer can use these dedicated steps to manage his testing and approval tasks. Once again, the needed filters are integrated into the customer dashboard. The development team will explicitly hand over all implementations that passed internal quality assurance to the customer. The approval transition “VERIFY ISSUE” will then be executed by the customer himself. Usually we convince the customer to do this directly in JIRA.
In this first example, the step “REVISION” of the requirement (the elaboration phase) is separated from the step “ESTIMATE”, thus the customer will keep the control of ordering the effort estimations.
Now let us consider a second workflow example as depicted below:
The interesting parts here are the initial step “DRAFT”, the step “ANALYSIS” (before “REVISION”) and the approval step “SIGNED OFF”. The “DRAFT” step is especially useful if customers create requirement tickets by themselves. The distinct step “ANALYSIS” is an independent elaboration and phrasing phase for the customer (typically when they have a dedicated operations department) whereas the step “REVISION” is an elaboration phase for the project team (development). At the end of the whole implementation process the customer can use the step “SIGNED OFF” for the approval process.
Overview: Where and How to Involve the Customer
Requirement management is an obvious area for direct participation of customers, but more traditional areas like “bug tracking” and “change management” are also potential candidates for customer involvement.
Below is a collection of areas where we constantly try to convince our customers to participate directly within our established JIRA processes:
- Requirement management
- Input of new requirement tickets
- Direct participation in the elaboration phase (optionally with additional workflow steps)
- Assignment for realization (workflow steps)
- Testing and approval of implemented requirements (workflow steps)
- Change management
- Input of new change request tickets
- Direct participation in the elaboration phase (optionally with own workflow steps)
- Assignment for realization (workflow steps)
- Testing and approval of implemented change requests (workflow steps)
- Bug tracking
- Input of new bug tickets
- Testing and approval of fixed bugs (workflow steps)
- Software approval process
- Execution of dedicated testing tickets
- Approval of all individual development tickets (requirements, change requests and bugs) (workflow steps)
- Issue the final software (or release) acceptance (workflow steps)
The “Change Management” process has to be aligned with the customers’ organization structure and change process. We experienced that especially change management is in most cases an already well defined process at the customer side. However, for “Change Management” we can typically apply the same workflow as for “Requirements”.
“Bug tracking” nowadays follows standard workflows. But bug tickets are also development tasks, i.e. changes to the product/source code. Thus, we extended the bug workflows with steps representing the approval and quality assurance parts (“READY FOR TESTING”, “VERIFIED” and “SIGNED OFF”) as well. This applies to all issue types leading to development activities where requirements and change requests just represent the controlling/management part and not the realization part, e.g. Requirements, Change Requests, Bugs and dedicated implementation tasks.
Dedicated JIRA Projects for the Customer and Development
Sometimes the periodic amount of JIRA tickets (e.g. needed for a software release) exceeds the “pain” threshold (typically > 300 per release) and the customer is beginning to loose the project overview and feels lost in the overwhelming amount of requirements, change request, bugs, QA tasks and tasks in general. Our recommendation for these cases is to split it up and create 2 dedicated JIRA projects:
- Customer facing project: Used for all operational bugs and incidents (source: customer and end-user), comprises the complete requirement and change management and the software approval process.
- Development facing project: Used for all bugs during the development phase, all implementation tasks derived from requirements and change requests, development internal quality assurance tasks, all tasks that are related to the project in general, etc.
The ticket handling is very easy: Assigned requirements within the customer project are just cloned and moved to the development project. The original and the cloned requirements are then automatically linked by JIRA. In the development project you can then create the appropriate division into implementation tasks needed for your team and component diversity. The status update of the customer’s source tickets (linked tickets) has to be done manually.
The development project is typically only visible for the development team and not for the customer. When we did this in the past, the customer’s initial doubts that we just want to hide information from him could always be resolved by simply opening the development project to him and showing him the hundreds of (open) tickets. Normally he would loose interest in this project very quickly because he is not getting any additional benefits out of it. On the contrary, he will be getting rather confused by the amount of information.
We’ve made really good experiences with the concept of 2 dedicated JIRA projects for the customer and the development, respectively. But there is a second way to remove redundant information from an overstrained customer. You can use JIRA’s security level concept. This way you can keep all tickets in one JIRA project. But you will then have to cope with the maintenance of security settings at ticket level due to the fact that security levels have to be set manually for each required ticket. To set a default security level is counterproductive because then every customer created ticket will be automatically hidden from the customer directly after creation.
In our experience the advantages obtained through direct participation of customers in JIRA exceed the disadvantages of for example the increased efforts necessary for JIRA configuration. A well informed customer who is directly involved in his project feels much more comfortable even if something goes wrong or the progress of the project gets stuck. Transparency is the magical keyword.
But you have to accept that every project has its own characteristics. It will be mainly influenced by the customer’s character, organization and stakeholders. You have to find the most appropriate and fitting level for a customer’s direct participation. Try to get the most accurate picture of the stakeholders you have to work with and then decide how they could fit into the process. And keep in mind that the process can always be adapted afterwards in order to achieve the greatest efficiency in project progress and customer satisfaction.
In keeping with agile practice apply continuous improvement to your project management processes: Change something – find out how it went – learn from it – change something again!
Summary of the Key Success Factors
- Let customers create tickets directly in JIRA: requirements, change requests, support inquiries, bugs.
- Incorporate customers’ duties and responsibilities (e.g. assignments, approvals) directly into the issues workflow as dedicated steps.
- Prepare specific filters and dashboards for the customer
- for his duties (detailing, assignments, approval)
- for overviews
- for status
- Split projects with an overwhelming amount of implementation tasks into two separate instances – one for the customer and one for development.
- Give customers a short JIRA training covering all standard actions as well as how to use and adapt dashboards and how to interpret the data and analysis reports.
- Tailor every project set-up individually and don’t try to compress it into the same template.
If you keep all this in mind, you have a good chance that JIRA will become customer’s ’sweetheart’!
There are tons of other interesting topics around JIRA. I will continue to provide you with further ideas, suggestions and mgm experiences. And of course if you have additional questions, ideas, and suggestions around JIRA I would really appreciate any comments and input from you.