Project management is a major factor in the efficiency and capabilities of any development team. For us it’s in ClickUp where the business objectives become requirements and translate into workable tickets. On complex projects, managing tickets can be challenging. What always helps is having clarity and a reasonable level of detail in every ticket created.
Let’s call it a “pet peeve”, it’s that gut reaction when you read something that looks like it was lazily written like “that thing over there, let’s make it better”. What? Where? When? How? The basics are sometimes missing in tickets. Why does this happen, even though most people involves in ticket reporting have some level of technical experience (given it’s 2022, and not 2008). The main cause of most bad reporting is when the person reporting is in a rush. It’s actually fine to make ticket drafts and then come back and work on the details later. After all it’s important to get something into the system about a bug that you’ve discovered, even if you’re running late for a meeting and don’t have time to articulate all the details. This should however be made clear in the ticket, for instance using a tag such as “needs-clarification” or “needs-details”.
A good starting point for precise and helpful reporting is just having the right attitude. You will often find that chronically bad reporters simply don’t have the right perspective on what a report is. They more or less view it as “I found something, so I said hey there is a problem over there, and that’s it I’m done”. The problem with this is that attitude, is that actually the person who discovers an issue, or has information about a direction (as in a new feature planned), this person is in the best position to communicate that information. If they fail to do this, there is naturally going to be inefficiency. Put more simply, as a developer if my client reports hey over there is an issue can you fix it, I now have to repeat whatever steps they took originally. Whatever analysis they did, whatever discovery they made, I have to do the same thing. And in some cases I won’t be able to do that without first getting “steps to reproduce” that are more clear. The right attitude to have when reporting issues is that your knowledge of the issue is valuable. You have information about it which is communicated thoroughly, will save development time. That means saving money and being more efficient at moving progress forward.
What can we focus on to create better issue reports?
In it’s simplest form, uploading screenshots is a way to make your issue report visual. The vast majority of tickets could be more easily understood with at least 1 screenshot. It’s also important when comparing or referring to multiple screens, to be thorough and provide screenshots for each different view. As the saying goes, a picture tells a thousand words. It’s true with many issues that it would take a very long paragraph, or multiple paragraphs to explain something that can be shown just with a screenshot attachment.
It’s important to also consider when you need to illustrate your images in order to make them effective. Sometimes a screenshot in it’s raw form is enough. You can already choose to focus on an area by using a “selection screenshot” which most screenshot tools support. This allows you to capture just the area you want the developers to focus on. This is often better than sharing a screenshot of your entire screen, although this might be fine in cases where the issue is more obviously visible.