Rules to Better Bug Management and Product Feedback - 8 Rules

Effectively managing product feedback is key to improving your product. While platforms like UserVoice and UserEcho have been popular, GitHub emerges as a superior choice for modern software development.

UserVoice and UserEcho

• UserVoice - Known for its voting and ticket system, it allows users to enter suggestions and administrators to track feedback
• UserEcho - Similar to UserVoice, providing a platform for user feedback and suggestions

Why GitHub is Better

• Integrated Development Workflow: GitHub integrates directly with your development workflow, making it easier to turn feedback into actionable items
• Transparency and Collaboration: GitHub's open platform fosters transparency and collaboration, allowing users to see the progress of their feedback
• Richer Interactions: Beyond simple voting, GitHub allows for richer interactions between developers and users through comments, labels, and reactions

Using GitHub for Feedback Management

• GitHub Discussions - For general feedback or discussions around feature or support requests. Facilitates community engagement and broader discussions.
• GitHub Issues - Ideal for reporting bugs or tracking work. Use labels to manage and prioritise feedback effectively.
• Project Boards - Use GitHub Project Boards to track the progress of feedback implementation, providing visibility to your team and users.

Link: github.com/vercel/next.js/discussions/categories/ideas

GitHub’s comprehensive tools provide a more integrated and transparent approach to managing product feedback, making it the recommended choice for software teams.UserVoice was as popular platform to collect, manage, and prioritize user feedback. It has a voting and tickets system out of the box.

More Information - Google Trends

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

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.

When reporting bugs and giving product feedback, it is essential that you are as descriptive as possible. This will save both you and the developer time and frustration in the long run.

Here are the 8 tips:

• 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.

See rule: Do you have a clear definition of a bug? External source: How to produce a good bug report?

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, and
• Actual outcome

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.

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. You may have a group email such as all@northwind.com.au, You would only Cc this email when a greater visibility is required.

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

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 Do you know which emojis to use in Scrum?

Tip: GitHub Issue Templates can help you with that.

The answer to this question can make or break contracts. We think that it's such a fundamental issue it has to be captured clearly. This is how we strictly define a bug.

A software issue can be classed as a bug where:

1. The application crashes to code (excluding bugs resulting from third party products, e.g. "blue screen of death" or crashing in a third party data grid that we cannot control); or
2. The application displays data inconsistent with the specified business rules; or
3. The application is missing functionality specified in the specification; or
4. The page design/layout is substantially inconsistent with the agreed mock-ups and the developers can reproduce the above on the test server and the application is not yet "live" and the issue has been reported in time (generally 30 days).

Examples of what could constitute a bug

1. The application crashes to code because it doesn't check that a connection is valid before running a stored procedure (this is likely covered because it crashes to code)

   

2. A sum total is negative instead of positive because the wrong operator (plus instead of minus) has been used to calculate the running balance (this is likely covered because data is inconsistent with the specified business rules)

   

3. The application is missing the Monthly Sales report (this is likely covered because the application is missing functionality specified in the specification)
4. The output HTML in the application is formatted way out of line and does not display in the specified browser (e.g. Internet Explorer 9) (this is likely covered because it is substantially inconsistent with the agreed mockup)

Examples of what is not a bug

1. Any problem caused by software or an application not written by the organization supplying the software.
2. The customer requirement was not included in the user interface/mock-ups/specifications.
3. The client decides that they don't like the look of the current form and wants the buttons at the bottom of the form instead of at the top, even though the form is substantially the same as shown in the specification.
4. The original specification states that the total price excludes GST, but it really should have included GST. This is a change to the specification, and is not included in the contract.

Using Work Items in Azure DevOps or GitHub

Using a Work Tracking tool allows you to create work items such as user stories, bugs, tasks, test cases etc. Only create bugs for defects, faults, flaws, or imperfections that fulfill your definition of a bug. For everything else, use other work item types.

Handling additional work for fixed-price contracts

Scrum wasn't designed for fixed price, fixed scope contracts. Any new features or modifications (non-bug items) not in the original Sprint or Sprints are classed as additional work and are outside the scope of the contract. Any tasks which are bugs should be marked as additional items and be completed in the current Sprint if possible. Most importantly, after the Sprint Plan has been sent, a PBI should NOT be entered as an item (additional or otherwise) in ANY Sprints if they are not a bug. Instead, move all non-bug items to the Product Backlog for future review after the warranty period for the fixed price contract has passed.

Handling additional work in a Scrum project

Any new features or modifications (non-bug items) not in the original Product Backlog are classed as additional PBI's and placed on the Product Backlog. Any tasks which are bugs found during the current Sprint should be fixed within the current Sprint. Any tasks which are bugs found outside of the current Sprint should be added to the Product Backlog. See Do you know when to create bugs? and Do you know the 3 steps to a PBI?

You can also use the Wiki definition of "Software Bug" as a reference to understand this concept: Wikipedia Definition of Software Bug.

Imagine this scenario... A designer notices a small typo on an intranet page. As a good employee, they open up the backlog and create a PBI to fix the spelling error. Then send a "to myself" to action.

Meanwhile they are thinking... "That took more time to report the error than it would have taken me to fix it".

Small errors should be fixed by the person who found them straight away. Text changes can be easily done in SharePoint, WordPress, or GitHub.

Bear in mind that communication is indispensable. Therefore, it's crucial to ensure that other individuals connected to that content are informed about the fixes/changes through either an @mention or a brief instant message (IM).

If you need more than 20 minutes of work to perform a task, then it's not free, and you need to get approval for it.

Follow this template to reply:

When you have an idea for content or notice some content is missing and cannot be written straight away, it is important to document it. It should be done by adding the words "TODO:" followed by what you want to be added there.

GitHub

For GitHub projects, creating an issue using "TODO" as prefix is the preferred way.

VS Code Extension

In VS Code, we recommend using the extension Todo Tree. You can find TODOs and highlight them in open files.

A new version of your software is deployed. How do you tell users important information on older versions?

You shouldn't need to check for updates to be notified of valuable information.

Software is often deployed without any mechanism to insert a message into older versions.

Messages might include notifications to update or simply helpful tips. Eg. Sometimes customers are not aware that their CRM installation is several years old.

A/B Testing is the process of testing different versions of an application on different users to gather empirical evidence to learn which version is better.

Using A/B Testing enables you to get features tested and when used effectively means that a bug will never be deployed to 100% of users. Generally, new features should be tested on 20% of users and rolled out to others once they are reliable.

Video: What is A/B Testing? | Data Science in Minutes

There are several ways this can be done...

Feature Flags (Recommended)

Feature flags are a modern way to toggle features for users. They are essentially a little bit of code that can be turned on and off at will. That means you can choose, when features are deployed and who gets them.

Feature flags are often implemented by developers writing their own code. However, there are better solutions today:

• LaunchDarkly

  • Video interview of LaunchDarkly CEO Edith Harbaugh

• Azure App Configuration is the recommended solution and there are some great tutorials that help developers get up and running in minutes:

  • Use feature filters to enable conditional feature flags
  • Tutorial: Use feature flags in an ASP.NET Core app

Azure Deployment Slots

Azure Deployment Slots are another way of doing A/B testing, you essentially deploy 2 versions of your app and then direct traffic to different versions.

Azure FrontDoor

Azure FrontDoor is an offering that lets developers direct traffic to different versions of an app.