One opportunity that was missed during the talk was to recognise that the Apollo programme was, in itself, an incremental and iterative project. So, NASA has been an Agile organisation for much longer than many might give them credit for.

It wasn’t until Apollo 11 that they landed someone on the moon. Each mission, from 1 to 11 (as well as the numerous missions prior to that not carrying the Apollo name), was a process of experimentation and gradual improvement towards the end goal.

Think of each Apollo mission as a ‘release’, each of which improved upon the previous. Following the tragedy of Apollo 1 (where 3 astronauts lost their life) subsequent Apollo missions were unmanned progressing back to manned flights. Incrementally, missions progressed to achieve earth orbit, then lunar orbit and finally, landing on the moon.

Learning from each mission was used to improve and refine the portion of the journey achieved so far and to guide the next increment.

I’m glad I caught Jeff afterwards to mention this. I get the impression that this point is going to find its way into future iterations of his talk.

Such confusion results in questions like the one asked of Rachel Davies recently, i.e. “When to write story tests” (sometimes also known as “Acceptance Tests” or in BDD parlance “Scenarios”).

In her answer, Rachel highlighted that:

“…acceptance criteria and example scenarios are a bit like the chicken and the egg – it’s not always clear which comes first so iterate!”

In that article, Rachel distinguishes between acceptance criteria and example scenarios by reference to Liz Keogh’s blog post on the subject of “Acceptance Criteria vs. Scenarios”:

“where she explains that acceptance criteria are general rules covering system behaviour from which executable examples (Scenarios) can be derived“

Seeing the acceptance criteria as rules and the scenarios as something else, is one way of looking at it. There’s another way too…

Instead of Acceptance Criteria that are rules and Acceptance Tests that are scenarios… I often find it useful to arrive at Acceptance Criteria that are scenarios, of which the Acceptance Tests are just a more detailed expression.

I.e. Scenario-Oriented Acceptance Criteria.

Expressing the Intent of the Story

Many teams I encounter, especially newer ones, place higher importance on the things we label “acceptance criteria” than on the things we label “acceptance tests” or “scenarios”.

By this I mean that, such a team might ultimately determine whether the intent of the story was fulfilled by evaluating the product against these rules-oriented criteria. Worse still, I’ve observed some teams also have:

• Overheads of checking that these rule-based criteria are fulfilled as well as the scenario-oriented acceptance tests
• Teams working in silos where BAs take sole responsibility of criteria and testers take sole responsibility for scenarios
• A desire to have traceability from the acceptance tests back to the acceptance criteria
• Rules expressed as rules in two places – the criteria and the code
• Criteria treated as the specification, rather than using specification by example

If we take the approach of not distinguishing between acceptance criteria and acceptance tests (i.e. see the acceptance tests as the acceptance criteria) then we can encourage teams away from these kinds of problems.

I’m not saying it solves the problem – it’s just easier, in my experience, to move the team towards collaboratively arriving at a shared understanding of the intent of the story this way.

To do this, we need to iteratively evolve our acceptance criteria from rules-oriented to scenario-oriented criteria.

Acceptance Criteria: from rules-oriented to scenario-oriented:

Let’s say we had this user story:

As a snapshot photographer

I want some photo albums to be private

So that I have a backup of my personal photos online

And let’s say the product owner first expresses the Acceptance Criteria as rules:

• Must have a way to set the privacy of photo albums
• Private albums must be visible to me
• Private albums must not be visible to others

We might discuss those to identify scenarios (as vertical slices through the above criteria):

• Create new private album
• Make public album private
• Make private album public

Here, many teams would retain both acceptance criteria and scenarios. That’s ok but I’d only do that if we collectively understood that the information from these two will come together in the acceptance tests… And that whatever we agree in those acceptance tests supersede the previously discussed criteria.

This understanding tends to occur in highly collaborative teams. In newer teams, where disciplines (Business Analysts, Testers, Developers) are working more independently this tends to be harder to achieve.

In those situations (and often even in highly collaborative teams) I’d continue the discussion to iterate over the rules-oriented criteria to arrive at scenario-oriented criteria, carrying over any information captured in the rules, discarding the original rules-based criteria as we go. This might leave me with the following scenarios:

• Create new private album (visible to me, not to others)
• Make public album private (visible to me, not to others)
• Make private album public (visible to me, & others)

Which, with a subtle change to the wording, become the acceptance criteria. I.e. the story is complete when we:

• Can create new private album (visible to me, not to others)
• Can make public album private (visible to me, not to others)
• Can make private album public (visible to me, & others)

Once the story is ‘in-play’ (e.g. during a time-box/iteration/sprint) I’d elaborate these one at a time, implementing just enough to get each one passing as I go. By doing this we might arrive at:

Scenario: Can Create new private album
When I create a new private album called "Weekend in Brighton"
Then I should be able to see the album
And others should not be able to see it

Scenario: Can Make public album private
Given there is a public album called "Friday Night"
When I make that album private
Then I should be able to see the album
And others should not be able to see it

Scenario: Can Make private album public
Given there is a private album called "Friday Night"
When I make that album public
Then I should be able to see the album
And others should be able to see it

By being an elaboration of the scenario-oriented acceptance criteria there’s no implied need to also check the implementation against the original ‘rules-oriented’ criteria.

Agreeing that this is how we’ll work, it encourages more collaborative working – at least between the Business Analysts and Testers.

These new scenario-based criteria become the only means of determining whether the intent of the story has been fulfilled, avoiding much of the confusion that can occur when we have rules-oriented acceptance criteria as well as separate acceptance test scenarios.

In short, more often than not, I find these things much easier when the criteria and the scenarios are essentially one and the same.

Why not  give it a try?

The solution in question is to use categories to ‘tag’ tests with a feature name and for those categories to be runnable. So, we can tag all the acceptance tests and integration tests relevant to users, say setting up email alerts, and run the ‘category’ as a suite. This is explained in this video about Runnable Categories.

Another good week! Everyone is open to trying new things and very capable.

I’m on holiday for the next week, so my next post on this thread will be in around two weeks. I’m going to miss being there this coming week – but I am human and I do need to have a holiday.

I’ve just completed my first ‘official’ week working with them. It was one of, if not, the smoothest of inductions I’ve ever experienced. I arrived and was shown a desk to work at. There was a welcome letter in front of a dual screen developer machine with Ubuntu installed. The letter told me everything I needed to get logged in, access e-mail and wiki links telling me where to find the rest of the information I needed to configure the machine. For the project I was about to work on.

Their CEO sent out an introduction e-mail telling everyone about me and others who started that day on the development team and in other non-technical departments. I also experienced a warm welcome from the team and was assigned a youDevise mentor to help me settle in.
My first few days involved several presentations – mostly demonstrative – introducing me to youDevise products and their business model. Yet I still got to work on code almost immediately.

I was very lucky to get to pair with their summer intern, Marius Cobzarenco, on a part of an all-new reporting capability for one of their products. I am so impressed with Marius. He left Cambridge University only three weeks ago and I have to say he is one of the most competent graduates that I’ve ever met! He has a level of technical competence that rivals many much more experienced developers and he has a passion and aptitude for learning that is rare. He became competent in Behaviour Driven Development after working with me for only an hour or two and fell in love with the approach. I was so impressed with him that I decided to sponsor his attendance at a TDD workshop this weekend with Jason Gorman.

Marius is a reflection of the high standards youDevise sets for itself. Whenever I’m there, I never feel like the smartest person in the room.

Speaking of smart people, other youDevisers I’ve also had the opportunity to work with include Joe Schmetzer and Stephen Siard.

Joe is a great guy – extraordinarily capable yet incredibly humble. Joe really knows his stuff! I’m looking forward to sharing with him, but mostly, learning from him. Stephen – who I have secretly, in my mind, nicknamed ‘the professor’ simply because his intellect is especially humbling for me – is another who I have been very lucky to work with. He has a way with algorithms that is tantamount to wizardry – but he is far too scientific to be called “the wizard”

These guys stand alongside other similarly impressive and diverse individuals that I’ll mention in future posts – each with their unique talents.

Next week, we start a new iteration. I’ll be seeing what it’s like working with some of their legacy code. Based on what I’ve seen so far, at least I know they recognise where they have legacy and that they are passionate about writing tests and cleaning the code up as they go.

Their CTO has been one of the most vocal advocates of RiverGlide, the company I created with Andy Palmer last year.

youDevise are enjoying a period of growth – driven by demand for their services. They have been hiring developers and testers but are struggling to keep up with demand due to their high-standards – they value quality over quantity. About 6 weeks ago they had retained my services for 2 days a month for some coaching and consulting. We got talking about the challenges of finding the right talent for their organisation. Then, it occurred to them, perhaps I could help so they asked me if I would consider working for them as a developer, in-between the coaching and consulting days.

This was a great opportunity for both of us. During our relationship so far, I’d only seen things from the outside. My visits were never more than 1-2 days at a time and involved working with several people looking at slices of problems they wanted to solve or goals they wanted to achieve. I only ever had anecdotal information – never first hand experience of working in their environment. First-hand experience will give me insights that will contribute significantly to the value I can deliver when coaching their teams.

For me, it meant I would get to work as a team member on a real project. I like to do a tour of duty working on a commercial project for real at least 3 out of every 12-18 months. It keeps my skills sharpened and keeps the advice I give as a consultant honest.

So, here we are. For the next month or two I’ll be working 4 days per week for youDevise as a consultant-developer, 2 days a month as a coach/consultant leaving me a couple of days a month to spend with other clients and on other projects.

I’m still the curator of testingReflections and intend to continue to be so, as I still get many people telling me how valuable it is to them. I have many plans for it, to bring it up to date but I simply haven’t had the time. I am working hard to make that time, so I appreciate your continued patience.

I’ll continue to cross-post to testingReflections for some time to come, but this is where you’ll find my latest posts so you may now wish to grab my feed from here.