Less than three there there should never be

Posted By Duncs ~ 30th January 2013

For safety reasons, there is a mantra in the canoeing community which is drilled into you from the first time you get in a boat: “less than three there should never be”
It refers to the minimum number of paddlers there should when a group goes canoeing.
Once again, I can shoehorn paddling into a metaphor for software development…

The idea being that with 3 paddlers, if one of you gets in trouble, the other 2 can help. Or (more pertinently for this post) when scouting a rapid, the differing experiences of 3 people really helps to make a decision on how to run that rapid.

Likewise, in software development, having 3 people in a discussion about a feature prior to any code being written also helps decide how that feature will be developed.

Sounds like normal requirements gathering / reviewing eh? Well it is, except that the gathering & reviewing is going on in real-time, through conversation & giving fast feedback to the people that matter.

This conversation is opposed to reviewing documents which have taken time to write & are invariably out of date as soon as they are published (subject to Michael Bolton’s Relative Rule?)*

I find this conversational approach to requirements gathering & reviewing more effective than waiting for a document to land on my desk. For example, I’ve found that a lot more implicit requirements are driven out this way - stuff that is only thought of when ideas are bounced around with others.

Who should be at the table?

Generally I like a Business stakeholder, Tester & Programmer to be part of the discussion as they each bring a different perspective to the table. Each person has an idea what the feature is about, but this picture isn’t unified:

Having this conversation helps to ensure everyone has the same idea about the feature & that what gets developed is actually what the Business stakeholder wants.

Who brings what to the table?

Cast your mind back to school for the 5 Ws on the Rugby post - Who, What, When, Where, Why & How:

Business Stakeholder

• Who - they are person requesting the feature
• What - the feature request
• Why - do they want the feature (will help focus Dev teams questions)
• When - they want the feature

Tester

• Why - is this feature being requested (to understand the value)
• What (TF) - asking questions of the requirements to drive out ambiguity
• Where - will the test coverage be (e.g. unit, integration, GUI)
• How - having an understanding of the implementation will help focus testing, help with testability & increase understanding of what coverage is required at what level

Programmer

• How - do they propose to develop & implement the feature
• Why - is this feature being requested (to understand the value)
• When - they reckon they can deliver it by
• Where - will the test coverage be (e.g. unit, integration, GUI)

If you take away any member from this discussion then key information is going to be missed.

For example, take away the Tester & you get Programmers jumping straight to how they are going to implement the requirement. Its not until the software is delivered that the Business Stakeholder realises they were not specific enough.

Take away the Business Stakeholder & you get Testers & Programmers developing to vague & ambiguous requirements. Again realisation that the requirements were not good enough comes too late.

It has its limitations though - it really loses its effectiveness if the features you are discussing are too large. Breaking down of features into smaller pieces is a discussion for another post (I’m not saying I’m going to write that post!)

Its not just me

I’m not the first person to talk about this:

• George Dinwiddie calls it “The Three Amigos“
• Julian Harty calls it “Trinity Testing“
• Janet Gregory & Lisa Crispin call it “The Power Of 3”

Where to start?

If you’re a Tester reading this post & new to the idea, I urge to start asking “Why” to get an idea of the value of the feature to the company. You’ll know a great answer when you hear it & it will really help you buy-in to the development of the feature.

From here the process grows organically as the necessary people should be joining the conversation to help answer your questions.

I’d love to hear about your experiences with this method of requirements gathering / gathering. Does it work for you? What sort of problems do you come up against when using if? Is it a new idea to you?

Thanks!

Thanks must go to Maria Kedemo, Kristoffer Nordström, Lisa Crispin & George Dinwiddie for prompting me to put my thoughts down on paper!

 

*Notes of the conversation can be kept in whatever format you like - acceptance criteria / business requirements in a wiki, acceptance tests in the code as living documents, napkin etc.

In my opinion, the acceptance criteria / requirements should be executable tests in the code - if a check-in or release causes a test to fail we have immediate visibility of the system no longer conforming to the specifications as they were originally agreed.