Mar 15, 2012

What do I do With Partially Completed Stories in Scrum?

It’s not that rare an occurrence for a scrum team to get to the end of a sprint and find that they have one or more stories that don’t meet the definition of “Done!”.


This week from one of my former Professional Scrum Master students asked me about this situation:

”What should we do with un-done work at the end of the sprint?
I was thinking we have two options:
1) Move the user story to the backlog for re-prioritisation (maybe into the next sprint).  The problem here is that I’m not sure what to do with the story points as it screws up our sprint velocity
2) Split the user story.  In this case we would leave the old user story’s points as-is, then create a new user story with the remaining work and re-estimate with planning poker.
I was reviewing the scrum guide and it doesn’t seem to have any details in this area.”


The lack of detail in the scrum guide should be enough indication on the approach to take. If the scrum guide doesn’t talk about splitting stories then it’s probably reasonable to assume you shouldn’t do it :-)

Putting the story back on the backlog for reprioritisation.  Sure, you won’t get any credit for the story in the current sprint because it’s not done, but it won’t screw up velocity either because velocity will be a true reflection of what you actually delivered during the sprint.  We want velocity to measure our rate of delivery not our effort. On average, over a number of sprints the velocity figures will average out in any case.  So yes, you may well have a few peaks and troughs when looking at single sprints but looking across the last 3 to 5 sprints you should have a good reflection of your actual rate of progress.

Not having a story finished and getting no credit for it also gives the team something to talk about during the retrospective. “Why didn’t we get to ‘done’ on story X?”.

On the flip side, I don’t like splitting incomplete stories because

1. it gives teams an “out” for not finishing properly and they get credit for effort not delivery. It stops them pushing for a goal and stymies the inspect and adapt process.

2. how do you actually split the story that was almost finished?  Can you split it in such a way that the work that was “almost” finished meets the “done” definition?  Can you do it in such a way that your product owner is absolutely sure that the completed part of the story is Done and that their acceptance criteria are satisfied? Can you cleanly separate the business value delivered between the completed part and the incomplete part? I doubt it.

Taking an incomplete story and splitting it just to make it look like you have a stable velocity reduces transparency and hides the truth of what you can actually achieve from your product owner, your stakeholders and most importantly yourselves.  Don’t do it.

Mar 4, 2012

The Visual Studio 11 Interface, With More Metro

Without getting into the “It sucks! No, It rocks!” debate about the new user interface there are some areas that people are particularly fired up about, including the use if colons as a placeholder for menu bars.

On the Visual Studio User Voice site there’s a request to tweak the UI and go “all in” with the Metro styling borrowing from the Zune interface (an interface I happen to particularly like).

Let’s have a look at the current UI as posted on the Visual Studio teams blog entry Introducing the New Developer Experience:

Now let’s look at the proposed user interface with it’s makeover (via

Not to be left as the sole alternative, here’s a slightly different take on it (via

I’m not campaigning for votes for the feature (and at this stage the UI is going to be mostly set in stone in any case), but what I do want to do is point out that a consistent focus on the Metro design principles makes a difference.

If you go Metro, go full metro, not some halfway house. The alternate user interfaces work in that they remove as much window chrome and scroll bar noise as possible, letting developers focus more on the content and they realise that if typography is king, then make typography king!  Fix menu fonts, title fonts, and so forth and be consistent about it.  By improving the typography they also managed to retain the shouty tab names in such a way that they don’t grate anywhere near as much as the current UI does.  The UI also feels cleaner because the ::::: lines aren’t there adding unnecessary noise.

It’s interesting to see how much of a difference the Metro design language can actually make to a user interface, and definitely something to consider if you get asked by your users to create a Windows 7 or desktop application that feels like a Windows 8 Metro style application.

How To Unit Test Async Methods with MSTest, XUnit and VS11 Beta

MSTest finally got some love with the Visual Studio 11 Beta and one of those changes was to enable tests to run asynchronously using the async and await keywords.

This is required if you want to write tests against any async methods (especially with WinRT!) but can also be used anywhere else you need to perform asynchronous operations.

Here’s a silly sample test to show you how it’s done

public async Task LoadGoogleHomePageAsync()
    var client = new System.Net.Http.HttpClient();
    var page = await client.GetStringAsync("");
    Microsoft.VisualStudio.TestTools.UnitTesting.StringAssert.Contains(page, "google");

XUnit also supports this option as shown here:

public async Task XUnitAsyncTestMethod()
    var c = new System.Net.Http.HttpClient();
    var result = await c.GetStringAsync("");
    Xunit.Assert.Contains("google", result);

Be aware that if you have a testsettings file specified in the Unit Test Explorer that async tests will not work.  This applies to the beta only.  Apart from that everything works as expected.

Mar 3, 2012

Git-TFS Presentation at the 2012 MVP Summit

The day before the 2012 Microsoft MVP Summit kicked off in earnest there was an MVP-to-MVP day. For those of us in the Visual Studio ALM area we had a day long series of lightning talks about all sort of TFS related subjects, making for a good and wide-ranging day.

For something different, I did a talk about git and TFS integration and how git-tfs can be used to hide many of the problems with TFS source control.  Below is a slightly modified version of the slide deck I used.

I hope you find it useful.

Improved Unit Testing with Visual Studio 11 Beta

imageThere’s just so much new stuff in the Visual Studio 11 Beta! In fact, someone should write a book about it… Oh wait, I am! (more on that when the time is right). For now, let’s have a look at one feature that makes me so very happy: Visual Studio’s new and improved unit testing capabilities.
It’s widely recognised by those with a desire to do unit testing that there are better unit test frameworks out there than MSTest but given that Visual Studio has always been so tightly coupled with MSTest it’s always been more difficult than it should be to get other test frameworks working well in Visual Studio.  The TestDriven.NET and ReSharper test runners have helped, but the integration back to visual studio was always lacking.
That all changes with the Visual Studio 11. Now it’s a case of “Use the framework that makes you happy. We don’t mind”.
You want to use XUnit? No problem!
NUnit? Easy!
MSTest (without the baggage it usually has)? Sure thing!
QUnit for JavaScript? Bring it on!
Something random that we’ve never heard of? Write an adapter and it’ll work just fine!

Dogs and Cats Living Together!

Visual Studio 11 introduced a test adapter model so that any test framework can run inside Visual Studio if there is an adapter for it.  The adapter model also means that you can not only run XUnit, NUnit, or any other type of test but you can run them in the same test assembly if you really wanted to! Why? I don’t know! But you can :-)
Maybe you have a suite of MSTest tests but you also want use XUnit’s data driven test features because MSTest sucks for unit testing. You can do just that.  It’s really nice.
Note: In MSTest’s favour, in this release when MSTest is used in a plain old class library for unit testing the MSTest test adapter uses a cut down, light weight version of MSTest with just the features needed for unit testing and none of the baggage that it normally comes with, making it quite usable for most unit testing needs. For most developers with an existing investment in MSTest tests they will see an improvement in performance as a result.


Get yourself started by loading the appropriate adapter for your unit test framework from the Visual Studio Extension Manager.  MSTest is already in the box so you don’t have to worry about that one.  In this screen shot I’ve loaded up the XUnit, NUnit and Chutzpah test adapters.

Running Unit Tests

Create a new C# Assembly project (NOT a test project) and add the XUnit and NUnit test frameworks to your project using NuGet
You can also add a reference to Microsoft.VisualStudio.QualityTools.UnitTestFramework so that you can do MSTest based unit tests.
Here, I’ve started by adding a simple XUnit test, then building the code and running the unit test as shown:
As you can see in the output window there is now a “Discover test started” phase where Visual Studio looks at the assemblies and determines what tests are in the system so that it can spin up the right framework and execute the tests.
The Unit Test explorer on the left shows the tests that were run, the time it took and any error information for failed tests.
In the same code I have then added MSTest and NUnit tests as shown, however at this stage I have not yet built the project – take note of the unsaved changes icon in the document tab, indicating that the project is neither saved nor built as yet:

Run Tests After Build (Almost Continuous Testing)

Continuous Testing is the idea that as you do your work all the unit tests are constantly running in the background and giving you live feedback when there are problems code by highlighting where tests have failed and where your code is broken.  The immediate feedback cycle makes test driven development an even faster development process since there’s no waiting around for all the tests to run.
Visual Studio has taken a step towards this ideal with the “Run Tests After Build” option as shown in the image below. Turn that setting on and as soon as you compile your code Visual Studio will run the tests automatically on a background thread so that you don’t end up with a blocked UI and can get on with coding the next thing on your list.
If a test failed the unit test explorer goes red and it’s obvious that there’s a problem.  The interesting thing is that in smaller projects the tests often run so fast that you don’t even notice them happening!
As a tip, once you’ve been using the test after build feature for a while you will probably want to stop the Output window from popping up every time you build so that you don’t have to keep closing it.  You can do this in the Visual Studio Options as shown

Don’t Forget JavaScript Unit Tests!

OK, I won’t.  Make sure you have the Chutzpah test adapter Visual Studio extension installed (see above).
In a standard web project include QUnit or Jasmine in your project and then create a JavaScript file for your tests.  Once you have your tests written run them as you normally would and Chutzpah will do the tricky work of finding the tests and running them.  Here’s a screen shot of a web project with a QUnit test in it


So there you have it! A brief overview of the new unit testing features in Visual Studio 11 Beta. Go and get it now and start playing with it.
Having Visual Studio automatically running your tests each time you do a build will change your development workflow for the better and keep you more focused on coding and help you stay in the mythical zone if you ever get there.
Remember that since all tests run in the background and this removes the time spent waiting for tests to finish that you can have tens of thousands of tests taking minutes to run each time and you won’t even feel a delay in your development activities.  Fantastic!