User Story - A Promise to have a conversation

 
Time and again it is important to constantly remind your team that a User story is not just a way of defining a requirement but is actually the premise on which you promise to have conversations with the user. It is by no means a finalised description of what the system should be doing. The first time it is written the analyst or product owner only has as much information as the user gives them. This information is pretty much raw most often a wish list off some post-it notes on the edge of the users monitor. It will have information of what the user wants to achieve or the grand plan of how something could be done brilliantly to save money or achieve a business goal. It will not tell you what the user wants the system to do.
This is where collaboration is fundamental to the idea of agile development ( should i say ADD – Agile Driven Development). The user story is to be evolved by having conversations between various functional experts. By functional experts I mean a QA, a developer, a business analyst or even a UI designer for that matter. The question is why? I guess it’s because these functional experts can think of the software that is to be built with a view of what the system should do, A user story should convey both what the user wants to do and what the system will do to be complete, clearly the initial draft of these stories didn’t do this.

When a developer evolves a story on his own he is going to make sure it is technically brilliant (may be not always) and eventually forget what the user wants , in most cases this conversation ends up in the developer trying to define what the system should do and what the user wants..  how many over engineered systems have we not seen and been part of in the past

When a UI designer is going to evolve it on his own he is going to make sure it is pretty software and most likely to make it usable but with lack of clarity of the functionality that the user really needs, he just has his wireframes or prototypes, which shows the user the dream he wants to have

When a QA is going to evolve this on his own he is going to make sure it is very testable, infact so testable that they start defining behaviour of the application and the implementation of the software even though they may or may not match what the user wants.. oh well make it testable but so testable that the stuff you build is not usable.

The analyst on the other hand is so caught up with making sure he conveys what the user wants he forgets most often how to test the functionality or in some case forgets to tell the team what the system should do  , well don’t blame him they are not the functional experts on the technical implementation of a system

We have seen these things happening all the time, any form of methodology without collaboration kind of summarises the situation in which these things happen. Alright then, so we can’t do without collaboration so what now and how far do we go with collaboration? How do we know where to stop, well I am going to have to be vague and say well it’s for the team to figure it out in the context of the system they are working but then, I guess some of the answer lies in the ability of the team and the user to work towards coming up with stories which adhere to INSPECT and the story itself becoming the documentation of the system.

As Gojko says in his book “Specification by Example” stories evolve into living documentation of the system. When you can actually read a story and express in simple English, the aspect of what the user wants to do and what the system is doing to achieve the users need, you could say you have reached that point where you can stop and move on to the next bit of functionality.

Again living documentation is not written once; it evolves over a period of time by refactoring constantly; Teams that collaborate constantly recognise this need to bring the stories used to build the system in line with the domain concepts in the system, and vice versa, it is a constant cycle of refactor and improve.. Oh should I say iterate and continuously improve... Rings a bell... Agile?. In reality, collaboration is under-rated by teams and it is something teams think they should do because it needs to be done. Most agile teams do this once for every story (I am laughing already) while estimating the story not so much while actually implementing it. That said there are also teams which constantly collaborate. I guess question is which team are you working in and what are you going to do about it ?

Screw Unit – Teamcity Integration

I had to setup up client side tests to run for my team on Teamcity. I initially thought I should use rake to do this, but then I had to leverage the fact that my team is comfortable with the .Net stack and not so much with Ruby. At this point I just thought i should use a unit test to run my screw unit test via Watin in a browser. This idea is available in a lot of other blogs for QUnit tests. The unit test opens the suite.html , parses the file and reports if the test failed or passed.This works fine. But then when a test failed I had to either look at the logs of the build or had to navigate to the Url, this feedback was ok but not great

I tried to write a teamcity test runner for screw unit which will send messages to TeamCity , but this was hard work and the effort involved was simply too much

If not real time feedback from a test runner, at least seeing the suite.html as a tab on my build would be good.. so I just pushed the artifacts for the build to include the Screw Unit test pack and set up a new tab in TeamCity server config file (main.config file) called Screw Unit Report. This tab would open the html file for the tests from the artifacts. So now I have TeamCity showing the Screw Unit suite as a tab, that's better, the only thing is when you click on the tab it runs the tests every time, but that's not such a big deal really . The effort involved in setting this up was 30 minutes. (I already knew how to setup tabs in TeamCity )

So to summarize

1. Write a unit test runner which will use Watin to open the Screw Unit test suite.html file.

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Diagnostics;

   4: using System.IO;

   5: using System.Linq;

   6: using System.Threading;

   7: using MbUnit.Framework;

   8: using NHamcrest.Core;

   9: using WatiN.Core;

  10:  

  11: namespace Tests

  12: {

  13:     [TestFixture]

  14:     [Timeout(600)]

  15:     public class TestRunner

  16:     {

  17:         private FireFox browser;

  18:  

  19:         [SetUp]

  20:         public void SetupBrowser()

  21:         {

  22:             browser = new FireFox();

  23:         }

  24:         /// <summary>

  25:         /// Tests that ScrewUnit tests pass

  26:         /// </summary>

  27:         [Test]

  28:         [Category("ScrewUnitTests")]

  29:         public void RunAllTestsFromSuite()

  30:         {

  31:             var screwUnitTestFile = Path.Combine(Environment.CurrentDirectory, @"Javascript\ScrewUnit\tests\spec\suite.html");

  32:             browser.GoTo(@"file:///" + screwUnitTestFile);

  33:             browser.WaitForComplete(5000);

  34:  

  35:             var resultsDiv = browser.ElementWithTag("h3", Find.ByClass("status"));

  36:             resultsDiv.WaitUntil(() => resultsDiv.Exists && !resultsDiv.Text.ToLower().Contains("Running"), 30000);

  37:  

  38:             AssertThatTestsHavePassed(resultsDiv);

  39:         }

  40:  

  41:         private static void AssertThatTestsHavePassed(Element resultsDiv)

  42:         {

  43:             var resultsArray = resultsDiv.Text.Split(new[] { ' ' });

  44:  

  45:             var numberOfFailures = Int32.Parse(resultsArray.ElementAt(2));

  46:  

  47:             Assert.That(numberOfFailures, Is.EqualTo(0), string.Format("{0}. Click on the Screw Unit Report Tab to see the details", resultsDiv.Text));

  48:         }

  49:  

  50:         [TearDown]

  51:         public void TearDownTestRunner()

  52:         {

  53:             browser.Dispose();

  54:             Thread.Sleep(2000);

  55:             var browserProcesses = Process.GetProcesses()

  56:                     .Where(process => process.ProcessName.ToLower().Contains("firefox") && process.StartInfo.UserName.ToLower().Contains("build"));

  57:                     browserProcesses.Each(p => p.Kill());

  58:         }

  59:        

  60:  

  61:     }

  62:     public static class Extensions

  63:     {

  64:         public static void Each<T>(this IEnumerable<T> collection, Action<T> action)

  65:         {

  66:             foreach (var item in collection)

  67:             {

  68:                 action(item);

  69:             }

  70:         }

  71:       

  72:         public static void WaitUntil(this Element element, Func<bool> predicate, int timeout)

  73:         {

  74:             var startTime = DateTime.Now;

  75:  

  76:             while (!predicate())

  77:             {

  78:                 Thread.Sleep(1000);

  79:                 var now = DateTime.Now;

  80:  

  81:                 if ((now - startTime).TotalMilliseconds > timeout) throw new TimeoutException("Timed out waiting for condition to become true");

  82:             }

  83:         }

  84:     }

  85: }

2. Push the Screw Unit test suite into the artifacts of your build in the team city configuration of your build

3. Configure the main.config file located at <TeamCity Install Folder>\.BuildServer\configuration\confg to create a new tab.

Run your build and you should be able to see the screwunit report on the build server now

   1: <server>

   2:  

   3: <report-tab title="Screw Unit Report" basePath="ScrewUnit.zip" startPage="tests/spec/suite.html" />

   4:  

   5: </server>

   6:  

You could use the screwunit test sample i took from git hub to test this Screw Unit Tests sample

Step by Step - Cucumber, WatiR and Ruby installation tips

There are few road blocks you hit when you go about the process of installing Cucumber, Watir and Ruby the first time, you have to search all the information and then as you install there are some things that work while some dont , I just thought it may be a good idea to consolidate the information in one place for myself if i do run into this situation of having to install this again. I have tried and tested this thrice and use the same process to install our test agents.

• Installing Ruby

#Tip – Choosing the version of Ruby installer

Watir is stable with Ruby 1.8.7 so dont carried away and install 1.9.x of ruby , you learn the hard way that it is not going to work properly.

See Http://watir.com/installation for updates on when 1.9.x support will be provided. Go to http://rubyforge.org/frs/download.php/74293/rubyinstaller-1.8.7-p334.exe download the exe and run the installer. I chose the installation folder to be called just ruby as I want to avoid installing multiple versions for now.

 

• Ruby Path

Check if "c:\ruby\bin" is included in the path (else run PATH=%PATH%;c:\ruby\bin at the command prompt)

• Installing the Dev Kit for Ruby

Download http://github.com/downloads/oneclick/rubyinstaller/DevKit-tdm-32-4.5.1-20101214-1400-sfx.exe .

1. Click on it to extract files to a folder <DEV-KIT-FOLDER>.
2. Open a command prompt for the <DEV-KIT-FOLDER>.
3. Run the command “ruby dk.rb init”
4. Run the command “ruby dk.rb install”

Not sure if you need this but run a “gem update system” and it should say Nothing to update :).

• Installing gems

Now at the command prompt

1. Run “gem install cucumber”.
2. Run “gem install watir”
3. Run “gem install “win32console”
4. Run “gem install rspec”

• Installing ANSI con – if you are unable to see colours on your console window when you run a cucumber feature, you may need to install ANSICON

1. Go to http://adoxa.110mb.com/ansicon . Download AnsiCon 140.
2. Extract the files.
3. Open a command prompt for the folder you have extracted the files in
   cd to x64 folder if you use a 64 bit machine or x86 folder if you use a 32 bit machine
   type "ansicon.exe -i"
   Close the command prompt , open a new one

This should be sufficient to run cucumber features now. In a weeks time I will post a project framework with some useful stuff for ruby / selenium / cucumber which can be downloaded so you can go about building tests quickly

ScrewTurn Wiki

I was looking for a some kind of ASP.Net sample site purely to demo some BDD scenarios at work, but then I wanted to do it on a site which is more complex than the usual ASP.Net sample site made of Customer/Order.

I found a couple of Wikis, but the one that caught my eye was ScrewTurn Wiki. First things first it is free under the GPLv2 license (for more details on commercial licenses see Commercial License Help)

The installation took less than a few minutes using the Microsoft Web Platform installer, You install the Wiki in one of two modes file system storage mode or SqlServer storage mode (just use SqlExpress). To choose which mode you want to install. See Installation Help for more details. Apparently you can go with file storage mode and then switch to the SqlServer data storage mode later (Data Migration)

The fact that you can manage the ScrewTurn Wiki using Microsoft WebMatrix is simply brilliant. The ease of use and ability to be able to publish the Wiki is simply useful. You can pretty much configure your hosting details if you wanted to host something on the internet and keep pushing your changes.

Now for Plugins, quite a lot of them seem to be available. There are vast number of navigational, text editing and data provider plugins. In addition to this you can customise different portions of the Wiki using your own providers , this seems like one of those things that was given a great deal of thought. See Custom Providers

I guess I am very impressed by what the Wiki offers, but looking at the features I am actually wondering if a product which was a Wiki is evolving into a CMS? Not sure, cant say I am bothered either, the only reason I raised that concern is the Wiki as is, is pretty simplistic and this is what appealed to me, building too much into could make it bulky and complex. I am just a developer so I cant give an accurate view of what users of the Wiki would want. On the bright side there are some really new features that are coming and that can be leveraged. V4 CTP offers native Azure support which should be good if you wanted to use Cloud based services I guess. See Roadmap for more details

DDD eXchange 2011 Podcasts

Attended this conference on Friday (10/06/2011) and was consolidating the links for the podcasts

Some of my favourites are

• · Greg Young on Assert.That(We.Understand) – related to TDD
• · Udi Dahan on Domain Models and Composite Applications
• · Jim Webber on REST and DDD - REST based APIs
• · Matthew Wall on REST & APIs in the Guardian's DDD Processes

Podcast Links

• Eric Evans on Welcome to DDD eXchange
• Jim Webber on REST and DDD
• Udi Dahan on Domain Models and Composite Applications
• Patrik Fredriksson on DDD in a Functional Programming Language
• Greg Young on Assert.That(We.Understand)
• Matthew Wall on REST & APIs in the Guardian's DDD Processes
• Eric Evans on Keynote - DDD Strategies for Moving Away from Legacy Systems

The N+1 Iteration syndrome

I constantly ask myself if i know what is next at the end of a sprint or iteration and that I should make an effort to know what is coming up next, I observe that just like me the members of the team are only focussing only on the card that there magnet is on in the current iteration. Adapting to a constant flow of user stories and requirement is not easy for any team and is as important as focussing on the stories in the current iteration. We as a team focus on the user stories in the board, but it may be worthwhile asking ourselves how many people in the team are really aware of what is coming up in the next iteration. If members in the team were asked to answer to this question honestly you will find that a vast majority probably don’t have much information or are totally ignorant. I prefer the term N+1 for the next iteration. In most teams I have worked this is a problem that is evident in one form or the other and some common symptoms I find are the ones mentioned below.

Symptoms

• Analysts find it frustrating that they have to repeatedly read the story out and explain the same story more than a few times.
• Team velocity sways massively and the standard deviation to average velocity is quite high
• Requirements workshops are almost absent and it seems like analysts are in a different time zone on the user requirements on most occasions when compared to the team.
• Team members are not sure about the size of the story and try to come up to a size as close as possible to the rest of the team rather than putting any effort involved in understanding the size of the story.
• Constructive discussions, debate and any implementation concerns are almost absent
• The team seems to easily agree on the size of the story and gets swayed into a conclusion by anyone who can speak the team into a conclusion
• Large stories seem to be finished earlier than they ought to be and some of the smaller stories seem to take more time and some times end up looking like large stories.

This syndrome manifests itself in different ways and consequences range to varying degrees of severity on the functioning of an agile team. The team should address this situation if they do find these symptoms, the effects of not addressing this problem could result in false velocities, skewed metrics, increase in cost of the project and finally manifests itself in a loss of trust from the users for whom we actually work on the project. I wonder if I am making a big deal out of this, but this may be because I perceive the consequences of this syndrome to grow exponentially into bigger problems and can be quite damaging for the future of the team and the project.

We can mitigate some of these symptoms, a few ideas that allow you to improve and move in the right direction are below

• Introduce a N+1 sprint section on the left and side of your Kanban or sprint board and line up stories that will flow into the next sprint.
• Encourage analysts who are working on N+1 Q to speak about there analysis during your stand ups, this helps spread awareness of the N+1 iteration on a daily basis. Truth is in an iteration the analyst is probably working 50% of their time on the N+1 sprint and the other current sprint.
• Encourage your team members to pair with analysts and discuss and learn what they are working on, if you can allow your developers and QAs to pair for 5% of the iteration on a rotational basis with the analyst. These pairing sessions really helps non technical analysts to learn a few tricks and understand why you would think the story is complex or simple
• Have mini 15 minute sessions every day after the stand up to pick up one story from the N+1 board and discuss with the analyst, testability and implementation details. This will mitigate the loss of requirements workshop they are long and can be boring anyway , small cycles of these sessions will get the team to be constantly involved in requirements.. the term cross functional teams was not coined just for developers and QAs , it did mean all functions in the project.
• Have some ground rules for your planning session,
  • Team comes attend the planning session with an awareness of the stories flowing into the Kanban,
  • You really don't want estimating to eat up all your planning time, clearly planning is not only to estimate it is also about discussing priorities and setting goals for your iteration, spend some time planning how you would action retrospectives as well.

You will see that the team will at least loose the perplexed “I don't know what you are talking about look “ and the “I cant be bothered” attitude , this could be a good starting point to address the problem. This will allow your team to be more involved in planning as much as they are involved in the progress of the sprints.

Authoring and Automating - User Stories

In most agile development teams the responsibility of writing user stories falls into the hands of the analyst. The analyst not in all cases may be well versed with the idea of writing stories. This is not because he does not know what to write but sometimes because he does not know the best way to express the story in the chosen story writing platform. This doesn't warrant a developer to pair with an analyst to author a story, In my opinion developers are not welcome to pair with the analyst to author user stories. Allowing this will allow implementation detail to find its way into the stories and sometimes they dictate the users intention.

Authoring stories

The best person for your analyst to pair with should be your QA, this proves to be the most useful.

• The QA looks at a story early in the life cycle and ensures all aspects of the story are testable.
• The ownership of the story is with the QA and he/she is able to identify any automation concerns of the story..
• Any scenarios that have not been through in a story due to data related anomalies are identified.
• The QA is involved in this process early on before the iteration in which the story is picked up , this will allow the QA to bring in some valuable information on the size of the story to the planning session.
• Since the QA gets an understanding of the story before a developer is involved his view of the story is as close as possible to the users requirement in the story. This important to make sure the intention of the user is not skewed by the understanding of a developer.
• The QA is able to identify any smoke tests that may be required to be run when a release is deployed to UAT or Live.

Automating stories

In our current project our QA starts automating user stories when he runs out of stories to test. In most cases the QA to dev ratio is 1:2 or 1:3 and so the QA gets bogged down with implementing acceptance criteria so the team has enough stories to dev on. It helps for devs to pair with QAs to automate acceptance tests and my observation has been the following

• On a normal day we developers are more in sync with writing better code than QA’s, developers can always help in writing better test code.
• When developers implement the acceptance criteria in the form of Given When Then, they actually are implementing the story itself.
• Developers will get an idea of how to implement the story and tests required when they actually develop the story.
• Where the story is looking for new elements on the UI, developers can aid in mocking the UI for the story else automating all the steps of the user story could be a night mare for the QA all on his own.

PS : My Selfish reason - Developers learn a new language .. I learnt ruby this way :)

In effect when three different people with different skills are involved in the authoring and automation of the story, this will ensure a lot more analysis happens and more often than not edge cases are discovered ahead of development. Any edge cases which will increase the cost of the story can be identified and a decision made taken if they have any real value in development.