Project Tracking using a Task Board

A great way to provide visibility and focus to a sprint is by adding a task board to your team room to track the progress of each task for each story in the sprint. With a task board, the team can quickly see what is going on, who is working on which tasks, and how each story is progressing. The task board also provides a great focal point during the stand ups allowing the team to make sure they are working each story to completing and any additional tasks found during the sprint are called out, estimated, and tracked.

A sample story board layout is shown below:

There electronic version of the task board in most agile tools (like the one for Version One shown below) that work well for distributed teams, but I have found that when teams are located at the same physical location a physical task board works much better.

You can build the task board using a cork board and index cards, a white board with post-it notes, or any other office supplies that you find work for you. I like the cork board and index cards, often adding post-it notes for the ‘task cards’ and flagging who is currently working on a task.

The task board has a number of columns and rows. The first column is for the story card and each row represents one story. The second column holds all the tasks identified during sprint planning. The remaining columns represent the status of the task as they are moved from “Not Started / To Do”, to “In Process”, to “Ready to Test”, to “Done”.

The story cards have the short description of the story, the estimate in story points, and acceptance criteria (typically on the back of the card). The task cards have a description of the concrete task and an estimate, in hours, of how long the task will take. If a task card has a large number of hours estimated – it is probably a good candidate to be broken down in to smaller tasks.

Working Stories with the Task Board

As the team works on a story, each task card is moved from “No Started” to “In Progress”, when a team member selects that item to work on, they will physically take the task card or post-it note from one column and move it to the next. If new tasks are found during development of a story, a new task card is added to the board in the “Not Started” column. If a task is found to be un-necessary, it is removed from the board.

When all tasks are moved to the “Done” column, the story is considered complete, potentially releasable, and the team can move on to the next story. (Remembering that it’s best if the team can complete one story and then move on to the next to minimize the work in progress.)

Daily Standups and the Task Board

The team should focus on the task board during the daily stand up. All conversation and commitments discussed by the team should focus on the task board. Team members should be moving tasks while discussing what they are worked on, and are going to be working on.

Having the team focus on the task board helps keep the focus on the stories and tasks and gives the team a very visible reminder of the progress and if new work is being added mid-stream.

Note: I lost my photos of a team standing around the Task Board (I hope to take some more soon), but I did find similar ones – and some other handy tips – at the visual management blog. See ‘borrowed’ photos below:

Photo 1 – Team in a circle facing each other. Good conversation, but hard to keep up with what is going on. Somewhere just out of the frame, the scrum master is scratching notes as fast as he can so he can update the status on a spreadsheet that no one every sees. (Not the best approach.)

Photo 2 – Team facing the task board. Still have good conversation, but the focus is on the stories, the planned work, and the commitments made by the team. And, the scrum master doesn’t have to take notes; the team manages the status right on the board. (Can it get any better than this?)

Resources

As usual, Mike Cohen has a good description of this: http://www.mountaingoatsoftware.com/scrum/task-boardsand some additional examples.

Interesting Link

http://jasoncrawford.org/2010/04/how-to-work-with-stupid-people/

Files Required to use Oracle SQL Plus

We need to use Sqlplus.exe for our database build process, but depending on which version of the Oracle client that is installed, the required files can be in a number of different directories.

To have a consistent build script, we want to place SQLPlus.exe in a well know directory on each of the build servers, no matter how the Oracle client was installed. To do this, we simply copy SQLPlus.exe and the supporting files to a well known directory where our build tools can execute it.

The tricky part is to get the correct supporting files deployed as well. To find the required supporting files:

1.) Start Sqlplus.exe from the normal Oracle client directory – where ever that is base on the Oracle install.

2.) Use Sysinternals Procmon.exe to view the SQLPlus.exe executable process and provide the associated dlls.

3.) The list of supporting dlls is:

• oci.dll
• oraocci11.dll
• oraociei11.dll
• orasqlplusic11.dll
• msvcr71.dll

By coping Sqlplus.exe and the dll’s listed above to a well known directory, we can reliably exeucte SQLPlus.exe from our build script – no matter how the oracle client was installed.

Updating a TFS Work item template with WITIMPORT command

Modifying the Template

Work item templates can be made fairly easily by modifying the associated XML files.

You can retrieve the files by going to the Team Menu, Team Foundation Server Settings Menu, and selecting Process Template Manager… menu item to display the Process Template Manager Dialog box shown below:

Select the process template you would like to modify and select “Download”. You are then prompted to select the directory where you want to download the files. The file structure of the template is shown below:

There is an xml file with the definition of each type of work item.

The work item definition files have sections for definition of the work item data, state workflow tracking, and descriptions for the fields where the data is stored.

You can use Visual Studio to edit the fields, layout, and workflow definition of each item. Or, you can work directly with the XML file.

Updating the template of an existing project

You can simply upload the revised template, using the same name or a different name to TFS using the Process Template Manager, but your changes will only show up for new Team Projects that use that template. This is typically not that useful of a feature, as one doesn’t create new Team projects very often. It is often better to import the template changes into an existing project. To do this, you can use the witimport command line utility.

The witimport command can be found in the C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE directory.

The command line arguments are pretty straight forward:

witimport /f filepath /t tfs /p teamproject [/v] [/e encodingname]

Details on this utility can be found here: http://msdn.microsoft.com/en-us/library/ms253163.aspx

Build and Deployment with TFS

Build and Deployment Practices

Goals

• Manage concurrent development efforts of the team effectively.
• Manage product quality by rigorous unit and functional testing.
• Maintain the ability to deploy any version of the application and related database schema and base-line data at any time to any environment.
• Provide the ability to address defects identified in production while continuing to add new functionality slated for future releases.
• Be able to respond to defects in User Acceptance Testing (UAT) or production without injecting new functionality into the deployed version of the application.
• Keep the main code line (development branch) synchronized with any defect fixes made in a release branch.
• Provide the ability to report on the status and progress of all development and deployment operations.

Principles

• Source code is the source of truth (i.e. Golden).
• Maintain fidelity between the source code and the delivered product.
• Remove the chance for error everywhere in the process by using automation and implementing process controls where possible.
• Make the management and tracking process simple and easy for developers (low friction).
• Audit (log) all build and deployment activities.

Versioning

The continuous integration process increments the build label each time it builds the solution. We use the build version number to track the build, build metrics, integration test results, and deployments.

The version number uniquely identifies each build. When we have a build with new stories ready for testing, we select the build in TFS, set the build quality to “Ready for Initial Tests”, and the functional tester selects the build, creates the deployment, and starts functional testing the build. When the functional tester is finished testing the new stories and regression testing the application, the build quality is marked “Ready for Deployment” and can be deployed to production.

To facilitate identification and tracking of the application versions the following number schema is used:

{Major}.{Minor}.{Build}.{Revision}

e.g.: 1.0.123.0

e.g.: 1.1.343.0

e.g.: 1.1.343.1

The major version number designates the current release branch we are working on. The major version number is incremented each time we have a new release to production. The major version is tied to the release number we establish for a group of features within TFS.

The minor version number indicates the sub-release for the designated branch. We increment the minor version number when deploying production fixes made to a code branch that is already in production.

The build number indicates the specific build we are working with. We increment the build number each time we build the product. With continuous integration, we may build the product several times a day. Each build attempt will have a new build number associated with it.

The revision number indicates a ‘patch’ release. We don’t expect to need patch releases and will not use the revision number at this time.

Branching Strategy

We use a Branch for Release strategy where we create a new branch each time we release a version of the application to production. The release branch gives us the ability to fix production issues and re-release without adding additional functionality from the next sprint into the build.

Branching Model

Note: we don’t need to actually create the physical branch for the release when we release the application. We can create the branch from the label if we need to make changes and re-deploy the release branch during the next sprint. This allows us to only branch the source tree when absolutely needed.

Continuous Integration and Version Build Use Cases

1. Continuous Integration (CI) Build

The continuous integration build retrieves the latest version of the source code from the mainline (development) branch in source code, updates the version number in the assemblies, executes the full set of database scripts against the development (integration) database, compiles the source code, performs the static code analysis, executes the unit tests, and code coverage analysis. If all these steps execute without error, we consider the build successful and the build reports indicate success and all build metrics.

The continuous integration build ensures the solution compiles and unit tests execute properly. We want to ensure that all the code changes made by the developers on the team integrate properly. If changes break the build, we want to know as quickly as possible so the developer that checked in the breaking change can resolve the issue immediately. Since we won’t be deploying the CI build for testing, we won’t label the version in the source repository and we won’t update the version number in the App.Config file.

2. Test Version (New Version) Build

When we are ready to test a new version, we initiate the build of a new version of the application and prepare the application for deployment to the test environment by creating a ClickOnce deployment package. To do this we increment the version number, apply a label with that version number to the main (development) branch in the source repository, retrieve the source files, set the value of the version number in the App.config file, update the value of the database connection string in the App.config file, execute all database package scripts against the Test database, update the assembly version number for all assemblies, compile, analyze, and unit test all assemblies. With the assemblies created and tested, we then build the ClickOnce deployment package, modify the link on the ClickOnce deployment HTML page, and copy the deployment files to the deployment location (currently on the TFS01 server).

If the build succeeds, we have a new version of the application ready to be installed and tested. The tester can install the new version of the application on a Virtual Machine for testing, or directly on their workstation.

3. Production Version Build

Once a version of the application has been through a full suite of functional and user acceptance tests and is ready to be deployed to production, we build the specific version of the application and create a ClickOnce package for deployment to production.

To create the versioned build, the build master selects the labeled version to create, and initiates the build process. The build process retrieves the files tagged with the specified version number from the source repository, sets the version number and the connection string information in the App.config file, updates the assembly version number information, compiles the code, performs static analysis, executes the unit tests and code coverage analysis, creates the ClickOnce deployment packages, updates the ClickOnce HTML page link information, and copies the deployment pack to the deployment location.

Using Team Build to manage the build process

Requirements of TFS

TFS’s Team Build requires the following:

· A unique name (number) for each build.

We must:

1.) Store the current increment number in a common location on the build or drop server.

2.) Increment the build number when the build kicks off.

3.) Label Source control with the build number generated.

4.) Override the Target in TFS – “BuildNumberOverrideTarget”.

5.) Remember every build number must be unique. (Build name must be unique.)

a. We may need to use something like “{BuildDefinitionName}_1.0.0.0″ to define a build that we do for CI and a build we do for Testing, Or Production.

Note: Custom Build Number Generator – uses file stored in build drop section, and DLL Placed in the Build Directory in Source Control – and referenced in the MS Build file on the server.

We Override the <Target Name=”AfterGet” /> target to get the assembly info files and update the version number of each assembly to match the build version number.

<ItemGroup> 
  <AssemblyInfoFiles Include="$(SolutionRoot)\**\assemblyinfo.cs" /> 
</ItemGroup>   
<Target Name="AfterGet"> 
  <!-- Update all the assembly info files with generated version info --> 
  <Message Text="Modifying AssemblyInfo files under
                                         &quot;$(SolutionRoot)&quot;." /> 

  <Attrib Files="@(AssemblyInfoFiles)" Normal="true" /> 
  <FileUpdate Files="@(AssemblyInfoFiles)"                                 
              Regex="AssemblyVersion\(&quot;.*&quot;\)\]"
              ReplacementText="AssemblyVersion(
                                &quot;$(VersionMajor).$(VersionMinor).
                                    $(VersionService).$(VersionBuild)
                                &quot;)]" /> 
  <FileUpdate Files="@(AssemblyInfoFiles)" 
              Regex="AssemblyFileVersion\(&quot;.*&quot;\)\]"
              ReplacementText="AssemblyFileVersion(
              &quot;$(VersionMajor).$(VersionMinor).
                    $(VersionService).$(VersionBuild)
              &quot;)]" /> 
  <Message Text="AssemblyInfo files updated to version
              &quot;
              $(VersionMajor).$(VersionMinor).
              $(VersionService).$(VersionBuild)
              &quot;" /> 
</Target>

Custom Build Tasks

To control the build number versioning, we created a custom MSBuild Task: “IncrementBuildNumber” to retrieve the last build number from the build number file, increment the number and update the build number file with the newly created version number.

We include our custom task in the build type, by adding the following tag to the TFSBuild.proj file:

<UsingTask TaskName=”IncrementBuildNumber”

AssemblyFile=”$(TeamBuildRefPath)\CustomBuildTasks.dll”/>

To manage the increment the build number during the build process, we call the IncrementBuildNumber task in the “BuildNumberOverrideTarget” in the TFSBuild.proj file as shown below:

<PropertyGroup>

<VersionBuild>9999</VersionBuild>

</PropertyGroup>

<Target Name=”BuildNumberOverrideTarget”>

<!– Create a custom build number, matching the assembly version –>

<Message Text=”Loading last build number from file
&quot;$(DropLocation)\buildnumber.dat&quot;” />

<IncrementBuildNumber NumberFile=”$(DropLocation)\buildnumber.dat”>

<Output TaskParameter=”NextNumber” PropertyName=”VersionBuild” />

</IncrementBuildNumber>

<PropertyGroup>

<BuildNumber>$(BuildDefinitionName)_$(VersionBuild)</BuildNumber>

</PropertyGroup>

<Message Text=”Build number set to &quot;$(BuildNumber)&quot;” />

</Target>

Running all Unit Tests

Initially, TFS assumes that you want to use a .vsmdi – metadata – file to maintain a list of all unit tests to run in the build. This requires the developers to manage the updates to this file each time the add a unit test. When we create an integration build, we want to run all the unit tests in the solution, and we don’t want to have to rely on the developers updating the unit test metadata file each time they check in a new unit test. So, we use the Test Container feature of TFS 2008 that allows us specify a pattern for test assemblies. When the pattern specified, we tell the TFS build process to execute all tests within the solution, not just those specified in the unit test metadata. To use the test container, add the following to the TFSBuild.proj build definition file after the TestArguments section:

<TestContainer Include=”$(OutDir)\%2a%2a\%2a.Test.dll” />

Executing Code Coverage Analysis in the Build

To run code coverage analysis in Team system, a test run configuration file is required. The test run configuration file maintains a list of assemblies to instrument for code coverage analysis. Developers maintain the test run configuration file as needed when they add or remove assemblies from the solution.

To include Code Coverage Analysis in the build, we specify the location of the test run configuration file using the <RunConfigFile> tag in the TFSBuild.proj file. Note, this tag must be specified within the <PropertyGroup> tag.

<PropertyGroup>

…

<RunConfigFile>$(SolutionRoot)\Main\
BuildIntegrationTests.testrunconfig</RunConfigFile>

…

</PropertyGroup>

ClickOnce Deployment

We use ClickOnce deployment to manage the distribution of new versions of the application in all environments (Dev Test, Functional Test, and Production). Our build and deployment process creates a new ClickOnce deployment packages with each build. Each environment has a unique drop location and install web page, allowing our testers to install a test version of the application and production users to install a production version of the application.

The application deployments may differ both in version number as well as the database connection used. (Test uses the test database connection, and production uses the production database.)

To create the ClickOnce deployment packages, the build process must:

· Set the application and deployment properties to match the version and environment specified by the build type information.

· Create an application manifest file using the mage.exe utility.

The application manifest describes the application, including: the assemblies, the dependencies, the files that make up the application, the required permissions, and the location where updates are available.

· Create a deployment manifest file that describes how we deploy the application, again using the mage.exe utility.

The deployment manifest includes the location of the application manifest, the version of the application that clients should be running, and the update location where the application checks for updated versions – specified in the publish properties.

· Copy the deployment files and application files to the deployment location, i.e. the web server running on the TFS01 server. The deployment manifest specifies the deployment location.

Using MSBuild to generate the ClickOnce deployment

Running TFS Unit Tests without Specifing the VSMDI File

Buck Hodges describes this in detail and provides utilities to make this happen:

http://blogs.msdn.com/buckh/archive/2006/11/04/how-to-run-tests-without-test-metadata-files-and-test-lists-vsmdi-files.aspx

The move from NAnt to MSBuild

Switching from NAnt to MSBuild, we have had to port our custom tasks from NAnt to MSBuild. Since the design of MSBuild is so similar to NAnt, this is actually pretty easy to do.

In addition to our custom tasks, we use many tasks found in the NAntContrib project. Luckly, there is a similar project for MSBuild so we don’t have to re-implement all the these tasks as well.

The MSBuildContrib files can be found here: http://msbuildtasks.tigris.org/.

As stated on the Tigris page:

In order to use the tasks in this project, you need to import the MSBuild.Community.Tasks.Targets files. If you installed the project with the msi installer, you can use the following.

<Import Project=“$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets“/>

Setting up Custom Version Numbering in TFS Build

Editing the MSBuild File for Team Build

TFS Build uses the [Microsoft.TeamFoundation.Build.targets] file to define the set of build tasks and targets needed for the FTS Build process. This file is typically found on the TFS build server in the directory: [C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild].

This file is shared by all builds that run on the build server so use care when editing this file to add new targets or modify existing targets.

Working with the TFSBuild.proj file

Overriding BuildNumberOverrideTarget

The base targets file has an existing target that provides for implementing your own build version number scheme.

</p> <p>&lt;!-- Override this target to execute a task for customizing the build number and/or drop location. Make sure that the task outputs properties with the names 'BuildNumber' and/or 'DropLocation'. --&gt; <br/>&lt;Target Name="BuildNumberOverrideTarget" /&gt;</p> <p>

Replace the oringal target with the following xmal block to call our custom build numer version mechanisim.

</p> 
<pre class="xml">
&lt;PropertyGroup&gt; 
  &lt;VersionMajor&gt;1&lt;/VersionMajor&gt; 
  &lt;VersionMinor&gt;0&lt;/VersionMinor&gt; 
  &lt;VersionService&gt;0&lt;/VersionService&gt; 
  &lt;VersionBuild&gt;0&lt;/VersionBuild&gt; 
&lt;/PropertyGroup&gt;
&lt;Target Name="BuildNumberOverrideTarget"&gt; 
  &lt;Message Text="Loading last build number from build version file &amp;quot;$(DropLocation)\buildnumber.dat&amp;quot;" /&gt; 
  &lt;IncrementingNumber NumberFile="$(DropLocation)\buildnumber.dat"&gt; 
    &lt;Output TaskParameter="NextNumber" PropertyName="VersionBuild" /&gt; 
  &lt;/IncrementingNumber&gt; 
  &lt;PropertyGroup&gt; 
    &lt;BuildNumber&gt;$(BuildDefinitionName)_$(VersionMajor).$(VersionMinor).$(VersionBuild).$(VersionService)&lt;/BuildNumber&gt; 
  &lt;/PropertyGroup&gt; 
  &lt;Message Text="Build number set to &amp;quot;$(BuildNumber)&amp;quot;" /&gt;  
&lt;/Target&gt;
</pre>
 <p>

Deleting work items from TFS

This is much more involved that it need be.  Why not just have a ‘delete’ menu item and ask ‘are you realy, really sure you want to delete this work item’?

Anyway, here is how you do it:

1.) Get and Install TFS Powertools, if you haven’t already done so.  (Get it Here)

2.) Open a command window and navigate to the directory where tfpt.exe is located. (Usually found [C:\Program Files\Microsoft Team Foundation Server 2008 Power Tools] directory)

3.) Type: tfpt destroywi /server:<serverName> /workitemid:<workItemNumber>

4.) Answer ‘Y’ to the prompt.

When are we Done?

Measuring Progress

Measuring the progress of an agile project is simple – the working, tested, and deployed unit of software shows the exact progress of the system.  Gone are the days of having 80% of your tasks 90% done for most of the project.  There are no partially implemented features, there are no “almost there” project estimates.  What’s done is done, what’s not done is not done. Even if a feature has 99% of the code, unit tests, user interface, and documentation created – if it is not releasable, then it’s not considered done.

Agreeing what Done means for your team

1. All code for feature(s) is complete, commented, and peer reviewed.
2. All Code Analysis rules pass, there are no errors or warnings.  This assumes the code builds without errors or warnings.
3. Unit (Integration) tests for the code modules (business objects) are complete.  Boundary conditions are tested, and all ‘standard’ business object tests pass.
4. 100% of the unit testable code is covered.  Note: In practice we can only get about 97%-98% code coverage when creating integration tests that access a ‘live’ database.
5. Code meets development standards and naming conventions.  (This is validated via a peer review process.)
6. Deployed to system test environment and passed system tests
7. Code / UI / Module passes functional testing (see functional testing check list) and passes user acceptance testing.
8. Design documents, including domain/design model elements are up to date, any user documentation require is created and checked into the team site on share point.
9. Task work items are updated, the remaining time is set to zero, and the task is marked as closed.
10. All time spent on tasks is updated on the time tracking spreadsheet. (On the team share point site.)