In this post, I’m going to take a closer look at how the new Feedback capabilities in TFS 2012 works under the covers.
In general, TFS users can request “feedback” from stakeholders about particular elements/areas of an application. This can be either specific or general scenarios. TFS manages the feedback process using work items and email notifications. But how does this work, really? Let’s find out!
You initiate a feedback request from your project (or team) dashboard by clicking on “Request Feedback”
In this example, I’m soliciting feedback for Bing searches. And I’ve asked for two items of feedback (called “feedback items”, see Step 3 in the screenshot).
So what happens when I actually click send?
Well, as far as the stakeholder is concerned, they just get an email with some simple instructions to get started:
But on the TFS side, TFS creates two work items (of type Feedback Request), one for each feedback item specified in the previous request (see #142 and #143):
Let’s look at #142 (Search for ‘Steve Lange’) and see what’s stored.
The Title field obviously houses the name of the feedback item. On the Details tab, the Description field holds the specific instructions that correspond with the feedback item.
On the Application tab you’ll find the details from step 2 on the request form (“Tell the Stakeholders How to Access the Application”).
And lastly, you’ll notice that the feedback items (Feedback Request work items) are linked together to form the more composite request.
So how can we see to whom this request was sent? Look in the comments of the history for the work item (at the bottom of the screenshot):
The benefit of this approach is that it allows feedback items to be tracked individually. If you submit a feedback request, but ask stakeholders to check out features that align with different backlog items/requirements/whatever, this method provides more specific tracking.
Reuse or Making Corrections
Another less obvious, but equally nice benefit to managing feedback requests this way is that you can make changes to the request without creating an entire new one. This is possible because the link that’s inserted in the email sent to the stakeholders references the work item ID’s of the feedback request items, rather than embedding all the instructions in the URL (or statically somewhere else).
So if I make a mistake I don’t have to create a brand new request, but instead the Title, Description, and other applicable fields on the Application tab and have the stakeholder simply reuse the previously-sent link.
In this example, the URL provided in the email looks like this (see bolded area):
By updating either of the work items specified in the URL, the feedback session will subsequently be updated.
More on the feedback URL
You can modify the URL and send it directly to someone without filling out the feedback request form. For instance, if I requested feedback of work items 142 and 143 from certain people but also wanted feedback on work item 143 from an additional person I can augment the URL and send it to that one-off person. In this example it would look like:
Here’s the basic breakdown of the URL:
|<TFS_URL>||The URL of your TFS instance|
|<Project_Name>||The name of your Team Project|
|work_item_ids||Comma-separated list (or use %2C) of work item ID’s. These work item ID’s need to correspond to Feedback Request work items or the Feedback Client will throw an error.|
So let’s say I walk through the process of providing feedback using the Microsoft Feedback Client. For summary, here’s the feedback I provide:
Once I submit my feedback through the Feedback Client, a work item (of type Feedback Response) is created for each individual reply. (See #144 and #145 below)
Again, this allows teams to track individual responses to discrete items. So if a stakeholder skips feedback for a particular item, it doesn’t interfere with feedback on other items.
Revisiting and Providing More Feedback
Here’s one last great feature. As the stakeholder, let’s say I want to either review or amend feedback I’ve already provided, or submit additional feedback. I’m covered! If I simply click on the link provided in the original feedback request email, upon entering the “Provide” step of my feedback session TFS is smart enough to see that I’ve already provided feedback. In doing so, it inserts the feedback details I provided earlier into the Feedback Client. So now I can make changes to existing feedback, or enter more information.
For example, here’s the Feedback Response work item created from my first submitted feedback:
If I click on the URL in the original email sent to the stakeholder, the Feedback Client runs again, and I can instantly see the feedback I’d previously supplied:
Really all it’s doing is looking at the Feedback Request work item, checking to see if there is a Feedback Response item submitted by me already. If there is, it pulls the content of the Stakeholder Comments field and sends it over to the Feedback Client for the stakeholder to make further edits. Sweet!
The basic thing to remember here is that the Feedback Management process in TFS uses TFS work items to manage the storage and workflow of providing feedback. Think of the Feedback Client as a very lightweight TFS client. Changes you make in the Feedback Client either create or update Feedback Response work items in TFS. Direct changes made in TFS to the work items are reflected in the Feedback Client when those work items are accessed.
I hope this helps better explain how feedback actually works in TFS 2012. It’s terrific and easy way to engage stakeholders to get feedback at various points in the development lifecycle. But it’s a flexible implementation as well, providing mechanisms for reuse and more granular tracking.