A while back I went over how to add change requests to Team Foundation Server (TFS) while working in an agile environment. The reason was that even though agile doesn't really use a concept of "change request" (that's a waterfall term), there still needs to be a way to track requests that weren't a part of the original requirements, especially if your project is deadline driven.

There's another way to do this that doesn't involve adding another work item type in TFS (now Azure DevOps) for the agile template. You can use the issues log.

First let's talk about GitHub. Every GitHub project has a section for "issues" that can be bugs, questions, ideas, requests for changes, etc. GitHub doesn't distinguish these things, instead allowing the team members to tag or categorize items with labels. In this sense "issues" represent a holistic backlog of "things" while the labeling process is how items are going through triage and getting categorized.

Triage is an important concept. Work item completion (whether features, user stories, or bugs) can be used to calculate lead time for requests, but you don't want to calculate that lead time until the bug is verified or the request has been approved. In addition, for agile development (our team uses a lean software development approach), there is a hierarchical nature to work items, and TFS (our project management tool of choice) sticks to this hierarchical way of doing things. Tasks fit under bugs or user stories, while bugs and user stories go under features, and features exist in epics. If you give the customer the ability to add items into TFS, how can you be sure they put them in the right place? How can you be sure the bug is valid? Furthermore, how can you be sure the item is written correctly?

For user stories, work items are written with a: As a [ROLE], I need [TASK], in order to [REASON] syntax, while features are written with a: _[FEATURE] = [ACTION] + [OBJECT] syntax.

If a customer enters a bug instead of a user story, or doesn't follow the user story syntax, or puts in a user story instead of a feature… well, things can get messy, and backlog items have to be deleted, changed, etc.

Why give the customer access at all? Shouldn't the product owner be entering the items, or some combination of product owner and scrum master?

Sure, if that's how your shop operates. But if you're not doing strict scrum, there's a lot of leeway. In lean software development with a Kanban approach, the sprint (or iteration) can change during its execution, especially from user feedback and re-prioritization of items. Also, in some shops, the "product owner" could be a member of the customer team, or the product owner role could be part-time.

Even if you have a traditional product owner, what you don't want is to be inundated with emails for changes, where the only communication is in the email--better to use the project management tool to capture these reports and requests, and continue the conversation there, especially on a team like mine where our group could be interacting across other groups.

This is where the "issues" work item in TFS comes in handy. This work item does not appear on the backlog proper (which is exclusive to epics, features, user stories, bugs, and tasks), so you'll operate almost exclusively in the "queries" section of TFS. Here, it doesn't matter how the issue is entered or whether or not it's a bug or a user stories. And it doesn't matter whether the customer enters it directly, or you copy the request from an email. The work item sits there as an issue, where you can keep it in a triage state.

Here's how we handle this on my team:

When a bug is reported or a request comes in, it ends up as an "issue" in the backlog with a priority of 4. We use a priority of 4 to signify that it has not yet been approved. The issue is assigned to me to breakdown. If the issue is a bug or usability issue, I reassign it to our usability analyst to verify before approving. If the item is reported from a user or customer that is not our core representative of the project, I leave it at a 4 until I can verify that it's approved to work on.

All communication is kept inside of the TFS issue item for tracking.

Once an issues has been verified and approved, I change the priority. I then look at the issue, and determine if it should be a bug, a user story, or a feature (or multiple items). I then create a "related" work item in TFS. If that related item is a bug (or multiple bugs), I make sure it has a parent feature, so we can keep things hierarchical. The same is true for if the issue is a user story (or multiple user stories). If the issue is a larger request, the related item might be a feature that I then have to break down into multiple user stories.

By the way, this also allows me to control the language of the work items that my team sees, such as the feature and user story syntax mentioned above.

Now that the issues have been broken down, they are appropriately assigned, story points are guessed at, and they are scheduled based on the priority. The issue remains active until all related items are closed.

With the above process, a report can be run just on the issues, which represents the external requests. More in-depth reporting can include the related items. In addition, lead time can be calculated from the point of issue approval (or creation of related items) to the closing out of the issue and release into production.

By utilizing issues for triaging work items, you can keep your board cleaner, and centered on the development team, while having an exclusive area for customer or user reported issues that reflect the user's own language, and you're able to provide traceability from the issue being reported all the way through development, completion, build process, and ultimately production deployment.