Compartilhar via

VS/TFS 2012 Tidbits: When to Use the Feedback Client

  • Artigo

As the Visual Studio family of products (Visual Studio, TFS, Test Professional) nears its 2012 release, I thought I’d bring some short hits – tidbits, if you will – to my blog. Some of these are pretty obvious (well-documented, or much-discussed), but some may be less obvious than you’d think. Either way, it’s always good to make sure the word is getting out there. Hope you enjoy!

When to Use the Feedback Client

FeedbackOne of the “new” new features of TFS 2012 is the addition of the Microsoft Feedback Client for collecting feedback from stakeholders, end users, etc.  This tool integrates with TFS to provide a mechanism to engage those stakeholders and more seamlessly include their insights in the lifecycle.

Several of my customers however, perhaps with brains overloaded with the possibilities of this capability, have asked me, “So when exactly do I use this? When do I request feedback?”

Well, the answer, as it often times is, is “it depends.”

First, if you aren’t aware of the two ways to use the Microsoft Feedback Client, check out (shameless plug) my previous post covering this.

The more I play around with this tool and talk about it with customers, the more scenarios I find in which this new 2012 capability adds value.

Now back to that “it depends” answer.. The key thing to remember for using the feedback capability is that there is no hard and fast rule for when you should use it.  But here are three main scenarios:

  • Voluntary, Unsolicited Feedback – When a stakeholder/end user has something to say, let them say it with the Feedback Client.  Instead of an email, entry on a spreadsheet or SharePoint list, using the Feedback Client leverages the goodness of Team Foundation Server (not to mention proximity to the actual development team) to log, manage, relate, and report on the stakeholder’s insights. If a business analyst or project manager likes the feedback provided, it’s just a few clicks to get a backlog item created from the feedback and shoved onto the backlog.  The feedback then becomes a supporting item for the PBI, helping address any questions as to why the PBI was added to the backlog.
  • User Acceptance Testing (UAT) – When a new feature has been developed and made available for UAT, request feedback from one or more knowledgeable stakeholders to get sign-off.  Linking the feedback request to the PBI/task/bug being tested for acceptance not only gives additional traceability in validating sign-off; but it provides the team additional “clout” if a stakeholder later voices a concern about a feature completion (“You said you liked it, see?”).
  • Checkpoints/Continuous Feedback – Feedback doesn’t have to be just at the beginning and end of a sprint. Any time there’s something new that QA’s already had a run at, why not involve a stakeholder? While you can, you don’t have to wait until a sprint’s over to get feedback.

 From MSDN, “Planning and Tracking Projects”:Planning and Tracking Projects

What other scenarios can you think of where you could leverage the new feedback capabilities in VS 2012?

Comments

  • Anonymous
    August 10, 2012
    Nice post, thanks