You are nearing the end of your potentially shippable product demonstration and now you are faced with consuming stakeholder feedback before they leave the room.

So where do you begin?

Step 1: Soliciting Feedback

An empty whiteboard should haunt your dreams!

If you are allowing stakeholders, internal or external, to leave the room without providing feedback then you are neglecting a very important aspect to your software development cycle.

Issues are either being left unspoken or your customers are not engaged at the level they need to be for your team to succeed.

• Simply ask them.
• Avoid analysis paralysis.
• If they have scheduling conflicts send them an interactive demo link.

Tip: Be creative in soliciting feedback and do not take stakeholder avoidance lying down.

Step 2: Clarifying the Confusion

Talk about each feedback item with the entire team in the room and try to reach a level of understanding. Often people have difficulty articulating what they mean. and you want to avoid everyone nodding in lukewarm agreement with one person is thinking square, the next circle, and everyone else triangle.

• I love it!
• I hate it!
• What ever happened to _insert obscure functionality request here_

I suggest using 5 Whys to help clarify each statement while clicking through the demo:

“I love it!”
“Why do you love it?”
“Seems so much easier to read!”
“Why is it easier to read?”
“Well these fonts across this menu..”

Clarifying the feedback, regardless of whether or not you agree with their opinions, will help in turning these into actionable items.

Tip: Feedback reflects more about the person and less about your demo or product. Try to refrain from knee jerk reactions during the conversation.

Step 3: Deciding on Go / No-Go for Release

Remember that the goal is having a releasable product at the end of the iteration. It isn’t mandatory that you release, but the conclusion of the demo should provide the team with clear guidance on next steps. If you can identify a handful of small items that are blocking release, I suggest reaching consensus on these and swarming on them as a team.

You may want to schedule your demos in such a way that you have time to anticipate small changes before you release to production.

Tip: I’ve worked with Scrum teams that held a demo every week, and released every two weeks. You are not restricted to the end of your iteration for demos.

Step 4: Seeding the Backlog

Take the time to document every piece of feedback, not just the items in which you are addressing before you release to production.

Convert them into the applicable artifacts such as:

• Stories
• Defects
• Tasks

Tip: Nothing frustrates a team more than a bunch of undocumented feedback that crops up after every iteration.

Good luck and remember, negative feedback is better than no feedback!