acceptance criteria

Baking In Quality with Agile

One of the things that I love about Agile and especially the related techniques of BDD and Test Automation is that if done correctly your teams are essentially baking Quality into your products AS they develop, not after. Traditional SDLC (read waterfall) took a very linear approach to project delivery which in turn translated into a similar approach to how we developed and delivered our software products.

In our traditional delivery methods, quality was not 'baked' in but tested out and we never ever got to the point where we are able to test out all of the 'defects' that are found, instead we create a bug database where 'bugs' go to die.  Every organization typically has some form of a bug database with bugs that were 'found' sometimes years ago and were never fixed (of course begging the question were they ever bugs in the first place?)  In Agile we really don't want to see a bug database because we should be instilling a zero defect policy for each sprint, meaning that we should never be introducing new tech debt into our product.

As I progressed on my Agile journey I came to realize that there are actually two types of 'bugs' that we encounter when we develop software:

  1. Bugs as Missed or Undefined Requirements
  2. Bugs as True Bugs

-- Bugs as Missed or Undefined Requirements - I will argue (and in a book that I am starting to write about this topic) that a majority of the bugs that we find and document aren't really bugs at all, but rather functionality that has been misinterpreted based upon the requirements definition that comes out of segregated development processes, ie Write Requirements, Develop Software, Test Software and Deploy Software.

Language is such an imprecise way of communicating that it almost virtually guarantees that if you have more than 1 person developing the software for your product you will get different interpretations of how to implement the requirement functionally.

Remember the old 'The System Shall' statement? that is commonly used in writing Business Requirements documents?  I always thought that this missed the scope of the requirement, what about what the System Shall Not Do?.  We focus so much on happy path for our functional development that we miss large segments of functionality based upon what an application shouldn't be allowed to do.

Let's take an example of an English word to convey what I'm meaning:

What do you think of when you see the word - BASS

Do you think of this:

Bass_Guitar

OR this?

Bass_Fish

These have the same spelling in the English language yet they have two entirely different meanings. Our life experiences become a prism for how we interpret what we read and how we react to it. (PS, I'm a musician so I think of the instrument before the fish)

Teams that rely on written requirements documents that are reviewed and worked on independently, meaning developers develop the code/functionality and then pass it on to testers will inherently have issues/bugs related to how something was interpreted and then developed.  In the above example the developers may have thought they were delivering a bass guitar, but the testers were expecting a bass fish (yeah extreme I know) but I believe this is the root of many of our issues when trying to deliver what the business expected in the first place.

-- Bugs as True Bugs - I believe that true bugs are more technical than functional (or should be).  Bugs related to how integration happens are very common because although we can describe the behavior of our feature we can't always anticipate issues related to how independent systems will work together.  Many 'true' bugs in Agile are caught in the moment and fixed before they ever make their way to production.  For the Finance people out there this is a tremendous cost saving that has been proven time and again.  ROI is greatly enhanced when you deal with tech debt up front rather over time.  And please don't ever think really that it is more important to get 'something' to production over making sure that the product is operationally sound.

So what to do?

To address the  inherent limitations with our  communication, we need to abstract our thinking into more concrete descriptions of behavior over broad-based statements such as the System Shall.

User Stories and the corresponding BDD acceptance criteria are a great way to do this as a BDD example table clearly defines the behavior of our product functionality via outcome based upon inputs.  The 'language' of BDD is unique so that everyone can begin to have a shared understanding of what the story and behavior of the product(aka system) will do.  BDD abstracts our communication and removes individual interpretation.

In Agile we start by ensuring that the teams understand that they OWN the quality of their delivery. One of the things that I absolutely love about high performing Agile team is that there is no finger-pointing, if a Sprint fails to deliver what the team committed to then everyone shares the blame, not just an individual or functional group.

How we bake quality into our products is by understanding how to write User Stories that provide context without the ability to misinterpret the meaning of the requirements.

To do this we must first ensure that we have a well written user story, what does that look like?

A good user story needs to identify the What and then the Value statement.  Many teams that I have worked with start to write stories that only identify the actor and What but leave out the value statement, which is really the proof that what we are working on is of sufficient value to devote our resources to.  A good user story should never have any Creative or Technical design conveyed, I know that many people like to show their technical knowledge by writing stories that convey what they think the design or system will need to utilize, but all that does is start the team down a path before exploring all options.

Behavior over language interpretation is what you are striving for when writing contextually rich user stories.

BDD with its accompanied Example statements takes an otherwise basic user story and brings it to life.  Much like we do when we take basic ingredients for cookies and then bring them together in the right amounts to deliver awesomeness every time.

Software quality is much like baking, you need:

  • The right ingredients - Good individual team members, honest communication, commitment to quality
  • The right process - Write good user stories, add quality BDD acceptance criteria, code and test in parallel and then deliver, involve the entire team in writing BDD, involve the entire team in the estimation process.

By taking the time to build contextually rich user stories and define the story with BDD acceptance you move towards a shared understanding of the 'behavior of your product' over one that is driven by functional requirements.  Requirements tend to convey to little of behavior and focus more on the big win that is being conveyed to Sr. Management regarding what is being delivered.

Agile is a very disciplined delivery process and in order to bake the quality into your product you need to develop efficient processes that keep the User Story/BDD train running smoothly.  If you are entering a sprint and then writing your BDD then you are already behind, you need to develop a process by which teams are working on current sprint development AND building context for the next one.  It can be done and when it is you get what I call progressive regression with the automation that comes out of your BDD work.

Agile is very disciplined and to think that going Agile will make your current life easier, well guess again.  What Agile will do is highlight EVERY current weakness you have in your current product delivery process and then focus your attention on finding ways of improving on them.

For those of you looking for workshops regarding User Story/BDD techniques, please reach out to me at soundagile@gmail.com.

Contextually Rich User Stories - The Importance of Details in Small Increments

Every software product that we build begins with a set of requirements. Teams or organizations who have utilized traditional requirements documentation efforts such as Product or Business requirements documents (PRD's or BRD's) typically have issues with translating their requirements process into user stories.  Instead of writing long passages of descriptive requirements that are heavy on the use of 'the user shall' we move to a smaller specification document that convey details to a specific individual feature.

What teams fail to realize is that their old requirements documents weren't all that good at conveying the necessary details that allow teams to delivery their product quickly and with quality.  You see evidence of this lack of clarity with the large number of change requests that are raised during waterfall projects.  In my pre-Agile years it was not uncommon for a typical 6 month project that I led to have over 100 change requests generated to convey the changing nature of the requirements (business, technical and UX).  The Agile manifesto addresses this reality by saying we accept change, why?  Because it's there it will happen, to deny it would be to deny the reality of product development, as we learn more we need to change our approach.

User stories, though small in format, need to have a specific level of detail if a team is to have the ability to accurately estimate and delivery the feature.

The basic User Story:

  • Story
  • Conversation
  • Acceptance Criteria

Can be deceptively simple to those who are just starting

In one organization I worked with as we moved into an Agile process the team looked at the User Story statement  as THE requirement.  It took awhile to get them to learn that successful teams use the User Story format as a specification and not a loose statement with no context associated with it.

An example of a solid User Story specification would look like this:

Story Format

Another important thing to note with this format is that the team is also collaboratively building Story acceptance criteria by using Behavior Driven Development (BDD) which directly feeds the test automation frameworks that most Agile teams utilize (Cucumber, Fitnesse, to name a few).

There are other efforts/processes that feed into getting the right amount of detail into the story such as Discovery and Pre-Planning and if these are missed you will not obtain the benefits of this format.

Over the past 5 years, teams I have engaged with, who have used this specific format for developing their User Stories have had a much greater success with both delivering on time and more importantly with higher quality.

At my last organization I asked a Scrum team to utilize this process during the Pre-Planning phase of their project.  After the project I learned that the Product Owner had been very worried about the team using precious 'development' time to talk through the work and build out the context of the user stories. After the project was completed he could state without reservation that taking the time to build out contextually rich user stories with the team had produced two key results:

  1. The team delivered on time and with more features than he had originally promised the client.
  2. When he delivered the demo to the client he had high confidence in the product as it met all of the context that had been build out and there were only 2 minor UI issues that were identified during the 3 iteration project.

Take away - Don't run before you are ready and get the context right before developing.

Member Login
Welcome, (First Name)!

Forgot? Show
Log In
Enter Member Area
My Profile Not a member? Sign up. Log Out