Do you know the right way to report bugs and give feedback/suggestions?
  v25.0 Posted at 11/11/2020 11:50 AM by Jean Thirion

​​​​​​​When reporting bugs and giving product feedback, it is essential that you are as descriptive as possible, so that the developer can reproduce the error to find out what the problem is or understand what features you are requesting.

Try to be as efficient as possible: 

  1. If there is a GitHub backlog, add an issue and @mention relevant people
  2. If there is a Azure DevOps backlog, add a PBI and @mention relevant people
  3. If you don't know where the backlog is, or don't have access, then send an email 

Try to have one issue/PBI/email per bug​/suggestion, but if the bugs/suggestions are related or very small (e.g. they are all on the same page) then you should group them together in a single email.​

Figure: Bad Example - This email isn't going to help the developer much - it is vague and has no screen capture, and gives no alternate way for the developer to contact the user regarding the issue
Figure: Good Example - This email includes the product name and version, the category of the issue (BUG), a screen capture and contact number, and shows that the user's system is up to date
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 three critical components of: Steps to reproduce, Expected outcome, and Actual outcome, will save the both you and the developer time and frustration in the long run.

Also, make sure your descriptions are detailed and useful as that can make finding the solution quicker and easier.

Make sure you always explain and give as many details as you can of how you got an error or a bad experience.

Hi, Rebecca,

Where is SSW TV on the navigation?

- Adam  

Figure: Bad example - Lack of details

Hi, Rebecca,

  1. Navigated to ssw.com.au
  2. Scrolling down looking for a big graphic like "CHECK OUT SSW TV! CLICK HERE!"
    Me, thinking… "Hmm… let's try the menu at the top..."
  3. About Us? Nope.
  4. Services? Nope.
  5. Products and Support? Nope.
  6. Training? Nope.
  7. User Group? Nope.
  8. Rules? Nope.
    Me, thinking... "OK. Now where? Most likely, the SSW company description will list it..."
  9. Navigates to About Us.
  10. Me, scrolls down… nothing.
    Me, thinking... "OK. Weird. Let's go back."
  11. Me, goes back to homepage.
    Me, thinking… "Is there a site map?"
  12. Scrolls to bottom of page. Clicks sitemap link.
    Me, thinking... "Ctrl+F for TV? Nope."
  13. Me, gives up… types tv.ssw.com.au to try and get lucky. Huzzah!

- Adam

Figure: Good example - We can easily identify more the one way to improve the UX

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

Figure: Good example - Recording bug reports in a video can make the issue clearer to see

Figure: Good example - Giving feature requests via video

Who should you email, 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 and not too much work, then you should email the Tech Leader and CC the Product Owner.
The Product Owner can always respond if he doesn’t like the suggestion.​
For a bug email:   TO: TechLead@  CC: ProductOwner  Subject:BUG xxx   (or use PBI @mention)​
For a new feature email:  TO: TechLead@  CC: ProductOwner  Subject:SUGGESTION xxx  (or use PBI @mention)
​Note: There is no use for: sswtimepro@ssw.com.au​

When you create a bug/suggestion to a backlog, it's important to add an emoji in the title so it looks nicer.
I.e: "🐛 Bug - Calendar is not showing on iOS devices" 
"✨Feature - Add 'Back to menu' item to top navigation"

Related rules

Related rules

    Do you feel this rule needs an update?

    If you want to be notified when this rule is updated, please enter your email address: