Archive for June, 2011


Why? Because it’s shit  just not appropriate nowadays.  The tools available have moved on. Get over it. There is better. Visio is like giving a graphic designer Microsoft Paint and rather than Photoshop. Giving a developer MS-Basic for DOS, or giving a starving dog a rubber bone.

Quite apart from that, the whole mindset of using Visio is wrong. Visio is a drawing tool. But as Analysts, we should be creating models, not drawings. And we should be creating models that get built on added to and improved over time, by everyone. Not one-off drawings that get thrown away or left to rot unlooked at on a shared drive somewhere.

There are plenty of excellent and reasonably priced CASE tools out there with incredible capabilities. And plenty of work justification and evaluating them has been done perfectly well elsewhere. Even re-reading your first semester university notes would probably give excellent justification of why you should be using a CASE tool rather than a pile of crap like Visio. (This does assume you studied a computer-related subject – if you studied geography you might find information thin on the ground). You nodded in agreement when the lecturer explained it to you then, so why not put it into practice now?

Ditch Visio and move on. Period.

I am coming round to the idea that Microsoft Word should also go.

Once again I find myself on a ‘challenging’ project which is so not because we are trying to do anything new or demanding in terms of requirements, but simply because we want to carry on pretty much as we are. Trouble is what we ‘do now’ needs to be dragged out of people, and the customer – not unreasonably – thinks we should know it all anyway.

On the wall not too far from where I sit at work there are two charts.  One illustrates the process we are supposed to follow for waterfall projects.  The other illustrates the process we are supposed to follow for agile projects.

Both look pretty much the same.

Admittedly, I haven’t looked at them in detail.  At the moment I am too busy working on things that seem to be neither waterfall or agile.  But I am sure people in the agile community would have alot to say about my observation.

I’ve written much on these pages and bored many people at work over drinks about my views on agile and waterfall.

In my view, agile ought to be a fundamentally different approach to financing a project.  Because if it isn’t, all you really have is a waterfall project but with different ways of reporting progress. There is no real opportunity to change or influence things during the project because you are locked in to what was negotiated upfront in order to get the money. Fine if you’re having your guttering replaced, but not much good if you are working on a complex software development. My previous post explains it further.


The agile debate over the last 5 or so years has really amounted to a rather repetitive in-fight within the technology industry between two factions – ‘waterfall’ people and ‘agile’ people. That is a shame because the real battle lies elsewhere.


Over to you, Messers Beck, Cohn, et al. Or anyone, really.

I have been thinking again about what constitutes a good User Story.  In doing so I thought I would summarise a few of the main issues to consider.

Beginnings

A User Story is a short, simple description of the capability of a system told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template, and traditionally this was “As a [role], I want [a desire] so that [there is a benefit]“. Dan North has a good article on the principles.  Here is an example from his article.

As an Account Holder
I want to withdraw cash from an ATM
So that I can get money when the bank is closed

This format was also famously presented in Kent Beck’s book User Stories Applied. More recently, attempts have been made at altering the structure of User Stories so that the business benefits are described first. We will see that in a second.

Behaviour-driven development (BDD) uses a story as the basic unit of functionality, and therefore of delivery. The acceptance criteria are an intrinsic part of the story – in effect they define the scope of its behaviour, and give us a shared definition of “done”. They are also used as the basis for estimation when we come to do our planning.

This all seems fine.  Nothing unreasonable here.  Or is there?  What if pulling the stories together to do the estimation might turn out to be a big piece of work in itself? Who approves that? And what happens if you don’t have the knowledge to produce the stories? What happens then?  Beck doesn’t offer any guidance.  The assumption is that you will never encounter this problem.  There are always people around that have the knowledge.   Sadly, this utopia isn’t always the case.

We also have the notion of a ‘Feature’. The IEEE describe a ‘Feature’ as a ‘characteristic that describes a software system’. I’ve no doubt there are other definitions that talk about business value, but lets just assume that the feature must be deemed worthwhile by someone.

Features != User Stories

A feature will encompass a number of User Stories.

As Matt Wynne brilliantly puts it, “User Stories are a great way to plan your work.  You can break down a big hairy requirement in to chunks that are small enough to work on without anyone freaking out”.

Having broken things down into chunks, we can pick and choose which ones to do first, and we may even find that some aren’t that important and could be dropped altogether. Our Feature might be

Specify delivery options for an order

and could give rise to this User Story. We have written it such that the benefit is described first:

In order to have my order delivered
As a customer
I want to specify my delivery preference

There are potentially many options and alternatives for arranging delivery. The analysis starts to suggest that there could be huge variations in the time and complexity involved in these options. So we split the story down:

One for standard delivery using royal mail:

In order to have my order delivered
As a customer
I want to specify standard delivery by Royal Mail

One for premium delivery where the user can specify a 2 hour delivery slot:

In order to have my order delivered at a specific time
As a customer
I want to specify premium delivery and choose a delivery slot for my order

Creating a system to handle 2 hour delivery slots is very much more complex than booking via Royal Mail. So we leave this until later.

We could break this down even further and add more user stories.  But we avoid the temptation to treat every User Story as a feature.  I’ve made this mistake myself.  Say we add a third User Story months later:

In order to have items within my order delivered in the fastest time
As a customer
I want to specify that my order can be broken into separate deliveries

What we don’t do is add an additional file for the new story and end up with a bunch of files like this:

features/
delivery_by_royal_mail.feature
two_hour_delivery_slots.feature
express_delivery.feature

The stories that make up the feature should all be added to a single feature file

Specify_delivery.feature

which we enhance and add to*.

* This assumes you are using the Cucumber testing framework, but even if you are not, it is still good practice. And you may ask where Microsoft Word and Microsoft Excel fit in to all this – and the answer is nowhere. They are just flat files.

Feature Injection

As we said at the start, the traditional way of writing User Stories was to follow this structure:

"As a [role], I want [a desire] so that [there is a benefit]"

Later, there was a move towards a slightly different structure whereby the business benefit could be expressed more explicitly. Chris Matts devised a technique called Feature Injection which our examples above follow. The principle is that by moving the elements of the story around we can force people to think about the problem in order of the business value first, then the stakeholder value, then what the stakeholder thinks will deliver the value.

Example:

In order that PrintCo printer cartridge sales go up by growing the mailing list
As a PrintCo Customer
I want to be prompted for my e-mail address
So that an e-mail reminder can help me avoid those times when I need to print something but the ink is empty

As the analysis progresses, this might extend into:

In order that PrintCo printer cartridge sales go up by growing the mailing list:
As a PrintCo Customer
I want to be prompted for my e-mail address
So that an e-mail reminder can help me avoid those times when I need to print something but the ink is empty


As a PrintCo Customer Services Rep
I need [something]
So that I increase the points I get for e-mail captures, improving my position on the high-scores display


As a PrintCo Customer Services Rep
I need [something]
So that I can see that the points I earn for e-mail captures affect my position on the high-scores display

I am not suggesting this is easy to do by the way.

A word about the scenarios

Having defined the User Stories, we then move on to define the scenarios. This is really a subject for another post, but I wanted to point a couple of things out specifically.

We write the scenarios in this form:


GIVEN (There we are in a certain situation or something has happend)
WHEN (I do something)
THEN (There is an outcome)

GIVEN-WHEN-THEN doesn’t imply there is a positive ‘benefit’ for the recipient or person carrying out the scenario. Also, it might come down to a question of viewpoint.  Not allowing something to happen, might be a  negative outcome for one role or user but a positive outcome for another.

Example:

Scenario 1: Account balance is negative
Given the account’s balance is below 0
And their is not a scheduled direct deposit that day
When the account owner attempts to withdraw money
Then the bank will deny it
And send the account owner a nasty letter.

Or we might have something like

Scenario: Deleting a facility house booking on an Order
Given an Order has been created
And the Order has been submitted for processing
And a line on the Order has been booked for a Facility House
When I navigate to the Facility House Booking
And I cancel the specific Booking
Then a booking cancellation is sent to the facility house

The issue with scenarios is that to uninitiated, it isn’t clear what is going on. How do you Create the order? How do you navigate to the facility house booking?

The BDD gurus will either say:

“It’s fine.  Look in the implementation code of the automated test”

or

“Ask your Business Analyst.  They will know”.

The problem is that if you live in the real world, its just not economic to automate everything.  And if you’re not able to, Given an Order has been created is a big deal because the steps involved in doing it might be very long and complicated and would somehow need to be included in the scenario. (Or if not, then documented by another means). I wrote about some of the issues around this previously here.  It is a topic I will return to, for sure…