Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Recording and Responding to Product Feedback

Deleted user Nov 27, 2018

Hi my name is Trevor,

I am a Software Engineer and I am looking for advice on how best to track, respond to, discuss, and defer feedback on our product in a way that makes it easy for users to provide their feedback, have the correct people see that feedback, and be able to address / resolve / defer the feedback in some way and let the person who left it know what happened.

The Background

Currently we have a process we call "Shared Ownership" which (long story short) is all of the developers and product stakeholders giving feedback on each feature during a sprint. This feedback is generally non-critical, critical feedback like the feature erroring, gets a sub-task created in JIRA directly. The feedback left as part of this process is more soft "The screen looks cramped with long names..." is an example of feedback someone might leave.

Since we can't (don't want to) have the whole company in the design meetings a lot of this feedback is around design, but likewise we also leave feedback about technical things "The PUT API request requires an Id in the body but that's inconsistent with other endpoints" is another piece of feedback we might see.

Really the process a way for everyone to "buy into" and provide the first round of feedback on a completed feature, before it is shipped. We can't have every developer in every meeting and on every code review so this is our way to get everyone a voice on our features. We don't ship a feature until we have gone through this process and have responded to all of the feedback.

The Question

My question for the community is, how can we streamline this feeback process. Right now we have a page in confluence per sprint, and we add each feedback item to a table. Each row of the table has a link to the jira issue, a short description, a long description with additional details and screenshots if necessary, and a space for developers / designers / product to respond to the feedback.

The problem we are running into is, people who leave feedback aren't always confident that their feedback has been taken, and sometimes specific feedback items require a response from a specific group (like a designer), who isn't always aware that they need to weigh in on something. It's also tough to see what feedback still needs to be responded to in order to close a story since its all in one big list.

We've come up with a number of ideas to change this internally, but none of us are strong power confluence users so we wanted to ask the community if there is a good way to leverage some features of confluence / jira to make this happen that we aren't aware of.



Log in or Sign up to comment
AUG Leaders

Atlassian Community Events