2015, this blog in review

The WordPress.com stats helper monkeys prepared a 2015 annual report for this blog.

Here’s an excerpt:

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 24,000 times in 2015. If it were a concert at Sydney Opera House, it would take about 9 sold-out performances for that many people to see it.

Click here to see the complete report.

1+3 != 4

Please stop adding story points

“I’m not sure if I was the inventor of story points, but if I am, I’m sorry” – Ron Jeffries

What is a story point

At their heart story points are an estimate of how much effort/complexity a piece of functionality is to deliver. This estimate is often represented as a number.

That’s fine, but please stop adding estimates!

Let’s say you use Fibonacci numbers to define your story points;

  • A 1 point story could be a trivial change, like fixing a typo
  • A 3 point story could well be something more involved, say adding a couple of textboxes to a website page, and persisting the data entered in them.

How much work is that?

If you have 2 stories, one estimated at 3 points and one at 1 point, how many story points is that? A total of 4 points is something I have heard.

Now, what if I have 10 stories, all sized at 1 point. By this logic we have a total of 10 story points. Nothing wrong with this, assuming the only goal for adding the story points is to re-affirm en elementary grasp of numbers. It gets funny if… you want to know how long the project will take to complete, based on this.

Week 1, we complete only 3 point stories, and complete 5 of these in 5 days.

Week 2, we complete only 1 point stories, and complete 100 of these in 5 days.

I have seen this interpreted as, in 10 days, 105 story points delivered, averaging a velocity of 52.5 story point per week. The sized backlog, stands at 150sp, so all should be complete in approx 3 weeks.

Spread the points

mathsHopefully you can see the problem here.  We can deliver small stories really fast and bigger stories, slow.

In the above example, the longest 3 point story took 2 days to deliver. The longest 1 point story took 3 hours.

The shortest 3 point story took 3 hours and the shortest, 1 point story, took 0.5 hours.

The backlog, has 99 one point stories and 17 three point stories (150 story points, mentioned earlier), so the longest time to complete could be:
99*3hrs (297) + 17*12 (204) = 501hrs = 83 days.

Optimistic time is:
 0.5*99 (50) + 17*3 (51) = 101hrs  = 25 days

At this stage I wonder if I’m writing a maths blog… Lots of numbers here, all based on, an estimate! Some people make the mistake of aiming to deliver n story points per sprint, and when stories are not delivered post mortems happen, to see what went wrong.

“I smell something fishy and I’m not talking about the contents of Baldrick’s apple crumble.” – Blackadder

Nonsense, the lot of it. The only way you can deliver a consistent number of story points per iteration, is if all those stories are the same size and your team’s ability to estimate (and create stories) that are the same size is amazing.

Keep it simple

If every story is enhancing your product (as they should), at the end of your iteration some stories will be ‘done’ and you will have enhanced your product. Story points can be used for getting a feel for the size (complexity/amount of work) a story is. This is useful to the product owner to see how much effort a requested feature is, to help with their prioritisation. It’s also useful if you want to ensure you only take stories of a certain size into your iteration (i.e. a max of 3, say), encouraging story splitting. Story points have other benefits too, but for ‘big’ releases and tracking story point burn up/down/velocity… please stop.

In football the only statistic that matter is the score line; in software, it’s what’s delivered.

Image Credit: Pranav Yaddanapudi

My Application.targets

This post sets out a way to enable TFS to copy and group applications files as well as web project files.


I have a Visual Studio solution with multiple projects. In particular I have a website, a web service (WCF) and a console application. I have TFS running onsite and a build definition associated with my solution. On check in, units tests are run and the build produces build output into a defined drop folder. TFS handily packages the website and web service into their own folders, living inside the _PublishedWebsites folder. The output of the console app is just dumped into the root of the drop folder. Ideally, we want it to be in its own folder and ideally in a folder like _PublishedApps. From here it can easily be picked up by our continuous delivery tooling to be deployed.

Distributed Solution

There are a couple of solutions out there on the web, lurking inside stackoverflow answers and suggesting themselves in other peoples’ blogs.  None answered it as clearly as I want and I’ve since lost the links to them, so this post is here to help me remember how to do it.

This Solution

I suspect there may be other ways of solving this problem. Please do let me know yours in the comments section.The crux of this solution lies in understanding how your web project files get copied to the PublishedWebsites folder in the first place.

The answer lies in the webproject .csproj file. Near the bottom of the file there is a line:

<Import Project=”$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets” Condition=”false” />

It turns out that WebApplication.targets file (comes with Visual Studio install I think) does all the fun stuff.

Find that file on your pc, on mine it’s here:

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications

At this point I confess my knowledge about msbuild scripts comes largely from google. I understand that it’s copying files needed for the website to a directory; this directory is defined near the top:

<WebProjectOutputDir Condition=”!$(WebProjectOutputDirInsideProject)”>$(OutDir)_PublishedWebsites\$(MSBuildProjectName)</WebProjectOutputDir>

TargetYou need a new targets file         

In order for our console application to copy its files to its own output folder, I wanted a .targets file for applications, not web sites.

There isn’t one out of the box, like there is for websites. So we need to create it. Fortunately there’s a shortcut; I call it Ctrl C, Ctrl V. seriously… make a copy of the WebApplication.targets file. Place it inside your solution file structure and name it something different, like Application.targets, for instance.

Next make two amends:

In the file find, <WebProjectOutputDir Condition=”!$(WebProjectOutputDirInsideProject)”>$(OutDir)_PublishedWebsites\$(MSBuildProjectName)</WebProjectOutputDir>

Change the name of the output folder, to _PublishedApps, for instance:

Find <WebProjectOutputDir Condition=”!$(WebProjectOutputDirInsideProject)”>$(OutDir)_PublishedApps\$(MSBuildProjectName)</WebProjectOutputDir>.

Inside <Target Name=”_CopyWebApplication”>, add: <Copy SourceFiles=”$(OutDir)$(TargetFileName).config” DestinationFolder=”$(WebProjectOutputDir)\bin” SkipUnchangedFiles=”true” />

The first is just a change to the directory name where files should be output too.
The second is a change to help it copy and rename the app.config file.

The final part of the puzzle is to amend your console app project to use the new .targets file.
Open the project file and immediately before the <target name=”beforebuild”> section add:

<Import Project=”..\build\Application.targets” />

Getting the relative path to your targets file correct. Save it all, check it all in (inc. the .targets file) and you should get a new output folder in your drop location, specifically for your console application’s files.

Written in August 2015, using TFS 2013 and Visual Studio 2013.

Image credit: Flood G