Implementing Jira in Small Business

[#1]

Introduction

This article will give insight on how a small software development department implemented Atlassian products to enhance and streamline the business process. The privately held company has 35 + years’ experience across a broad range of industries and organizations, with a focus in Accounts Payable & Medical Claims. The software development team was created in early 2015, mainly due to the volume of incoming projects and data exponentially outpacing our existing architecture. The company develops quality solutions, using cutting-edge technology working in a micro-service environment. I graduated with a B.B.A. in Information Technology Management and joined the team in 2016. Jira Software, Jira Service Desk and Confluence were products installed but rarely used as part of the process. After a few weeks of analyzing the existing business process, areas for improvement were uncovered.

• Software development had little documentation.
• Solutions were communicated via email. There was no formal process for technical write-ups, process documentation or status updates.
• Software deployments, issues and incidents were communicated verbally or by email.
• Procedural documentation was decentralized across the network and difficult to locate in a timely manner.

Implementation of Atlassian products improved efficiencies within the departments, the business and directly affected my role within the company.

Our Software Development Process

In the infancy stages, Jira was used to track project statuses at a high-level. After some internal restructuring, I was provided the opportunity to own the platform and configure the system to best fit our needs. With opportunity comes challenges, this was when I joined the Atlassian Community to look for answers on how to setup Jira. My first year in the Atlassian Community was mainly for posting questions I had about database and software migrations, project & board setup among many other configurations Jira has to offer. Spending many hours in Jira, with the help of the community, our team now has a standard that we follow from concept through deployment, as well as operational support through the product lifetime. Below is a high-level overview of how our process works:

1. All Jira Issues are created to a specific project and immediately start on the backlog for requirements gathering.
2. Daily stand ups and weekly grooming allows us to break down the requirements into linked, meaningful sub-tasks.
3. Weekly manager meetings allow ‘the business’ to direct which work is the highest priority and these are moved into upcoming sprints.
4. Once a sprint is started, two boards are configured for each Jira Issue. One board contains the overall story or task and the second board contains the linked sub-tasks.
5. Sub-tasks are distributed among software engineers and moved to a completed status as solutions are built. Once all sub-tasks are complete, the story is complete.
6. Jira Plug-ins allow the system to automatically generate sub-tasks for items that need to be complete on every single Jira Issue, such as technical documentation and unit/integration testing.
7. Our workflow is configured to pass Jira Issues into statuses for tracking purposes. We use a somewhat standard workflow: Backlog > To Do > In Progress > In Testing > Review/Deploy > Complete.
8. Our sprints are closed after two weeks; all incomplete issues are moved into the next sprint or backlog and reprioritized.
9. The Burndown and Sprint Reports are used to better estimate time capacity going forward. These reports are also used for much more, such as tracking and highlighting outliers than my have occurred during the sprint.

Jira has many more features to offer than other project management tools in the market and it has the capacity to be configured to meet any business needs. Jira has directly contributed to molding our procedures and creating a standard for the business as a whole.

Maintaining the Software

In the past, software requests and incidents were tracked via email communications. We found ourselves scrolling through emails to find a specific stakeholder request or replying to a reported incident. Using Jira Service Desk, we now have a more streamlined approach to handling requests.

• Requests or Incidents are initially opened via Service Desk Portal. The option for users to send emails to Jira Services Desk is used often. The ability for an email request to convert into a Jira Service Desk Ticket fit our needs.
• Users are managed in Active Directory and grouped in Jira Service Desk. Each group receives status updates each time their service desk ticket is updated.
• The ability to group users together by department provides departments with insight to which tickets are open, in progress or resolved. This allows departments to become more collaborative while opening tickets.
• The ability to link a service desk ticket to another issue on our backlog has helped tremendously. Linking issues between service desk and our development team backlog allows requests to be prioritized into a sprint.

Jira Service Desk has allowed us to easily audit and track all requests confidently. This has also significantly improved our process for handling software related issues in a timely manner, while the end users are consistently updated by the system.

Documentation the Software

One of my first tasks was to migrate all procedural documentation from multiple storage devices to a centralized location. Over the course of six months, we worked with the Atlassian Community to setup spaces and knowledge bases to structure a public facing knowledge base in a way that made sense with our current system. We migrated 6,000+ attachments into three different spaces, which contain over 10,000 pages. Confluence directly influenced the way we document our processes and procedures. Employees are currently using Confluence daily to create new or update existing documentation. Confluence has also helped us create a standard for documentation and allow us to share knowledge company wide.

Conclusion

Currently our priority is to migrate from labor-intensive, manual processes to fully automated pipelines using cutting-edge technology. The Atlassian Products & Community continue to help us build efficient processes that people understand. All work is scoped, prioritized and vetted prior to being pulled into sprints. Sub-tasks are generated to ensure technical and process documentation, and workflows are completed prior to closing cards. We have the ability track all past, current and future development easily. I cannot thank the Atlassian Community enough for the quick and detailed responses that helped our process become more user-friendly. I plan to stay active in the Atlassian Community, providing users detailed answers that support their questions, and help improve their process.

[Johan Soetens _Dumblefy_]

Thank you for sharing your experience.

I wonder why you use two boards. Is using a Quick Filter to show/hide sub-tasks an option?

[Thomas B]

Hello @Johan Soetens _Dumblefy_ - thanks for reading! The main reason for separating into two boards was for the 'developers' sub-tasks to be worked within one board, while the 'business' stories are completed in the other. We felt like two boards made things less cluttered because we often have 20-30 sub-tasks per story. Using Quick Filter's to show/hide sub-tasks is definitely an option and would actually work the same way!