SSW Foursquare

Rules to Better Bug Management and Product Feedback - 8 Rules

If you still need help, visit SSW Consulting Services and book in a consultant.

  1. Do you know the best way to manage product feedback?

    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.

    github discussions
    Figure: Using GitHub Discussions to gather feedback for Next.js


    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.

    uservoice trend
    Figure: Google Trends shows that "UserVoice" is declining in popularity (see trend line), while "GitHub Discussions" is slowly growing

  2. Do you know how to report bugs and give suggestions?

    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:

    report bugs and suggestions
    Figure: Making the Product Backlog the main source of tasks

    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?

    Figure: Bad example - This email isn't going to help the developer much - it is vague, has no screen capture or other details to help reproducing the error

    Figure: Good example - This email includes the product name and version, the category of the issue (BUG), a screen capture, and informs the user's system

    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

    Figure: Bad example - Lack of details

    Figure: Good example - We can easily identify more the one way to improve the UX and there's a clear suggestion to action

    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.

    Video: Good example - Recording bug reports in a video can make the issue clearer to see (1 min)

    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?

    Figure: Good example - Using a tool to record steps replicating an issue is a great and simple way to report a problem that's easy for a developer to understand and reproduce

    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.

    Video: Good example - Giving suggestion requests via video (5 min)

    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.

    For a bug email:
    To: Tech Lead
    Cc: Product Owner
    Subject: Bug - {{ SUMMARY OF BUG }}

    For a new feature email:
    To: Tech Lead
    Cc: Product Owner
    Subject: Suggestion - {{ SUMMARY OF 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, 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?

    do you know how to report bugs and give suggestions
    Figure: An intranet page with links to projects’ backlog to make it easy for everyone to find. Note some projects have more than 1 backlog.

    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

    We have a proposal to change the standard for a bug from 🐛 to ⚠️ - Vote here.

    Check out the rule on Do you know which emojis to use in Scrum?

    Tip: GitHub Issue Templates can help you with that.

  3. Do you have a clear definition of a bug?

    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.

    bug feature

    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)
      Figure: Yellow screen of death
    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)
      Figure: An incorrect sum is likely to be a bug
    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.

    2016 02 08 12 20 59
    Figure: Do I create this as a bug, or a task?

    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?

    62034c tfs preview add bug
    Figure: Adding a bug to the Product Backlog in Azure DevOps

    Note: The above is our definition. Others have different definitions that we do not subscribe to: Painless Bug Tracking.

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

  4. Efficiency - Do you know the quickest way to fix small web errors?

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

    Epecially if you find out who the culprit is, it is a good idea to notify that person including the things you have fixed, so it doesn't happen again.

  5. Do you know how to reply to free support requests that takes more than 20 minutes?

    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:

    Figure: Good Example - Ask for billable hours approval if a support request demands more than 20 minutes

  6. Do you document "TODO" tasks?

    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.


    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.

  7. Do you allow users to get up-to-date messages?

    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.

    Figure: Visual Studio 2019 has helpful notifications to indicate which parts need updating

  8. Do you know the best way to do A/B testing?

    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 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:

    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.

We open source. Powered by GitHub