Agile Project Management with TFS

Recently, at work, we've been trying to formalize a project management process that makes sense. After much experimentation throughout a handful of projects, we've been able to hammer down a process that works well for us. This post is intended to lay out that process for agile project management using Microsoft’s Team Foundation Server (TFS) in such a way that makes sense for the organizational structure, resources, and processes. In particular, it outlines a way to move from business analysis to project structure breakdown to user acceptance testing and bug reporting.

Software Development Lifecycle

Any software development project goes through a lifecycle. This lifecycle includes business analysis, information architecture, database design, software programming, user documentation, testing, continuous integration and deployment, and support and maintenance. In an agile lifecycle, work is often iterated over and refined on a regular basis in order to quickly tackle the unknown requirements that might emerge during development.

The application lifecycle flows from responsibility to responsibility, but these can be broken down into application phases. In Kanban terminology, these phases can be represented as swim lanes.

From the above diagram, you can see that the implementation and deployment and review phases are the ones that are commonly iterated over during an agile iteration or "sprint." Storyboarding can sometimes be accomplished at once in the beginning of the project—with some modifications throughout the lifecycle—or it can join the beginning of the implementation phase if storyboarding represents the kickoff process of a new feature set.

Business Analysis

TFS offers tools for running successful software projects, but certain things need to be accomplished before requirements can be loaded into TFS for work to begin.

Gemba-ish Walk

Gemba walks in Lean terminology are when the business analyst is physically present to view the process being examined. At the very least, a meeting should be held with the primary user(s) of the system to either view or discuss the process/work/system(s) being utilized. All of this should be detailed into a business document that identifies the project and the stakeholders. This business document should be more than just a bulleted list of actions or an Excel spreadsheet. Ideally, the document should attempt to take on a narrative format so that context is not lost in translation. Often bulleted items are broken down into the essence of the request, which could eliminate useful context that offers the "why" of something that is being requested, or something that is being done.

Technical and Architectural Considerations

In the process of requirements gathering, if a technical resource is present, there is an opportunity to brainstorm about technical considerations when it comes to application work. Additionally, systems architecture might need to be documented if the structure of the server, network, or database could have an impact on the completion of the project. This is a part of the edict to acquire 100% of the known requirements before the start of a project.

In order for a project to start and proceed successfully, you should have 100% of the known requirements.

Documentation Revision

Business documents aren't finalized on the first attempt. The document itself should be iterated over by the business analysts, project managers, technical team, and stakeholders. Once finalized, it should be signed off on by the project sponsor. This is an agreement of the basic requirements, and ultimately it becomes a living document that is updated as requirements change (or new ones are discovered). It can be used as a guidepost to refer back to in the event that something within TFS is unclear. Bear in mind that although we have spoken explicitly of a single business document, it is highly possible that there will be multiple business documents per system being analyzed, and that these documents will align with the project epics (discussed later).

Team Projects

TFS allows for the creation of projects and collections (a grouping of projects). Advanced users can query across projects to get an item listing at the collection level, but most will work inside of a single collection on one or more projects. At the highest level, a project is a major initiative that could take several years to complete, and will have several subprojects, systems, or milestones underneath them.

Team Areas and Epics

TFS follows a hierarchical structure inside of a project. On the "work" tab, you have the traditional agile categorizations of epics, features, and user stories: Epics contain features, while features contain user stories, etc.

TFS does offer a second level of classification to manage projects teams called Team Areas. With a Team Area, you are basically creating a sub-project that is visible at the higher Team Project level, but allows you to attach epics, features, user stories, etc. to an segmented area in order to concentrate work items and Kanban cards to a specific sub-project.

For example, if your Team Project is called VMed, which represents an entire software suite, you might have a Team Area that focuses specifically on an online testing application. In many instances, the Team Area will represent a product or application within a Team Project.

Epics represent the top level of agile classification for work items. Oftentimes these are described as very large user stories that encompass several iterations worth of work. If Team Areas are ways to reduce a project into the project/application that is being worked on, epics can be seen as ways to classify the systems that an application addresses. For example, an application called iCan might have a Team Area called iCan within the VMed project, but there could be an epic for entrustable professional activities (one system the application addresses), and another for clinical skills (another system the application addresses). These epics are collections of related features within an application.

Features and User Stories

Features come from the business document, and are broken down under epics. Oftentimes, the business document for the epic/system will detail the system in such a way that chunks of text can be pulled out and entered into TFS as feature items. Features are broad descriptions of related functionality that needs to be created within an application in order to meet the requirements. Features are most often collaboratively entered into TFS (under the appropriate epic(s)) by the business analyst (who was primarily responsible for requirements gathering) and the project manager (who will be overseeing the day-to-day development).

User stories, meanwhile, are specific, actionable items broken out of features. These should take the form of a user request. For example: As a user, I would like the potential and selected candidate listings to default to ordering by last name to make it easier to search. The standard user story takes some form of:

As a user, I need X in order to do Y.

The purpose of the user story is to create a concise statement that identifies the role of the user, the goal of the discrete piece of functionality being ask for, and the benefit of accomplishing the task.

User stories should accomplish two primary things: they should identify the need of the user in a non-technical way, and they should be capable of being easily translated into a test case that will dictate if the work done successfully accomplishes the request, and fulfills the requirement.

The project manager and the technical lead (who will be acting as scrum master or managing the Kanban board) should create the user stories. This way the project manager can ensure that the user story appropriately reflects the requirements, and the technical lead can ensure that the user story can be appropriately broken down into work items. Additional requests might come in at a later date, that the project manager must subsequently vet, and find the appropriate place for it in the backlog.

User stories are often assigned story points. It is the job of the technical lead to assign an appropriate number of story points based on his or her experience. Story points are supposed to not be time-related, but instead reflect difficulty in relation to other user stories. This is fine in theory, but in practice, managers want timeframes, and often story points end up being a masked time estimate anyway. An adequate practice would be to have a single story point represent a single day’s worth of work and move forward from there.

Iterations

Once user stories have been created, and the backlog has been filled, the stories need to be prioritized. These can be dragged around in TFS to make things easier. The project manager and the technical lead can then begin to assign user stories to an iteration. Iterations are usually scheduled for two or three week intervals. If multiple projects are being undertaken, an effort should be made to make sure that all iterations within projects end at the same time. In organizations where different resources are used on different projects, and priorities shift, this is important in case adjusting resources and timelines is needed.

Forecasting and Velocity

TFS offers a good tool for forecasting work based on story points and developer velocity. If the technical lead has filled in all of the story points, and the backlog is prioritized, the technical lead can then determine the story point output per iteration for the current team. This will draw forecasting lines predicting how many iterations will be required to complete the work requested with the current resources. This is especially useful to test out what would happen if additional resources are added, or if resources are taken away. It could also influence the prioritization of the user stories, if one or two larger user stories are pushing work further out than a projected milestone.

Work Item Breakdown

After user stories are created, the technical lead will then break down the user stories into individual work items. These work items, or tasks, are the things that need to be accomplished technically in order for the user story to be considered complete. The technical lead can then assign these work items to individual people.

Effort

TFS offers effort tracking if there is something needed for a project. Each work item has an initial value for estimated effort, as well as a spot for recording the hours completed and the hours remaining. In addition, each iteration has a section for filling out the capacity of individual team members. If you combine the capacity feature with the effort estimates, once work items are assigned to individuals, you will quickly be able to determine if the collective estimated effort for the work items exceeds the individual’s capacity. The technical lead and/or the project manager can then adjust expectations, and reassign tasks.

Kanban Board Maintenance & Use Case Testing

Kanban boards can have many different column configurations. A preferable one has columns for queue, development, integration, testing, and closed (or completed).

• The queue is the backlog where all new user stories exist, or where you return user stories that have had some work, but for some reason (e.g., priorities) have been stopped.
• Development is the column for active items.
• Integration is for items that have been completed by the development team, and are in the process of being merged and deployed (e.g., through continuous integration) into a testing environment. If the testing team is separate from the development team, it is a good idea to divide integration into a "doing" and "done" column to simulate a pull rather than push system.
• The doing column inside of the integration column is for when the development team has checked in their work, but it hasn’t yet made it to the testing environment.
• The done column inside of the integration column is for when the work has made it to the testing environment, and is now ready for a tester to pull the item over into the testing column
• The testing column is for items that are currently under review by the testing team. On the story Kanban board in TFS, this column often has user stories ready for testing and bugs that have been resolved and are ready to be closed.
• The closed (or completed) column is for when the user story has passed user acceptance testing.

One important point is that developers should not be responsible for closing user stories or bugs. There needs to be another person or group that validates that the work is not just finished, but meets the business requirements.

Bugs

In TFS, bugs can exist inside of a user story (at the work item level) or inside of features (at the user story level). Either is acceptable, however, most often bugs can be found—or reintroduced—long after a user story has been deemed complete. Do you attempt to find, and then reopen, a user story in order to add a bug, or do you just add the bug at the user story level? The latter seems much more efficient. It allows you to attach the bug to a feature, it prevents you from having to search for, and reopen, past user stories, it can still be linked to a user story (in TFS) if necessary, and oftentimes—especially if the bug is coming from a user and not a tester—the language is somewhat similar to a user story request.

When a bug is entered into the system, the technical lead will assign it to an individual. When that bug is resolved (not closed), the system will reassign it to the person who reported (or entered) the bug, and the bug will shift to the testing column (this can be automatic if configured correctly in TFS). If a user story is being tested, and a bug is discovered, a bug should be created, and the user story can either stay in the testing column or be moved back to the integration/done split column.

End of Iteration Meetings and Change Requests

At the end of each iteration, the project manager(s) and technical lead(s) should sit down collectively to go over the past iteration, as well as the overall Kanban board. If this is a multi-project environment, all boards should be reviewed in the event that resources have to be shifted around.

It is possible that during an iteration, a new request comes in that changes requirements. This should be cataloged as a change request (so that it is noted for the record), reviewed at the end-of-the-iteration meeting, and then, if accepted, added to the backlog in the appropriate manner. Although TFS does not have a change request work item in their agile template, one can be added through editing the XML configuration of the system.