Google says this about the development process: Definition: A software development process is a way to improve design and product management by breaking software development work into smaller steps or sub-processes that can be done in parallel or in-order.

To be honest, I feel like Google is more of a profit than a search engine.

There may be broad facets of the development process I could focus on, including conventions like the agile process or waterfall. Instead, I think a topic that is interesting to me is how developers and engineers may interpret a specific part of this process as subjective when in reality it should be more objective, which are tickets. Let's talk about why tickets, what tickets, when tickets and how this fundamental part of the development process can create an extremely efficient or slow working environment. I will also link a few extremely good resources that have already talked about what I'm going to talk about in-depth and are probably more eloquent.

Atlassian does an impeccable job covering tickets in their developer guide, which you should [read] –

Specifically, I would like to regurgitate the section on why it’s important to use tickets in order to set up a baseline idea of the standard ticket. Atlassian says,
“We believe that using tickets to track work provides value by:

-Clearly defining expectations

-Measuring velocity

-Coordinating work

-Historical reference”

Atlassian has a substantially comprehensive understanding of WHY we use tickets as a part of the development process, however, one thing I would like to mention is HOW we should use tickets which I think deserves a place in the definition.

Mark Dappollone says it well in his blog, “involving developers in technical planning will reduce the scope of that development by eliminating the interpretability of user stories… the work is better defined, which allows you to do it faster, and the resulting product is better.” While Mark may not be explicitly talking about tickets I believe having developers writing tickets, and writing them well, does increase production. This is part of the reason we use tickets. We use them to enhance the development process. There may be a way to translate this sentiment into a two or three-word phrase and stick it on the Atlassian docs, but I wasn’t able to be so concise.

Now that we have defined a general understanding of what tickets should do. Another important thing to bring up, one that has many sources and is debated, even then, some engineers and developers see it more as guidelines, is the actual structure of the tickets. The many resources and templates for writing tickets are perhaps overwhelming and contribute to the decline of the ticket quality. This may be due to the ticket not having standardized anatomy, which it should, at least on every team. And there are as I mentioned an extraordinary amount of resources for writing good tickets. I think the important thing is to have a project manager or someone decide on the ideal ticket. I really enjoyed reading Daniel Starling’s blog on the Anatomy of a Good Ticket, it does a great job laying out the points within an ideal ticket. I really enjoyed the actual anatomy of a ticket and the distractions section. However, everything he mentions is gold from the timebox to the ticket process which illuminates parts of the ticket process that may not be talked about at length. Regardless the extremely condensed version is a ticket should include

• Business Requirement - A user story or explanation of risk being mitigated that the ticket deals with.

• Questions (optional)- If a ticket is moved to the Pending Questions status, then questions are always recorded here in the ticket description for a stakeholder to read and respond to.

• Acceptance Criteria- Once a Business Requirement is set, we need a bulleted list of items that we can check off to know that the requirement is met.

• Notes- Miscellaneous details that may provide additional context to a ticket.

Another option would be to find an ideal template and use that, but a template that enhances the process, not one that makes the tickets lazy and ambiguous.

So as an example let’s look at two tickets I have worked on and compare them to see which one is more concise and has a better structure that encourages efficient development and production.

In this first ticket we see at the top "related issues", this follows a good sense of historical reference immediately letting us know which project and or text spec this falls under as well as giving us a dependent on bullet which helps us follow a thread of blocking.

In the description section, we have very explicit instructions of creating a form. Not just creating the form but what will be included in the form and how it will be labeled. Immediately saving any time constraints for having to come up with naming conventions. Next in the description something else that jumps out that saves a developer time is including specs regarding certain details. What I mean by that is we have a bio, but also included in the ticket is what data type it should be as well as limitations on characters. Again, just something in the ticket that could save the QA time. There's also the inclusion of what to do after submission, we need to redirect to the next page, I'm sure in a meeting this might be covered and explicitly talked about, but having it in the ticket reduces the window for errors.

As for the acceptance criteria, there are bullets that are explicit, boolean, and also touch on testing.

This isn't even the perfect ticket in my mind. There are a lot of things that could be done differently. However, for the purposes of this comparison, this is a good ticket for the reasons listed above especially when compared with the following:

I'm not a big fan of this ticket, It looks unfinished and lacking in the same detail as the previous ticket we looked at. First, I want to mention the most bottom portion which is the child issues. This should give us a historical reference. However, when we go to the testing issue. It is a blank ticket.

Now for the description, this first sentence having an expectation of a login screen gives us no information. What is the screen? Is it a new page? Is it a modal? The second part of the sentence includes another acceptance criteria, they want to be able to log in and use the application. But what does that mean? The previous ticket had very explicit instructions that after the form is completed we are sent to another page. What does use the application mean? Is logging in not using it? What is use in this context? Why include this and not any acceptance criteria for the point?

What is in the acceptance criteria? Number one says use the model decision. Now it is not very intuitive to understand that this first point means use the decision we've made previously in meetings, which is, write a login utilizing a modal instead of a new page. And also why wouldn't it just say create a modal for our login inputs. That would make more sense and be more explicit. It's just very vague and requires information that isn't a part of this ticket.

The second point is “including a placeholder for inputs username and password”. This is the first informative bullet on what are we including in our login model. Apparently, we have two inputs, a username and a password. That should have been its own bullet. Is this going to be the only inputs we have on this login modal? So far these are bad acceptance criteria because they are vague. They are dripping bits of information non-consecutively. And it's requiring the developer to do more work on his end by guessing what should be included.

The last bullet style and design of the component using the aforementioned decision as a reference, but it does not actually include a link to the decision. It does not include any information about where to find the styling, It just says do it find it get to work.

This is not a very good ticket, I have many problems with this ticket listed above, not including the formatting itself. And to be honest this ticket is why I made this post. We need to be better for our developers. We not only need to include developers in this process but have someone who oversees writing tickets and perhaps has some sort of template.

A good ticket reduces time and energy in the development process. Hopefully, with the links I provided and the comparisons I gave, you can do some research for your own team and find the best tickets or templates that will make an impact. I think it's worth it. I think it's essential and I think it can save a lot of headaches. Maybe we all just need to have a stand up, every developer and engineer, get together on one big Google meets or zoom or discord chat, really hammer out a nice template that we all can. I'm talking to everybody, all of you, let's just do it. Let's get together instead of trying to asynchronously figure this out.

Until we set up that meeting, thanks for reading.
Have a good day and be well.