Pimping your TFS Project Portal

I don't think of myself as an ALM guy, but I have worked on a number of projects that happened to use Team Foundation Server. I find customers tend to make use of different features over time:

1. Initially, they just use the source control feature
2. Then they start to use automated builds
3. After a while, they may start to use work items
4. One day, after a long time, they might start to use reports

One area that is often neglected is the SharePoint project portal. I've seen some teams (notably our internal development centre and the Microsoft SDC) who make great use of the portal, but more commonly it's completely unused.

Recently I decided to customize the portal on a project I was working on, and thought I might share some tips for pimping your TFS project portal.

The goal of the project portal should be to provide easy-access to anything people on the project might need, especially those who don't normally interact with TFS through Visual Studio.

Lists

1. Environments list
   Most projects will do automated deployment to a number of servers, such as development, test and production. Your project portal home page should show a list of these environments. You might have the following columns:
   • Name of the environment
   • Status (online, temporarily offline, etc.)
   • URL/access instructions
   • Date and build number of the build currently deployed to the server
   • Information about test usernames/passwords if necessary
2. Active Risks
   I use a simple risk register to track things that need to be done, but can wait a few weeks. Think of them as impediments that we know will take a long time to resolve. Ideally risks would be stored as work items in TFS, but I find it's common that not all stakeholders have a TFS CAL, so a SharePoint list is a good substitute. An example of a risk might be that we need confirmation from a hardware vendor about the specs we have requested - it doesn't block us, but someone needs to resolve it. Potential columns:
   • A title and description
   • The user who will 'own' following up on this risk to ensure it doesn't impact the team
   • The status (not started, in progress, resolved, etc.)
   • The iteration/sprint number before which the risk needs to be resolved
3. Iteration plan
   Iterations and their work items should be stored in TFS, but I like to show a short list of iterations on the project portal home page. The nice thing about keeping these in a list is you can use them as a "choice" field in some of your other lists:
   • Iteration name (e.g., Iteration 3)
   • Start and end dates
   • A statement of the overall goal of the iteration - e.g., "Patient search and inbox"
   • Any important resourcing notes - e.g., "Jack's last iteration"
4. Glossary
   On any project there are a number of terms that arise that your everyday "off the street" developer won't understand. If you are doing Domain Driven Design, this might also house your Ubiquitous Language. The glossary is a good place to capture this:
   • Name of the term and a description
   • Whether the term is an industry-specific term, a business-specific term, or a technical term
5. Important dates
   While the team works to produce the product, stakeholders are often scheduling other things around the project, such as demos, external reviews, dates when new servers will arrive, and so on. It's a good idea to put these on the project portal so that the whole team has an understanding of when these will take place.
6. Contacts
   Make sure everyone on the team has a way to contact everyone else. If it's an internal team, you might be able to rely on Active Directory to track this, but if your team is made up of a mix of staff, contractors and consultants it might be easier to list contact details on the project portal.
7. Other things people should know
   On one project, we had a daily standup teleconference at 9:30 AM. I made sure the project portal home page had the time, dial-in numbers and some short rules on what is expected of people in the standup.
8. Retrospective Feedback
   At the end of an iteration, it's a good idea to hold a retrospective with the team. We use this to brainstorm ways to improve how the team works. Rather than just capture these in your notepad, add them to a SharePoint list:
   • A title and description
   • Iteration number
   • Category (something we did well, something we should start doing, something we should stop doing)

When you do the next retrospective, you can bring up the previous round of suggestions to see whether you successfully stuck to them or not.

Wiki

You might intend to use word documents for Formal Documentation later in the project, but a wiki is a perfect way for the team to collaborate on documentation and keep them up to date while the project progresses and things change rapidly.

Some important things any project wiki should contain:

• Getting Started
  When a new developer joins your project, there should be a single page that helps them to get started and be productive. It will tell them:
  • The TFS connection to use
  • The TFS path from which to get latest
  • The solution to open
  • Steps to get the project to compile and run
  • Links and licenses for any third party tools or libraries they will have to install
  • If your project has custom tools that developers need to use to be productive, such as code generators, include documentation on how to use those
• Communication manifesto
  If your team is centrally located, this might not be so necessary. If team members work from different floors or remotely, you might find it worthwhile to capture this:
  • If you do a daily standup, explain the rules of the standup, and what time it starts
  • You might hold a sprint kickoff meeting at the start of every sprint, or a retrospective at the end. Make sure these are listed.
  • If your team is doing remote standups by teleconference or email
  • If you are using work items in TFS, make sure people know to update these regularly, such as daily
  • Let people know what you expect to see in check-in comments. For me, I need to see at least a full sentence. Hold up some examples of good checkin comments, and try to lead by example!
  • Let people know how to use "ambient" communications, like check-in notifications and work item reports, to stay abridge of project progress
  • If you are doing code reviews, put some tips on how to ask for and conduct a review
    1. Standards, practices and principles
       If you have a larger team or a team with higher than usual turnover, it's good to capture some of the standards you have.
  • Coding standards. I hate long coding standards documents, but then can usually be standardized in about five or six points: this is how we name private fields, for everything else, do what ReSharper suggests. Class names and namespaces should match file names and folders. That's all we need.
  • Principles the team should be aware of. Uncle Bob's SOLID principles are a good start.

Needless to say, you can track most of this information in other places, and you don't need to use TFS or even SharePoint for any of this. But if you are using TFS, you probably already have a SharePoint portal, so why not make the most of it?

If you are using your project portal, what other items would you add to this list?

Special thanks to Darren Neimke and Mitch Denny for the communication manifesto area, which I picked up from the way they ran our internal development portal.

Also, I do apologize for posting about SharePoint - I promise it's a once-off and I'll stick to WPF :)

Hello, I'm Paul Stovell

I'm a Brisbane-based software developer, and founder of Octopus Deploy, a DevOps automation software company. This is my personal blog where I write about my journey with Octopus and software development.

I write new blog posts about once a month. Subscribe and I'll send you an email when I publish something new.

Subscribe