Let me open a ticket

For the last couple of months I started collaborating in a project for a Mexican designer retail e-commerce page for United States market. It is a quite unique team because the people with the most experience are only there for questions, while the rest of the team is young.

An Instagram post from a costumer at the Mexican designer store

About a week ago we had a discussion over our Slack channel, that lasted about an hour, wether or not I should open a ticket so someone could take a look at the possibly error I was seeing.

These are the highlights I want to share with you about our conversation on opening tickets.

1. Define a process

The first fuel of the discussion is that we were not sure if we wanted a new ticket or not. And it was pretty confusing. To all of us. See, the thing is that we did not have a documented or defined process that would tell the team what to do.

Every project is different and somehow unique. However, processes are pretty much the same with some tweaks here and there to adjust to the uniqueness of the project.

Tweaking a process image to illustrate my point.

Make sure that you and all the team is familiar with the process being followed. This includes, but not limited to: which types of tickets you have and how to use each, when to open a new ticket, when to reject a new ticket, etc.

2. Make sure you add all the information

Other of the main points in the discussion was “How do I know if this is actually a bug?” As, how do we shield from this not a bug, it is a feature. It turned out that there were no much Acceptance Criteria documented for us to decide for ourselves.

It was then evident that the information a story, a bug, a task, or any form of ticket, shows how a team is really independent from its own team members and stakeholders. Think about it. The less information someone shares in a ticket it will translate into less context, more questions and more blockers the person receiving the ticket will have. The person receiving the ticket will need to reach the person who created the ticket to be able to start working on it.

Shared information should help to answer other people questions.

Personally, I think this is the most difficult mindset or habit to change. Also, the time spend trying to open a ticket should be considered, right? Well, I have been told that there is no such spend time opening a ticket, but invested time because this will be reflected in how much independence there is in the team.

Based in our conversation I created a list of things tickets should have:

1. State the problem you are seeing. Being descriptive always help and gives clues to the person that will work on the ticket on where to start looking.
2. Avoid creating hypothesis of what the cause of the problem is. When you say “the server is down” it is possible that the person looking into the problem will go in a different path far away from the real problem.
3. Describe the steps to reproduce. Share the recipe that will lead to the described problem guarantees that anyone is able to see it. Be mindful that you might be obviating a set of steps with a generic step.
4. Be as detailed as possible in Acceptance Criteria. This will help the team to define if what it is being seen is a bug or not.
5. Add a reference to the desired functionality. Link the failure to something that can be used as a reference when checking again. Usually a story with acceptance criteria or a test plan will contain this information. Adding this reference is important. This will cause that all team share a common understanding of the functionality the system should have.
6. Add environmental information. Is it happening in all instances? Are you seeing it in a specific browser? Which version do you have?

Final thoughts

After what seemed like a really long time in the dark not knowing what to do next, the team ended up making some agreements. First we decided that we needed a new bug, because the story was already delivered in the past sprint. Also, we noticed that there is a lot of detail in some of our stories, so we are trying to get as much detail in from now on.

At the end of the discussion I opened a new ticket, added a reference to a Epic Story. Currently the bug is being chased. Any time now, fixed.