Liz Keogh's blog

Reading Simon Baker’s post on metrics made me smile. I rant about similar misuse of metrics quite a lot. A common reason that I see targets and metrics fail is because they’re aimed at a perceived circle of responsibility – for instance, developers who are measured on how few bugs they produce. This ignores the possibility that something outside of the development team might be causing the bugs – poor analysis, a difficult technical environment, lack of a decent production-like staging platform, etc.

Simon’s post calls out another common local optimisation. He says, “…the true purpose of the people doing the work, which is to improve service and quality and satisfy users.”

One of the ways in which we can satisfy users is through usability and user experience. At one of the Agile 2009 keynotes, Jared M. Spool gave a beautiful example of why this could be a bad idea. He talked about a company that had reduced a 5-stage process to 2. The users loved it. “Unfortunately, they forgot that the company was paid per page impression,” he said. The company went bankrupt shortly after putting the beautiful new website in place.

In Feature Injection, Chris Matts calls out the people with the original idea, or the people who are investing in the idea, as the core stakeholders. These are the people who need to be satisfied. Everyone else is incidental, and the vision is usually one that either makes money, saves money or protects money (stops another company spoiling your idea, or stops them from stealing your market share). Everyone else whose input is needed to make the vision a success is an incidental stakeholder. This can include the users.

Here’s an example of how focusing on the true stakeholder can help. I was talking to a friend at XtC about a user-centric story.

As a user
I want register to be emailed when the game is released
So that I can buy it as quickly as possible.

I was discussing alternative ways of implementing this story which didn’t involve email. “Who really wants the users to be notified? Who’s actually paying to notify them?”

“Marketing, I guess.”

“Why do Marketing want the user to be emailed?”

“So that they can make a big hype about the game when it’s released.”

So, rephrase this from Marketing’s point of view.

In order to make a big hype about the game when it's released
As Fred, the Marketing guy
I want users to register for an email about the release.

Now we can see that perhaps, users may not want to register for the game. We might have to entice them with something else. We also see that our goal – the big hype – could be met by other methods; with advertising, for instance, or by getting favourable reviews in magazines.

By allowing the developers to focus on the goal, we may come up with different or better solutions. We also come up with different tests. Will the user actually want to navigate through the 5 screens we make them fill in to register? Will we get the big hype we’re looking for?

I find when using the Feature Injection template that I frequently put the real name of the stakeholder on the card. This means that if we run into trouble, we can go and talk to the stakeholder about alternate ways of achieving their goal.

They’re not user stories. They’re stakeholder stories.

The paradox of mocking

When we code from the outside-in in BDD, we start with the layer we know – the UI, often graphical – establish collaborators for the UI, establish collaborators for those classes, and work our way inwards until we run out of collaborators we haven’t coded.

We write examples (tests) for each unit of code, all the way down, and we usually express the collaborations with mocks.

The trouble is, we don’t really know how the class we’re about to code is going to use its collaborators. We can only guess. When I actually come to code the class, I often find that I want to use the collaborator in a different way to the way I expected. When I come to code the collaborator, I might find that it needs more information than its consuming class is giving it to do its job properly.

In this case, I have to back up and change the way that I’m expressing the collaboration in the examples. I change method names and signatures for my collaborator according to the things I’ve learnt from actually using it.

I’d rather do this – work out how I actually want to use a class, then change the descriptions – than be forced to conform to the guesswork that I made.

Multi-pair stories

Yesterday, one of the development team said, “If you’re doing XP, you only have one pair on each story, so if you have four developers, you’ll have two stories in play. It doesn’t make any sense to try to limit it to one.”

I’ve heard some of the Kanban community talk about “swarming” a feature; getting a whole team of, say, 8 developers to take it on and complete it in a short time. I’ve also found that some of them prefer not to split up the features as finely as I do, into very thin vertical slices; instead, the teams work on something marketable.

This makes sense, if you’re going to parcel out chunks of code. The idea of slicing things horizontally goes against most of what I teach about how to write stories – and yet, it does allow a larger team to get something valuable out the door more quickly than BDD’s pure outside-in.

It turns out that guessing what might need to happen further down a stack isn’t much different to guessing what happens with a collaborator, before the class is actually written. Realising this has made me revisit my assumptions about the need to do pure outside-in work. So how can we do this and still call it BDD? How can we gain confidence that we’re writing software that really matters, and doing so efficiently?

I can remember occasions at Thoughtworks where we did this – particularly, finishing off features to hit deadlines at the Guardian. Some of the developers at my current client are also working this way, as are others in the industry. So, here are my suggestions for making this work.

BDD for swarms

• Use scenarios. Having a clear understanding of the feature and a set of scenarios to which the team can work to helps keep everyone focused on the actual behaviour needed. This means it’s less likely that pairs and individuals will write code “just in case”. If in doubt, YAGNI. The scenarios will tell you if you missed something, once all the chunks are integrated.
• Get something working. Start with the happy path or simplest scenario, and integrate this as soon as you can. This will provide a “backbone” for the rest of the scenarios. It also lets the team play through the different scenarios to test their work.
• Mock out collaborators. If you need other classes for end-to-end testing, knock up something really simple or use a mock to allow you to get some feedback. For instance, I make a smiley face appear on my Game of Life exercise when I click the button, just so that I can see that the GUI events are wired up. It takes about 5 minutes to do something like this. Name your simple classes in a way which makes it obvious, so that they don’t get mixed up with the production code and can be safely deleted later.
• Talk to the team. Conversation around what you’re doing will be crucial! If an interface has been defined at the boundary of the code, and you need to change it, go tell the other teams. They’ll be able to adapt to, or at least be aware of, the changes.
• The rest of the team is your customer. When it comes to the name of a method or the value that’s wanted from that method, the “upstream” team – closer to the outside – trump the downstream team. When it comes to the information that’s required to do the job, the downstream team win.
  
List pets = petStore.getPets(String name);

  The upstream team can ask to change the List to a Set, or the name of the method to getPetsByName. The downstream team can say, “Hey, we need the type of pet too; we’ve got a hamster, a rabbit and a kitten all called Snowy.”
• Prefer code that’s easy to use over code that’s easy to write. If you’re upstream, trust that the rest of your team will be able to solve the problem you’re about to set for them. Keep pushing the complexity down, and remember: Tell, don’t ask.
• Use examples to drive your code. When you code a module further down the stack without looking to see what’s going to use it, you’re indulging in guesswork. Write some examples of how you expect the consuming class to be using yours, then revisit them when you have more information.
• Write examples to help other people code. Ideally, the upstream team will provide examples of how they want the collaborator to behave to the downstream team. These examples can be built incrementally, as the upstream team come up with features.
• Share code. If the teams check in before the code is finished, their scenarios will fail. If they check in examples which haven’t yet been coded, those examples will fail. This won’t be a problem if no one else is modifying the code base; however, if it’s a subset of a much larger team breaking the build can cause havoc, and the habit of keeping builds green is a good one. Try distributed version control, which will allow a team to check in on USB keys or a temporary space until the code works. (There are techniques for getting, say, Mercurial, to work alongside, say, Subversion – mostly by making each system ignore the other). You could also pass around patch files to keep the code in sync.
• Delete unused code. If at all possible, check the code as it’s being integrated and delete anything which isn’t actually being used or going to be used. This might include things like database columns, layers of abstraction which aren’t actually valuable, etc.
• Look for quick feedback. If you haven’t integrated your code within a few hours, it’s probably wrong. Making the assumption that it’s wrong should help you want to integrate it more frequently.
• The more, the merrier! Look over each other’s shoulders as you pass! There’s nothing wrong with tripling or quadrupling instead of pairing, if it means that a pair is more likely to write the right software later.

Edit:

Eric Willeke responded to my post with his own perspective on swarming. I very much like the idea of having the skeleton (the simplest scenario?) ready in time for the rest of the team to get on board.

Pascal Van Cauwenberghe has written a great post on estimating business value, tying it into a feature-injection style template. I particularly like the idea of calculating business velocity, and showing value earned over cost on a visible chart.

Even though we know that cost accounting isn’t useful without looking at ROI, many companies still have this focus (how many people have had problems getting hold of sharpies because they’re "too expensive"? Coloured post-its? Free coffee?)

Perhaps by making the return on investment over time apparent to everyone, we can motivate the team, show the value we’re earning and gain the trust of the business at the same time.

As an aside, I remember one client where the deadline was very tight, but nobody wanted to work overtime or weekends. Our PM asked us if there was anything we’d like to have which would help us work more effectively. We asked for – and got – fresh fruit every day. The difference in our work – both the amount and quality – was noticeable! (We already felt very well respected, so I discount the placebo effect here).

It’s amazing how much difference a few pounds of expense can make.

My first ever article, “Pulling Power: a new Software Lifespan” is up on InfoQ. BDD, Feature Injection, Lean and Kanban playing nice together!

Big thanks to Dan North, Chris Matts, David Anderson, Amr Elssamadisy and the amalgam of developers who make up “Jerry”; also to the Thoughtworkers who reviewed my article and gave me advice, and the Kanbanjins like Eric Willeke who patiently talked me through Lean and Kanban. Several times. Anything I still haven’t understood is my error, not theirs.

I wish I could have put in everything I’ve learnt about Kanban, which is far larger than this article allows. It strikes me as a lovely, simple, high-discipline, least-wasteful way to deliver software, and it matches my feeling that you should fit your process to reality, not reality to your process.

My experiments with Kanban boards so far have been highly successful. Now I want to know about the problems, too. Have you tried Kanban? What happened? Did you try to introduce it? Did that work out? If not, why not? Did you think about introducing it, but decide not to? Tell me your stories!

When we first wrote JBehave 1.0 we quickly recognised that there was power in the scenarios; in the conversations that they could help to drive, and in the reusability of the steps.

I loved the ease with which you could combine smaller steps to make bigger ones, use scenarios as the contexts of further scenarios, and take the necessarily procedural automated tests and turn them into sets of reusable objects.

Now BDD is more widely used, and people out there are using JBehave 2 and RSpec, and I hear complaints. Amongst them, this is one of the more common:

“Every time I change this screen, I have to go through fifteen files and add another step.”

Since JBehave uses plain text scenarios you can’t rely on the common refactoring tools, and that can make it a bit more painful than just messing with code. So, I thought I’d have a go at explaining how I avoid this issue; by sharing some of the ways in which I divide or combine contexts, events and outcomes into reusable components that help me avoid duplication in my scenarios.

Given a context

A context is a state which was set up by irrelevant forces, and which is used within the scenario to alter the outcome resulting from the events.

If the manner or time in which the context was set up matters, then that, too, is part of the context; unless it’s part of the behaviour you’re looking for, in which case it’s an event. The only reason for separating the contexts in which a scenario occurs from the events which are performed in the scenario is because it doesn’t matter how they were created. This means that Givens have more flexibility in implementation than Whens.

A context should matter. If you can remove the context from the scenario without changing the outcomes, it isn’t part of the Givens.

A context should be independent of other contexts. So, I prefer Given a wet newspaper to Given a newspaper / Given that the newspaper is wet. The first is less likely to require refactoring than the second.

A context should create an abandonable artifact. By this I mean that the forces which created the artifact – data in the database, files on the disk, a particular page at a given URL – can safely forget about the context they’ve created. Given an article about Iraq is a good context. Given I am logged in is not so good, even though we frequently use it as an example. Sorry. If it helps, it’s a step that rarely needs maintenance. Given we’ve filled in the comment box and are ready to submit it is likely to cause issues, because of all the other tiny steps that you have to use to get there.

When an event happens

An event exercises the feature whose behaviour you’re interested in when describing or running the scenario.

If you don’t care whether it works as long as it leaves things in a clean state, it’s a context. If you don’t actually need to do anything to cause an outcome – you’re simply checking that given some state, some other state is also present – you don’t need to write an event; just skip straight from Given to Then.

An event should create a valuable outcome.The granularity of the ideal event is very similar to that of the ideal context. As a user, I don’t want to go to the screen with the book, click the purchase button, navigate to the basket, enter the credit card number and click “submit”. I just want to buy a book. By specifying the steps which a user purchases a book inside the granularity of this larger step, we capture the value of that step. Since people rarely do things that they (or their sponsor, paymaster, loved one, etc.) don’t find valuable, this can usually be reused as one large step.

An event may be dependent on context or on another event. So, when I buy a book, and when I cancel my order within 15 days, then I should not be charged for the book.

An event should cause or contribute to an outcome. The outcome is something measurable. It could be that the outcome you’re looking for is an absence of something, for instance if a user’s preferences have been changed, and you no longer want to see all those Facebook groups. If it doesn’t cause an outcome, it’s a fairly irrelevant event.

Then an outcome occurs

An outcome describes the benefit that your system or application provides when the events are performed in the given context.

An outcome should have teeth. If a particular error message doesn’t have the exact wording expected, the world will not come to an end. If my credit card gets billed for the books but I don’t get them when I expect, it might.

An Outcome should be Specific, Measurable, Achievable, Relevant and Timeboxed. Ask a QA if you don’t know what this means. QAs are wise and can break anything.

An Outcome should represent the valuable purpose of the events. Instead of checking that a series of menus exist when you navigate to a particular screen, write a scenario that uses those menus and check that the benefits they provide are accessible through them.

Stories and regression tests

It can take quite a while to run scenarios. I sometimes like to turn mine into regression tests by combining them. I like to add contexts, events and outcomes to existing scenarios to better describe the benefits of using any particular feature in any particular context. This may mean that scenarios are related to more than one story. This will help keep them maintainable, and isn’t a bad thing.

I have never found the need to add a context to a scenario half-way through that scenario, even if it’s been created from several others.

I do frequently use one scenario as the context for other scenarios.

Unteaching the business

Sometimes, we accidentally train our business to talk to us about the solutions they’d like, occasionally in the language of software development. In that case, they’ll quite happily discuss the particular steps they need to take in the GUI to achieve the desired outcome, and may even have an idea of the underlying database tables and discuss what ought to be in those tables after the events.

If this happens, try to draw the conversation back to how the data will be used; why it’s valuable to produce that artifact in the first place. You never know; you may find you need to do less work than you thought you did.

Back last year, Vlad Gitlevich kindly made a video of Dan and I talking about BDD.

We concentrated almost exclusively on the principles rather than the technology, which means the video is still very relevant. Particularly we talked about how BDD plays with DDD, outside-in, stories and scenarios and using them in conversation with the business, and our own experiences.

See it here!

Thanks, Vlad!

The high-level vision is made up of Stories of Unusual Size

We have a good idea of where it is we want to go. We have some high-level stories which are quite large. We’re about to play some of them in our iteration, and we want to know what the real scope of the stories is. We’re also pretty sure that some of these SOUSes are too big to get done in the space of a week or two.

To get feedback more quickly, we split the stories up

Occasionally it’s possible to release part of the original, high-level story. More often, we can split the story up so that we can get feedback about that bit of the story.

Whatever we do with the story, in order to get feedback, it has to show something that the business can understand and on which they can give us feedback. If you can’t get feedback, nobody cares. If nobody cares, it’s not a story.

(If you’re having problems getting feedback from your business, try delivering something.)

We can’t split the story up into horizontal layers

The business don’t care if

• We created a CustomerData table with the right columns
• We can migrate all the old data into the new database
• We are using Spring as our framework
• We are using magical pixies to make our site look nice instead of CSS.

They care if

• They can see interesting information on the website
• They don’t have to use two different applications for the same job
• They can get changes made quickly and easily
• The site is fast enough and makes for a good user experience.

Here are three ways of splitting up stories

The only valid way to split stories is into slices which the business can understand. That means that there has to be some effect on the interface that the business use! Even if there’s another computer somewhere else that uses our site, and no user interface at all, we should be able to define the effect of our stories in terms of their effect on the interface.

QAs are used to this. They have a great acronym, “SMART”, to remind them that stories should have acceptance criteria, which should be:

• Specific – no generalizations (”It must be quick enough” vs. “It must load 90% of the time within 1 second”)
• Measurable – nothing that can’t be given a quantative measurement (”Users are happy” vs. “Users who express their level of happiness should give us at least 7/10″)
• Achievable – nothing that can’t be done (”I want my site emblazoned on the side of the moon”)
• Relevant – keep it related to the story at hand (”I want the three latest blog posts and a pony”)
• and Timeboxed- work out when it needs to happen (”I want to be able to duplicate the works of Shakespeare using the random word generator”)

Three ways that I’ve found to split up stories are:

• By splitting up the output of the interface
• By splitting up the input of the interface
• By splitting up the behaviours, or business rules, that connect the input and the output.

We can split stories using the outputs

Think of a webpage. If you’re reading this on Wordpress, it’s a great example. We’ve got several components on the screen:

• The blogroll
• The archive
• The comments
• The admin area
• The footer
• The date of each post
• etc.

Let’s say our business have asked for a blog roll. The usability experts have come up with a design that shows the date of each post, who posted it, tags, categories and comments.

We can start capturing blog posts immediately. Not all blog posts have comments. We need to capture the date to show them in order, but we don’t need to worry about how to display the date. Not all posts have tags or categories, either! So our stories might be titled:

• Blog posts
• Display date on blog posts
• Tag blog posts
• Categorize blog posts
• Comment on blog posts
• Stop robots spamming blog posts
• etc.

An output might be a page with components on it, a particular flow through an application, or a report with content and formatting.

We can split stories using the inputs

We can split the story up into the different types of input, and the way in which they effect the output. Search filters are a really great example of this. Take a look at Google’s advanced search.

I doubt that Google started with all those different search options. Maybe they started by letting you search for all words. Then by letting you search for exact words. Then by letting you search for all words, or exact words, but not the unwanted words.

The form of the output is exactly the same – a list of search results – but the actual content changes depending on what the input was. We don’t need to support all those inputs to begin with! So, our stories for a Google Advanced Search page might be titled:

• All these words
• These exact words
• Not these words
• Paginate results
• Search by language
• Search within a domain
• etc.

We might also want to split stories using the state of the application – the context in which it’s running. This is similar to changing the input. For instance, the iGoogle home page contains some widgets, and has a search bar. We can change how the widgets and search bar look depending on:

• the skin choice
• the order of the widgets
• the different tabs
• etc.

Each of these might also be a different story. The context is another input, and the output changes depending on it.

We can split stories using the business rules

Let’s say we’re building a payroll system.

The simplest payroll we can create is for a full-time employee, who has an annual salary, and who gets paid monthly. Sometimes these employees might just have arrived, so they won’t be paid a full month’s salary. Sometimes they might be in the process of leaving. Perhaps an employee works part-time, so we actually have to look at how many hours they worked that week. Maybe they do overtime. Some of them will get performance bonuses. Some will be on commission. They might have pension contributions, or expenses.

All the information is captured in a database already, so our context isn’t changing. Our input to the system is just an id! Our output is a cheque with an amount. But our amount changes as we introduce each story – which means it won’t work for everyone to start with.

We can support the simplest cases first, and add business rules incrementally to deal with the difficult cases. So, our stories might be titled:

• Full-time employee
• Part-time employee
• Employee who just joined
• Employee who’s leaving
• Overtime
• Pension contributions
• Expenses
• Commission
• Bonuses
• etc.

As we start adding things to this list, we can start dealing with more and more employees. We can let the legacy system deal with the people who aren’t on the list. It might be a manual legacy system! But even if that’s the case, we can start cutting down the work of the admin staff very quickly.

You can use scenarios to help split up stories

When we think of examples of the behaviour of our application, we think of stepping through them in the same way that QAs do when testing.

We can say:

• Given a context
• When some events happen
• Then some outputs should occur

If we have different contexts that change the outputs when the same events happen, then we can split the stories according to those contexts. So using an example of an ATM which does different things depending on the balance of my account and whether or not I have an overdraft limit, I can start splitting the “Withdraw cash” story into “enough money” and “overdraft” stories.

If different events cause different things to happen, there are probably different components on our interface that can be delivered independently. So putting in a value for the amount of money, and pressing the buttons that deliver predefined amounts of cash, might be two different stories.

If we find that we’re getting the wrong outcomes for particular contexts and events, we’ve probably got some business rules that we need to include (and we’ll have to have a strategy for dealing with the exceptions in the meantime). For instance, my card used to work very well in the ATMs abroad! But now, I have to phone my bank and let them know where I’m going ahead of time – they’ve put in a business rule to help cope with international fraud.

So our single story – “I can use an ATM to withdraw cash” – becomes:

• Withdraw cash if enough cash
• Withdraw cash if enough overdraft
• Quick buttons
• Limit use abroad
• …and we can probably find some more if we talk to people who know the domain.

These stories are not necessarily releasable

Sometimes, the business will have a minimum feature set that they want to release. This might be because of training, because they have a certain number of commoditized features that they need to enter a market, or because rolling out the software or making changes to it in a live environment is expensive.

However, the stories should each have something that the business can start playing with, that QAs can test, that we can get feedback on and that we can showcase and feel proud of.

But they might be!

We sometimes discover that a story we’ve broken down can be released with only part of the original functionality in place. This is great, if you’ve got an immovable deadline!

“We’ve just bought out another company. That’s 1,000 new employees, and they all need paying at the end of the month…”

OK. Let’s work on that first release.

Technical stories don’t make sense

As I learn more about stories and how they get written, I occasionally come across odd things that don’t make sense.

One of these is the technical story. Here’s an example:

As a developer,
I want an automated build
So that I can be sure my code works.

Of course, we’re resistant to letting developers have their own stories. So sometimes, instead, the technical story becomes:

As a business user,
I want developers to have an automated build
So that they can be sure their code works.

This doesn’t make sense to me either. Surely “working code” is part of another story, for any part of that story? Of course, the QAs are busy checking that code works! So why do we even need a build?

If there’s no benefit to the business, the chances are that a technical story isn’t really appropriate.

As a business user
I want the developers to refactor the UglyClass
So that... um...

Maybe not. In this situation, refactoring of UglyClass should happen when it enables some other piece of functionality to be delivered.

Feature injection helps us talk about the business benefit

There are some technical stories, though, which really do deliver something the business care about. You can find this out by asking, “Who cares if I don’t do this? Who cares if I don’t have an automated build? If I don’t write unit tests? If I don’t write acceptance tests?”

This is where the feature injection comes in. I’m flexing Chris Matts’s template a bit to do this; here’s how mine reads:

In order to <deliver some business benefit>
<these people>
will need <these features>.

Now we can start working out why it is that we write the automated build.

In order to minimize support costs due to poor code quality
The development team will need
To write scenarios and automate them.

In order to stop wasting money coding things that don't work in production
The development team will need
Automatic integration with a production-like environment.

In order to minimize the risk of our production environment falling over
The development team will need
Automated performance testing.

Users aren’t stakeholders

Interestingly, the people who care most about these things aren’t always the development team! The maintenance team care about support costs. The business stakeholders care about wasting money on code that doesn’t work. They also care about the production environment falling over.

We sometimes see this in normal stories too: that the user isn’t always the person who cares about the story.

As a user
I want to fill in a captcha box
so that... what? No! What a waste of my time!

Using “In order to…” we can turn this around:

In order to stop bots from spamming the site
Users will need
to fill in a captcha box.

Now it might be obvious that the beneficiary of this story is the person who has to moderate the site, or the commercial team whose adverts would become worthless in a morass of spam. But just in case it isn’t, we can capture both the stakeholder and the user:

In order to <deliver some business benefit>
As a <role> I want <some other role>
to <do something, or use or be restricted by some feature>.

In order to stop bots from spamming the site
As a member of the commercial team, I want users
to fill in a captcha box.

Feature injection helps us remove the implementation detail

So, going back to our technical stories:

In order to stop wasting money on code that doesn't work in production
As the budget owner, I want the development team
to integrate their code regularly with a production-like environment.

You might notice that when we word technical stories this way, the implementation detail – how the development team integrate their code – tends to fall away. All that’s important is that we do it; if automating that is the easiest way then we’ll do it that way.

(Interestingly, JBehave2 was developed with no automated builds. Running them manually was enough.)

Now we can talk about the business benefit of our stories

We can also see that there are three different things we can do with our new build, for three different stakeholders. Because we’re splitting up our technical stories appropriately, we can ask each of the stakeholders to help prioritise the stories, and to give us clear acceptance criteria.

In order to minimize the risk of our production environment falling over
As the person in charge of advertising revenue, I want the development team
to be able to verify the performance figures.

Now you know who you need in the story workshop, too.

“So, I want 90% of pages to load within 1 second, and it should be able to cope with the Christmas sales.”

Of course, the language still isn’t quite perfect, so you can now have the conversations about the real business benefit (maximising advertising revenue and user experience, minimizing the risk of the brand being stigmatized by an embarrassing failure) and splitting up the stories (situation normal vs. peak time).

“But, you know what? We’re not going to be able to do this until after we’ve finished the first internal release and have some idea of what the real content’s going to look like and which agencies we’re going to use for the adverts. Can we delay it till then?”

No problem. Let’s work on that first release.

If you’re more interested in the results than the conversation, skip to the summary.

Recently, I’ve realised that a lot of BDD has been very dev-focused. There’s a reason for that. Dan’s a dev, I’m a dev and most of the people who helped to evolve BDD are devs.

BDD’s about the interaction between the business and the technical people in software. I want to know how it’s working from the other side. So, I’ve been learning more about the customers, and particularly, more about BAs and their role. I had the recent fortune to run into Angela Martin at Agile India, where she taught me the art of grouping stories into coherent releases, while still keeping the stories granular enough that progress can be measured and delivery made regular and predictable.

Last night at XtC I met up with Chris Matts (of Real Options fame) who told me we’re doing it all wrong. “It’s not an art, it’s a process,” he said. “You’re focused on the stories; that’s why you think it’s an art form. The focus should be the value you’re releasing.”

“Right”, I say. “So, when we originally planned the stories that would deliver the value, we knew what would contribute to that value. But we’ve lost sight of that. Changes have been made. As devs, all we have are those narratives – the ‘As a <role>, I want <a feature>, so that <some benefit is achieved>’. So we need to work out which of the benefits add up to the value we’re aiming for. That helps us work out which stories we should try to complete for a release. The QAs are helping us work out what’s ready; the BAs are helping us work out what’s important.”

“That’s the problem,” says Chris. “You’re putting the role first. It’s the value that’s most important. Try this: In order to <deliver some value>, as a <role>, I want <some feature>. Instead of working out why people want a feature, and whether it contributes to the value, now we’re working out who needs a feature, then assigning the story. So our stories are much more focused. If all the stories that contribute to a value are ready, we release.”

I guess if we get to the point where we can release with only some of the stories ready, we didn’t break down our values into granular enough elements. And when we want to work out what goes in a release, it’s easy. The word ‘release’ is more meaningful. There’s some untapped money out there – some market share, some cost saving, some battle against a competitor. All the features we produce go towards releasing that value for our customers to use – and it’s the value we’re releasing, not the features.

Thanks, Chris, for that.

I need to also thank Dave for giving me a better understanding of what a value is.

In summary: my preferred narrative now reads:

In order to <achieve some value>
As a <role>
I want <some feature>.

Because, in order for my work to have any meaning, as a dev, I want to know why you want it.

Edit: Chris said he posted this to the Kanban group on Yahoo, but they aren’t responsible for it. Sorry, Chris, didn’t mean to misaappropriate! See you on there soon.