Table of Contents

• “Can you please fill that?”
• How it’s wasting your time
• Why should I care?
• The good news - there are patterns
  • Descriptive problems
  • Estimation problems
  • Severity problems
• Doing things differently
• So I started building it - meet “Bliss”

“Can you please fill that?”

Remember how many conversations or meetings you’ve had where people try to fill in missing details for new or existing issues? Often, you hear questions like:

• “What does this title mean?”
• “How long do you think it’s going to take?”
• “Which client does this issue belong to?”
• “How urgent is it? The severity is not set.”

When new issues are introduced to the team or existing ones are being reviewed for missing details, companies often try to fill those gaps in three main ways:

1. The “Ping-pong method” - Assigning the issue to someone else, asking them in the comments to fill in the missing details, and then waiting for it to return back.

2. The “Let’s suffer together” grooming method - Setting up a predefined, fixed meeting every week for the entire team to refine issues. This often results in a wasteful and redundant workflow for all stakeholders as they try to fill gaps.

3. The “Search & destroy” method - A team leader or project manager goes through all relevant issues once a day or week with multiple queries. They read and verify each one, tagging and commenting as needed.

How it’s wasting your time

For solution #1 (comment and wait) - When you assign an issue to someone else, you usually also mark the task as “blocked” or add a general tag of “needs_info.” However, this approach does not provide a clear way to know what’s missing without opening every issue, which can be very time-consuming. Additionally, don’t you also want to know why most issues are blocked? Is it because the title is confusing? Are they missing a design? Or maybe external systems are opening them without the required client info? When everything is tagged the same way as “invalid,” it’s difficult to see the bigger picture.

For solution #2 (grooming meetings), see this chart:

# People / meeting	Weekly sessions	Meetings duration (hours)	Time wasted / month	Time wasted / year
5	1	1h	0.8 days (20h)	10 days
5	1	2h	1.6 days (40h)	20 days
8	1	1h	1.3 days (32h)	16 days
8	1	2h	2.6 days (64h)	32 days
10	1	1h	1.6 day (40h )	20 days
10	1	2h	3.3 days (80h)	40 days

This means that for every group of 5 people spending 1 hour per week, the company wastes almost an entire day per month - just for filling in missing data. And it’s not like those meetings are even effective—when two or more members are filling in details, the rest usually just doze off, as they lack the context of what the two people involved are talking about.

For solution #3 (search & destroy) - Usually, it’s difficult to know what a person meant in every issue. Additionally, going through all those issues every day or week takes a lot of time and energy, and most of the time, it’s just solution #1 with a mediator.

Why should I care?

More than the time wasted, there is one more thing we miss, and that is what the company is not doing. Think of all the issues that must be taken care of (especially when it comes to SLA) which can easily be forgotten. When it’s difficult to plan, execute, and measure, it’s also difficult to reach goals. The more messy issues you have, the more difficult it is to understand where you are. Having a messy virtual working environment also affects motivation and productivity, impacts company culture, and hurts internal and external communication.

The good news - there are patterns

As a freelancer helping startup companies to plan and build products over the years, I’ve found myself sorting and organizing a lot of issue boards with many different task managers. Each of them helps you create new issues easily, but most of them lack the ability to verify them. Although you can set some kind of basic verification (e.g., required fields), the “invalidness” of the issues is more complex than that.

Usually, you see the following kinds of problems in issues:

Descriptive problems

• Affecting: execution
• Examples: the title is too short, there is no sufficient description in it’s body, issue is not tagged with enough data to start working on (for example - which environment or customer the issue belongs too).

You can often mark those problems as “required” or even add several validations in some of the tools. However, people can still forget to fill them out and just “write something down” to move on, later forgetting what they meant when they first wrote it.

Estimation problems

• affecting: planning
• Examples: missing story points or estimation in hours, days or any other scale you use.

If issues are not estimated ahead of time, there is no way to plan the next sprint, version, or even roadmap. While this may not be problematic most of the time when the issue is resting in the backlog, when it’s time to start working on it, the team needs to know how much effort it should take. This is necessary to plan how and when things will start (and are supposed to end). Think of an issue becoming a bottleneck for the rest because it’s in progress for too long, clogging the pipeline for the rest.

Severity problems

• Affecting: planning, execution and operations
• Examples: missing severity, priority, missing customer or client data (a crash in production in an important client is much more important than typo currently only in development)

When the severity is wrong, people end up either working too much on the wrong things or not at all on what’s important. Think of a customer bug that’s forgotten because its issue got lost among others and pops up when you least expect it.

Doing things differently

I needed an effective way to find and track invalid issues before it was too late. I didn’t want to keep sorting backlogs with messy issues again and again just to find the same things.

For example, I always knew that if an issue had less than 4 words in its title or body, it would be impossible to understand what it meant. I knew that most companies required all their sprint issues to be estimated and have an assignee, along with other rules that vary from company to company, but are repeatable. I kept collective those sets of “rules”, knowing I can always use one or another when needed.

This led me to think of a new solution with the following properties:

1. It will be a Slack bot - as it’s the main gathering place for teams for collaborative sharing.
2. With predefined rules - you just need to turn on and that’s it. Rules like the “title is too short” rule and more. No need to think of new workflows yourself (although you can). Just turn them on and let the bot do the scanning for you and report the results.
3. It can also solve issues - The simple one is to just close the issue, but it can do much more, such as assigning users, adding tags to issues (#invalid), filling in missing details (either manually with the user or by using default values or even AI), and more.
4. No DevOps will be required - Although there are some great open-source solutions to find invalid issues, I wanted a solution that would not require writing any code or managing DevOps. This is because I believe it can be used in many domains such as product management, project management, business development support, and more.
5. Integrates with common task managers - Whether it’s JIRA, GitHub, GitLab, or more, you define rules once and use them everywhere you need, creating a shared culture in your company.

So I started building it - meet “Bliss”

Although still work-in-progress, I’ve created a new slack bot called “Bliss - the issue manager”. Here’s a quick glimpse how scanning summary and new alerts for problems will look like:

That’s all for now, Feel free to contact me via linkedin if you want to know more once the bot is ready to try.