Do you know how to report bugs and give suggestions?

When reporting bugs or providing product feedback, it’s important to include as much relevant detail as possible. Make sure it reaches the right people through the right channel - ideally the product backlog, or email if needed. A well-written report saves time and avoids frustration for both you and the developers.

✅ Use YakShaver

The best way to report bugs or share feedback is by using YakShaver.

YakShaver is a smart tool that simplifies how you report issues and give feedback. Instead of spending time writing a detailed report or figuring out who to send it to, you just record a quick video and YakShaver handles the rest.

Using AI, YakShaver analyzes what you've said and automatically routes the issue to the right person. This means you don’t have to worry about choosing the right backlog, tagging the right team member, or following up to make sure it landed in the right place. It speeds up communication, reduces misunderstandings, and allows everyone to focus on solving the real issue instead of getting bogged down by process.

Video: What is YakShaver? | Ulysses Maclaren (1 min)

---

❌ Do it manually

If you can’t use YakShaver for some reason, follow these 8 tips to do it right manually:

• Tip #1: Draft your bug with enough details
• Tip #2: Draft your suggestion with the complaint and what you expect to see
• Tip #3: Should you send this to the Product Owner or the Tech Lead?
• Tip #4: Should you email or put it in the backlog?
• Tip #5: Do you make it easy to find all the backlog in your company?
• Tip #6: Make sure when using backlog, the Product Owner will still get an email
• Tip #7: Separate PBIs
• Tip #8: Use emojis and prefixes for PBI/Issues titles, or email subjects

Tip #1: Draft your bug with enough details

Make sure you always explain and give as many details as you can of how you got an error or a bad experience. Detailed and useful descriptions can make finding the solution quicker and easier.

The goal is to include enough details so the developer can focus on the development work more rather than trying to figure out what the feature requirements or bugs are.

Things to include:

• Steps to reproduce the error
• OS and browser details
• Screenshots
  💡 Tip: Copy and paste the text for searchability
• Video for more complex bugs (more info below)

Learn more:

• Do you have a clear definition of a bug?
• How to produce a good bug report?

Functional Bug template

When possible, a great template to follow is the Functional Bug template from the ASP.NET open-source project. Spending time to provide as much detail as possible, by ensuring you have the 3 critical components:

• Steps to reproduce
• Expected outcome
• Actual outcome

Make it extra clear with videos

Better than a good textual description of a bug report is a screen recording. This should be followed for a more detailed report. Use Snagit or Camtasia to record your screen.

Recording a stepped user flow of actions that walk through through an issue is another excellent way of reporting a problem that is easily understood and reproducible. There are many tools you can use to make recording these steps easy, for example Steps Recorder which is built in to Windows, or Microsoft's Test & Feedback extension for Chrome, Edge and Firefox.

See our rules for setting up and using these tools at Do you use Problem Steps Recorder? and Do you do exploratory testing?

Tip #2: Draft your suggestion with the complaint and what you expect to see

Define all the requirements as per Do your User Stories include Acceptance Criteria?

Better than a good textual description of a suggestion request is a screen recording. This should be followed for a more detailed report. Use Snagit or Camtasia to record your screen.

Tip #3: Should you send this to the Product Owner or the Tech Lead?

It depends on the team, but often the Product Owner is busy. If you know the Tech Lead and your suggestion is obviously a good one, then you should email the Tech Leader and Cc the Product Owner. The Product Owner can always reply if they don’t like the suggestion.

If you are unclear use IM to ask, but remember the golden rule to not send tasks on Teams.

Tip #4: Should you email or put it in the backlog?

Always go for backlog if you have access to a backlog management system, otherwise email relevant people.

Tip #5: Make it easy to find backlogs within your company

It is recommended to keep track of active project backlogs on the company intranet, while also including the Product Owner and Tech Lead contact information, coupled with a link to the Teams channel of that project.

Tip #6: Make sure when using backlog, the Product Owner will still get an email

Create an Issue/PBI and @mention relevant people (GitHub and Azure DevOps will generate a nicely formatted email)

See rules on Do you know when you use @ mentions in a PBI?

Tip #7: Separate PBIs

If they are all related to one area, then you could consider putting them together. Otherwise don’t bunch them up.

See rules on Do you send tasks one email at a time?

Tip #8: Use emojis and prefixes for PBI/Issues titles, or email subjects

When you create a bug/suggestion to a backlog, it's a good idea to add emoji in the title. Not only does it look nicer, but people can look at the item and take in the necessary information quickly.

This means that anyone looking at the backlog can glean its nature at a glance, rather than having to read each item to know what category it is (5 bugs, 2 features, etc).

Examples:

• 🐛 Bug - Calendar is not showing on iOS devices
• ✨ Feature - Add 'Back to menu' item to top navigation

Check out the rule on which emojis to use in Scrum.