Three Best Practices For Success in TFS 2010 Agile Projects

Okay, there are a lot of things you probably should be doing in TFS 2010 and probably are already doing. But my “Big 3” best practices are things some agile development teams I have worked with should be doing, but they tend to balk at even when I emphasize the importance of each. So I thought a blog might be helpful to illuminate, in writing, why I believe they are of vital importance to successful agile projects using TFS 2010 work item tracking. This blog only continues the theme that I see almost universally when working with customers who want to deploy TFS 2010: they routinely desire more visibility, traceability, and more predictability. The best practices outlined in this short post will help, in various ways, to achieve all three.

1. Stack Rank

I talked about the stack rank in my post on a three-tier hierarchy for TFS 2010 here, and will expand a bit on those thoughts in this post. Basically the stack rank allows you to effectively prioritize Features within the business community. Capabilities are stacked by the business community in concert with the test and technical communities. While stack ranking of Capabilities is primarily a task for the technical team and is system level, the business still needs to be informed what features will be delivered first, and the Test/QA team needs to know what must be tested and in what order. In essence, we're emphasizing the team nature of software development with TFS 2010, where all team members are working together in concert to deliver a working system in an agile manner. The stack rank is a key part of scheduling work into iterations in an orderly manner based on business priorities, as well re-prioritizing work items that are not being currently worked inside of an iteration.

2. Daily Time Entry

One area where I tend to get resistance from some teams is the requirement for daily time entry of tasks. I have to say unequivocally that this is not an area that should be under negotiation for any team that expects to be successful with TFS 2010 in terms of work item tracking. Project visibility and traceability are inherently dependent on daily reporting of task progress. In TFS 2010, for the MSF Agile 5.0 process template, the following key project management reports depend on daily time entry:

• Burndown and Burn Rate – Helps track the team's progress toward completing the work for an iteration. Shows how many hours of work the team has completed, how many hours remain, the rate of progress, and the work assigned to each team member.
• Remaining Work – Helps track the team's progress. Shows the total number of hours of work in an iteration and the team's progress toward completing it.
• Stories Overview – Helps track how far each user story has been implemented. Shows each story's actual number of hours of work remaining and completed, its acceptance test results, and the number of bugs that are linked to each story.
• Stories Progress – Helps track recent progress for each user story. Shows each story's remaining, completed, and recently completed work.
• Unplanned Work – How much unplanned work is there?

The reports above are vital to provide visibility into project process for team leads, project managers, and executive management. Through the use of individual developer's queries, coupled with bulk input from Excel, daily time entry should take no more than a few minutes for developers to enter time on a daily basis. The entire team benefits, which includes developers, team leads, testers, business analysts, project managers, and executive management. Again, this is done for the sake of visibility and traceability, which is available to all involved on a team project. Without daily time entry, you will have lost a major portion of your investment in TFS 2010, as it would be a glorified source code control system, with the only true benefits being the ability to check in code against work items, and produce your daily builds if you decide to use this feature. The agile integration that is now a fundamental part of TFS 2010 is the result of many years of feedback, and if you expect to be successful with work item tracking in TFS, then I implore you to take advantage of this feature. Not performing daily time entry is a huge mistake and will hurt the entire team.

Daily time entry begins with original estimates for each task that has been assigned to a developer within any given iteration. During iteration planning, each developer would enter their original estimates in anticipation of the upcoming iteration, and the team lead would use the iteration backlog to ensure that a) developers are effectively loaded based on workable hours during the iteration, and b) work is balanced across development resources. Once the iteration has commenced, it is up to the developer to record the hours for each task worked that day, and to record the amount of remaining hours on each task. The developer must do the math of subtracting from remaining hours or adding hours if the task appears that it will take more work than expected. The developer must do the math to add to the cumulative hours that a task has been worked. The reports will reflect unplanned work if the cumulative hours worked are above the original estimate, which is why it is important to not touch the original estimate once the iteration has commenced.

3. Daily Builds

Team Foundation Build provides the functionality of a public build lab and is part of TFS 2010. With Team Foundation Build, build managers can synchronize sources, compile the application, run associated unit tests, perform code analysis, release builds on a file server, and publish build reports. Build result data is propagated to the warehouse for historical reporting.  Builds can be scheduled in a number of ways, including a build on every check-in, as well as gated check-ins that won’t allow check-ins that “break” the build. At a minimum, I strongly recommend that builds be done on a daily basis during each development week.

Daily builds represent the “heartbeat” of any development effort. At a minimum, daily builds indicate project progress and also indicate if the collective changes developers have made the day before won’t compile as a unit. If the daily build fails, then it is the responsibility of the team to make the build integral again. Thus, at worst, only a day’s worth of changes will ever accumulate that “break” the build. A build is also a candidate to be promoted from development to test, and ultimately one build will go into production. Bug work items are also associated with a build since the test team will focus on testing specific builds that have been promoted by the development team. The development team determines which builds will go to test, and can indicate to the test team specific Features and Capabilities that have been added or modified within a particular build.

Are Daily Builds Complicated?

In general, the complexity of the daily build depends on the complexity of the project. Some team projects have many Visual Studio projects with complex dependencies, particularly those with third-party components or, for example, mainframe integration, whereas others have little to none. The daily build does require some effort to setup initially, but there is little maintenance moving forward. Once it is setup it will run every day as scheduled automatically, and diagnostics will be recorded in order to provide powerful reports that provide a window into progress of the project in terms of build quality, build success over time, and build status such as test results, test coverage, and code churn. If you wish to include unit tests or automated tests then these will need to be added or modified as required, but there is little difficulty once this is initially setup.

Conclusion

My hope is that this post was helpful to you, and causes you to think a bit more about what is important when implementing TFS 2010. I’m always open to your comments, questions, and suggestions.

Comments

• Anonymous
  January 05, 2011
  Good post!!!

• Anonymous
  January 05, 2011
  Good post!!!

• Anonymous
  January 05, 2011
  Good Post, Walter