“The Only Constant Is Change”

What’s the problem?

Gathering and analyzing requirements correctly is not trivial. If you don’t get the requirements correct, you won’t delight the customer. If you get a requirement wrong and it gets into production, it requires an order of magnitude more money to rectify. It can be as much as one hundred times more expensive if the mistake gets into production (Source IBM). Getting requirements wrong can result in rework, which means you will get less stories done, and this will slow you down whether you use Waterfall or Scrum. At the end of the day, the requirements must lead to a potentially shippable increment in functionality. However, requirements change…

How do you solve the problem?

You can solve the problem of changing requirements by ensuring your organization’s quality philosophy takes the customers quality requirements into account. Customer involvement is essential; if they aren’t involved, you must have someone who can speak with authority as to what is actually required. There are a variety of requirements strategies

• Just Barely Good Enough (JBGE) is an approach where the customer or product manager provides requirements that are just barely good enough to start working on
• Document Just in Time is an approach where the customer/product manager document the requirements just before the coding starts, maybe a day or a few hours beforehand
• Executable (Tests) Requirement Specifications are supported by tools such as FitNesse where you can define system requirements in a syntax that is tied back to fixtures which implement the required functionality

The use of an Agile Requirements Management Tool is recommended, but you must remember the manifesto: “Individuals and interactions over processes and tools”. While the use of a tool can unburden your memory, the real value, when it comes to gathering and managing requirements, is to talk to people. A variety of tools are available; the main ones are:

• Cucumber: This tool uses “Given, When, Then” acceptance criteria. Cucumber is a tool for running automated acceptance tests written in a behavior driven development (BDD) style
• FitNesse: FitNesse is a web server, a wiki, and an automated testing tool for software. It is based on Ward Cunningham’s Framework for Integrated Test (FIT). FitNesse supports acceptance testing rather than unit testing as it facilitates detailed readable descriptions of system functions.
• JIRA Agile:  Good for building a backlog, planning each iteration’s work and visualizing team activity and progress.

Ways/Tools to Elicit Examples and Requirements

The best way to elicit requirements is by initially verbally communicating the requirements and storing them in the “Requirements Backlog”. These can be discussed just before doing the coding. We can have tests (which reflect the requirements) to guide development, or two tests, a high-level happy-path test and a high-level unhappy-path test. We can also have tools that can help to describe the desired behavior, e.g.

• FitNesse
• Mock-ups, e.g. Balsamiq
• Mind Maps, e.g. FreeMind
• Checklists
• Spreadsheets
• Wikis
• Flow charts

Eliciting Requirements

When it comes to eliciting the requirements, to avoid any contradictions, there must be only one person who speaks on behalf of the customer. This is usually the Product manager, although in principle everyone can help getting the requirements right.

Workshops, interviews and expressing examples using Fit or FitNesse are great ways to elicit requirements. Collaboration and communication are key to getting the examples, and therefore the tests, right! I consider software defects to be requirements; after all, a defect is a non-conformance to a requirement, right?

There are two standard forms for writing stories

• Mike Cohn [2004] “User Stories Applied”
  • Form: Role, function, business value
  • As a (role), I want (function) so that (business value).
• Mark Balbes [2012] “Defining Your Product with Agile Stories”
  • Acceptance criteria for a story take the form of “Given… When… Then…”

The second form is used to describe acceptance criteria for a story. The acceptance criteria serve multiple purposes. They are used by the developers and testers to know when a story is done. They also act as documentation for the behavior of the system, e.g. for technical writers and customer service.  The acceptance criteria for a story take the form of “Given… When… Then…” A single story may have multiple acceptance criteria.

When thinking of the acceptance criteria, it is often useful to apply the “zero, one, many” rule. Think about what happens in the system if nothing meets your criteria, if one thing meets your criteria, and if multiple things meet your criteria.

Mock-ups can convey requirements for a GUI or report more quickly and clearly than a thousand words.

What do good requirements look like?

Stories define the product, it really is that simple.

The requirements must have clear boundaries, otherwise the testers won’t know when to stop or whether they have encountered a defect.

User stories with acceptance tests, what are they? How do we use them?

• They are a brief conversation point (basically a dialog)
• Agile teams expand on stories until they have enough information to write code
• Testers elicit examples from the customer
• Testers help customers write tests
• The tests guide the developers
• Use cases can supplement the examples or tests

During each sprint the team works with the customer to deliver the increment in functionality. The solution is incrementally improved upon over the course of each iteration. What is the make-up of a requirement?

Story + Example + Conversation = Requirement

A shared language is required; this is where the syntax/language created using FitNesse comes into its own. Cucumber is another tool that supports a syntax which you create. This syntax then connects to the fixtures.

Good user stories call out desirable behavior and, conversely, they also call out undesired behavior. Simplicity is essential; you must strive to ensure your requirements are simple.

The scope

The requirements must be written in such a way that testers know exactly when they have reached the boundary of the requirement. If the boundary isn’t well defined, testers may end up thinking that they have found a defect. The scope needs to clearly specify what’s in and what’s out. Focus on the core functionality; get the customers to focus on this

Prioritized requirements

Are all of the requirements really needed? Those that are need to be prioritized. Personally, I like to use MoSCoW, i.e. Must, Should, Could or Won’t. Others use High, Medium, or Low.

By doing this you create a prioritized backlog. This simple activity eliminates so much confusion.

When it comes to digging into the requirements and trying to figure out what is going on, try to balance discovery with delivery.

• Discovery: understanding the right product to build
• Delivery: building the product right

A requirement is a combination of the story + conversation + a user scenario or supporting picture if needed + a coaching test or example. The stories must be testable. How do you test them? An example goes a long way toward “testing the testability” A useful phrase for any agile team member is “How can we test this?” The customer has to decide the specific requirements and capture them in the form of examples, conditions of satisfaction, and test cases. One thing that is lost on most people is that User stories are not about requirements, they are about work flow, i.e. value to the user.

The idea is to break down the project into small stories, each of which is self-contained, provides a small amount of value to the end user, and represents a thin vertical slice through the layered application design, which can be shipped at the end of each sprint. This is the much talked about “potentially shippable increment” in functionality.

Story sizing

This is never an easy thing to do as people are bad at giving exact values. A simple way to estimate the size of a story is to use T-shirt sizing. Values such as XS, S, M, L, XL, XXL work for most, they could be any value you like.

If T-shirt sizing isn’t your thing (and it isn’t mine), you could use “Planning Poker” instead, also known as “Scrum Poker”. The concept is simple: The estimators select their effort estimate from the deck of cards and everyone turns their chosen card over at the same time. The Fibonacci sequence is used, as it conveniently reflects the uncertainty of the larger estimates. This then leads to a team discussion about why one person thought it was two days’ work and why one person thought it was eight days’ work. This actually happens a lot, especially in terms with high-time developers and new hires.

Preferred methods of communication

Face-to-face is the best method of communication, so long as the person you are speaking to is professional, wants to be supportive and prepared well in advance of the meeting. If face-to-face isn’t feasible due to location and distances involved or a travel budget that couldn’t send a ferry across the Mersey, then the Trifecta would be a quiet office or meeting room using a shared desktop, web cam and instant messaging. The audio quality of webcams can be poor, so why not also “fire up” a high-fidelity conference call? Or maybe just a plain old phone call. E-mail is okay, but you don’t know when you’ll get a response, delivery isn’t guaranteed, your email could get caught in a spam filter, and sometimes it takes an age to get a response. All too often, much of the question/message is lost because 90% of communication is non-verbal and only 10% of your message is getting through to the email recipient, this is why they may misinterpret your question and send back something you were not expecting.

Executable tests are a great way to communicate

• A few examples combined with high level tests are what programmers need to get coding
• The tests must cover the basic happy path, but don’t forget to cover the unhappy path

Don’t forget that use cases are an excellent way to describe the “big picture”.

Feedback

Feedback can take different forms:

• You must take the time to solicit feedback from your customers, and also that of other testers. Ask the customers if they think their requirements are being met.
• A continuous integration framework must be set up to provide continual feedback on the state of the tests, the code and therefore the requirements.
• Embed QA with development to ensure the tester can write tests, which guide the programmer, which can be confirmed working with the new code each day.
• Did you build the right thing? Was it built right? These questions relate to the feedback from verification and validation.
• End of sprint demonstrations are an essential part of the feedback loop. The product owner, or customer proxy, needs to see what the increment in functionality looks like and get hands on-experience. If the customer is happy, that’s great, if not, the next sprint can be used to reprioritize the tasks that development needs to work on.

Roles within the agile team

• The different roles in the team work together to define the requirement using tests and examples.
• Customer team
  • These teams write the stories.
  • The teams can be made up of QA, BAs, SMEs, product managers
• Developer team
  • These teams deliver the stories.
  • The teams can be made up of programmers, architects, system administrators, and of course, the testers, as they are core.

Who solves the problem?

Writing the tests is a collaborative effort, in which all roles (product owner, testers, developers, SMEs, BAs) are involved. The detailed functional tests are written to flesh out the requirements.

The customers clarify and prioritize the requirements by providing

• Concrete examples of desired behavior required
• User stories
• Communication between the customer, QA and the developers is essential.
• Use any collaboration tool that is available.

Testers work closely with customers, or their proxies, to define stories and acceptance tests.

When

With Waterfall someone wrote the requirements before the coding began.

With Agile, on the other hand, the requirements are defined and illustrated using test cases days before the coding begins.

When is a story complete? When tests demonstrate that minimal functionality has been met.

Delivery of the steel thread/happy path/minimal increment in functionality (thin vertical slice) is essential.

Sources

iSixSigma Magazine, Mukesh Soni [2008] IBM Systems Sciences Institute report that the cost to fix an error found after product release was four to five times as much as one uncovered during design, and up to 100 times more than one identified in the maintenance phase.

References

Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley Signature)