How Writing Effective Jira Tickets Can Streamline Web Development

At Bear Group we recognize that clarity is key to all forms of communication and it is especially critical when outlining the technical tasks involved in a website development project, lest a requirement gets overlooked or misinterpreted. Therefore, our Project Managers (PMs) take great care with writing out clear, concise, and actionable tickets. 

There are several strategies and approaches that our PMs utilize to write the most effective tickets possible.

The right tool: Jira

Since PMs act as the primary conduit between our clients and our developers, it’s vital that the right tool is in place to relay and store all build-specific information. We use Jira, the Atlassian agile project and issue tracking tool, for all task creation, monitoring, reference, and management. 

Jira is intuitive and flexible, allowing our clients to have a bird’s-eye view of project status and health. We primarily use Jira’s Scrum board to build out focused, logical sprints with client-specific permissions and custom workflows.

A look at the ticketing process.

The right prioritization

Before writing tickets, our PMs work with the development team to outline the sprints to make sure any dependencies are being prioritized and that sprints are built with sensible, thematic groupings in mind. 

For instance, if a theming task is dependent on custom development, we will prioritize the latter. Or, if we plan to theme out a specific template, we aim to group all dependent and related tasks in one sprint rather than handling them piecemeal. This approach also aids in the quality assurance (QA) process so our QA Manager and clients can review templates and/or features holistically.

Getting Started with Agile Project Management?

Learn how to use an agile approach to website development projects. Download Bear Group's whitepaper on the agile approach to set your project up for success.

Access the Whitepaper

 

The right level of detail

The ultimate goal when writing Jira tickets is to include the right level of detail without overloading the ticket with excess information.
 
The top reasons why it's important to write thoughtful, carefully constructed tickets are to:

  • Minimize the time it takes to fully understand the requirements.
  • Give enough information to the assignee to effectively tackle the issue.
  • Not overwhelm the assignee with too much, non-essential information. Large amounts of excess text will bury the technical specifics developers look for, making key details harder to find and/or comprehend.
  • Know when a ticket should be broken up into subtasks (e.g. if there are too many requirements to track and fulfill in one ticket).
  • Prevent confusion about the requirements that can easily be misinterpreted.
  • Allow for all stakeholders (clients, designers, QA) to easily understand the issue and efficiently review it. 
  • Use for future reference. Sometimes related or similar issues crop up on other projects; if a ticket is written with clear, precise language it is easier for PMs to trace and relay previously implemented solutions/resolutions that can be advantageous to the project timeline and budget.

The right process

Once a ticket is in QA, our PMs will monitor the ticket to make sure that all requirements have been met unless the developer has recommended that certain requirement(s) be re-ticketed for the sake of efficiency. 

From there, our PMs will guide the QA phase to ensure ticket feedback is “sliced” into cross-linked polish, improvement, or new feature tickets. This is an important step to ensure feedback doesn’t get buried in comments and that clients can prioritize and track any non-critical feedback separate from the overarching ticket.

This diagram outlines our suggested workflow for QA:

A look at the QA workflow.

In conclusion

Communicating what our clients need in an effective, organized way is vital to the progression and quality of our development. Our PMs are fastidious about writing tickets as clearly and effectively as possible with the ultimate goal of making sure developers, QA, and clients have a shared understanding and set of expectations.