We’ve been using ordinary playing cards for our Planning Poker game (Ace is one, King is thirteen) but it limited our range of story points so we’ve bought some cards from Mountain Goat Software that have everything from “?” to “∞”. Of course, now I want to try Team Estimation to see if we can speed up the Planning Meeting …

If we keep metrics of how our Project Velocity changes as we add developers to the Team we can begin to get a rough estimate for how it will affect the Project Burndown.

In this blog post Mike Cohn estimates that adding a seventh developer to a six man team will reduce the velocity by approximately the amount you’d have expected it to rise by in the next iteration. In the second iteration following you will still be below your original velocity and it’s not until the third iteration following that you’ll gain your expected increase in velocity. Note also that the total gain in velocity will be less than ⅙th.

Any developer or project manager instinctively knows this and the reasons have been described clearly. For instance, there are four stages a team goes through: forming; storming; norming and performing ^[1] (Bruce Tuckman (1965)). More forcefully, there’s Brook’s Law: “Adding manpower to a late software project makes it later.” (or “Nine women can’t make a baby in one month.”).

Setting up PartCover for .NET unit test code coverage takes a little work.

Trying to running PartCover.exe on x64

“Retrieving the COM class factory for component with CLSID {FB20430E-CDC9-45D7-8453-272268002E08} failed due to the following error: 80040153.”

This is because the COM class requested is 32-bit only and PartCover is running as a 64-bit app.

Setting environment for using Microsoft Visual Studio 2008 x86 tools.

C:\> "%VS90COMNTOOLS%\vsvars32"

Microsoft (R) .NET Framework CorFlags Conversion Tool.

C:\> CORFLAGS /32BIT+ /FORCE path\to\PartCover\PartCover.exe

Microsoft (R) .NET Framework Strong Name Utility

C:\> sn -k PartCover.Console.snk

-k [<keysize>] <outfile>
Generate a new key pair of the specified size and write it into <outfile>.

C:\> sn -R PartCover.exe PartCover.Console.snk

-R[a] <assembly> <infile>
Re-sign signed or partially signed assembly with the key pair in <infile>. If -Ra is used, hashes are recomputed for all files in the assembly.

Running PartCover

This is an example command line to create an Xml report of code coverage.

.\tools\PartCover\PartCover.exe
--target .\tools\NUnit\nunit-console-x86.exe
--target-work-dir .\src\Tests\
--target-args Alpha.Modules.Sam.Tests\bin\Alpha.Modules.Sam.Tests.dll
--output .\docs\PartCoverReport.xml
--include [Alpha*]*
--exclude [*Tests]*

Viewing the report

A new viewer for the reports is required (the stylesheets aren’t very good) – ReportGenerator.

C:\>ReportGenerator.exe
path\to\PartCoverReport.xml
path\to\output_dir

PartCover.cmd

A command script with argument placeholders.

.\tools\PartCover\PartCover.exe
--target .\tools\NUnit\nunit-console-x86.exe
--target-work-dir %1
--target-args %2
--output .\docs\PartCoverReport.xml
--include %3
--exclude [*Tests]*

.\tools\ReportGenerator\ReportGenerator.exe
.\docs\PartCoverReport.xml
.\docs\PartCover\

Using PartCover from VS.NET

VS.NET > Tools > ExternalTools…

Title: PartCover
Command: $(SolutionDir)..\PartCover.cmd
Arguments: $(BinDir) $(BinDir)$(TargetName)$(TargetExt) [*Module*]*
Initial directory: $(SolutionDir)..
Use Output window [check]
Prompt for arguments [check]

Now there is a “PartCover” option in the Tools menu. Select a Test project and select Tools > PartCover. In the displyed command arguments change “Module” to the name of the project, i.e. “Sam”, and run.

The report is written out to: .\docs\PartCover\index.htm

(I would launch IE automatically but haven’t added that to the command script yet.)

I was lucky enough to be able to attend Angela Druckman’s two day CSM (Certified Scrum Master) course in London this week. I can highly recommend it not least because the trainer was extremely good and very knowledgeable but also because the attendees brought a lot of interesting questions to the discussions.

Danube offers many free resources to help teams implement Scrum:

• Danube’s free tool, ScrumWorks Basic
• Blogs by Danube Trainers and Staff
• Whitepapers by Danube Trainers
• Webinars on Scrum Topics (from basic to advanced)
• Danube Staff – Email them anytime.

A good enumeration in your C# code isn’t going to look like the values in your lookup table in your database and neither is it likely to have great descriptions of the items that you could display to your users. So how to extend the enumeration?

We’ve used attributes and called them EnumDescription (to distinguish it from the ComponentModel defined DescriptionAttribute) and EnumRepositoryValue. We then used extension methods on the enumeration values so they could easily display a good description or submit their equivalent value to the database.

One problem is that the .NET Enum type is not extensible so you can’t easily create a FromRepository() extension method without decorating the base Type. For translating database values to enums we created a helper method instead.

Now you can say this:

EnumMother enumMother =
    (EnumMother)EnumHelper.FromRepositoryValue(
        typeof(EnumMother),
        SomeEnumRepositoryValue);

And this:

string description = EnumMother.Some.GetDescription();

And this:

string repositoryValue = EnumMother.Some.ToRepositoryValue();

Given this:

    public enum EnumMother
    {
        [EnumDescription("Nothing at all")]
        [EnumRepositoryValue("N")]
        None = 0,

        [EnumDescription("Some of it")]
        [EnumRepositoryValue("S")]
        Some = 1,

        [EnumDescription("Everthing, ever")]
        [EnumRepositoryValue("A")]
        All
    }

A couple more extensions provide ToList() functionality as a bonus for creating user interface select lists.

We have Object Mothers in Alpha that wrap up test data for the unit tests. This is fine up to a point but we needed to add a Builder pattern to supplement the Factory pattern so we could have easy generation of default + overridden data. A comment on a blog post lead to the excellent NBuilder project which we’re now using.

These snippets of advice on Agile come from people who are practicing Agile and some of the comments are pure gold.

There are some useful resources for adding functionality to your C# application’s framework:

• Extension Methods
• Utility Libraries
• Umberella looks good but is undocumented (what is it with you people?)

I favour dropping the estimation of Tasks in hours for a Sprint. It’s extra work and it doesn’t add anything to the process.

• It’s proven that relative estimation is more correct than absolute estimation. Since ideal man days is a time measure it’s all too easy to make absolute estimations.
• There is no linear correlation between a story point and the number of hours. People who ask how they can correlate story points with ideal time have not yet learned to separate the concepts properly.
• A story point is a universal measurement across the team. It is not biased by the experience or skills of any individual on the team.
• In the spirit of continuous improvement Agile practitioners ought to be alert to opportunities to reduce their process overhead (without losing effectiveness).
• If each story is small enough to be estimated and tested then there may be little benefit achieved through breaking it down into smaller tasks or re-estimating them in hours.
• The return on investment by estimating in hours is not high enough to make that a serious candidate. We want completed, working software, not very accurate estimates.
• A Product Owner wants to know how many features the team will deliver not how many hours each of them take. If the Product Owner gets an idea of the relative size he can prioritise and plan accordingly.
• After the 3rd or 4th sprint, the team reaches a steady state in story points and it becomes easier for the product owner to fill the backlog with story points.
• It’s difficult and time-consuming to to get developers to estimate time to completion. Developers are terrible at estimating because the work they do isn’t the same each time: either it’s a new business problem or they are dealing with a new technology. Developers also have a tendancy to “hoard” left-over time: if they think they have been allocated so many hours to do something then the work expands to fill the available time.

Dropping hours means that in VersionOne the Sprint Burndown Chart won’t show anything at all but we can refer to the Project Burndown Chart and the Cumulative Flow instead as that burns down Story Points.

64 bit versus 32 bit is stinging us all over the place. Now we have some x64 dev machines (nice) and others using x86 machines. The solution is to set the build platform target of each and every project file to x86.

Also, the build server (TeamCity) is on an x64 box. DLLs that were being called had to be updated like NUnit and the Oracle data client. Then NBehave had to be updated as it’s version of NUnit wasn’t exactly the same so we have a nightly build of NBehave!

There are even problems with some of our tools like this problem with PartCover.