Good Enough, Lean, and User Stories

This article discusses two subject groupings:

a) current definitions and examples of 'Good Enough' software and 'Lean' software;

b) how by eliminating wasteful efforts using lean concepts like value stream mapping, coupled with using the idea of user stories and acceptance criteria, any issues regarding the subjective use of 'good enough' becomes objective.

Good Enough Logic

For years the idea of good enough software has stoked many a disagreement between people suggesting that even using such a phrase may license people to do less than their best, or even do less than is necessary for a complete deliverable. To some, good enough seems to suggest sub-standard work. Good enough merely suggests when to say 'when'.

Exemplified, you may hear as I do, developers and testers arguing that good enough logic is simply unprofessional and irresponsible. And business folks, sometimes customers and customer proxies, arguing that if someone on the delivery team is using the term good enough, they are likely cutting corners. So people tend to rebound from this concept by uttering such phraseology as 100% test coverage from testers, requiring onerous low-level designs and inspections, or arduous detail and alignment with project schedules and Gantt charts forecasting the future...all due to the knee-jerk reaction of not wanting to be good enough practitioners. Understanding test coverage is good. Understanding design and inspection is good. Over-use of these behaviors due to fear of the unknown or inexperience is an uneducated bludgeoning resulting in over-engineering. Later, people appear confounded as to what takes so long to fix a 'simple' defect in the system.

While this article is neither intended, nor crafted to discuss software testing in specific, it is a low-hanging, good example of the mis-characterized battle between good (do it all) and evil (do what is good enough) in the software systems realm. Exactly how much testing is enough, let alone good enough? A 2001 book that stimulates interesting conversation, Lessons Learned in Software Testing, published by Cem Kaner, James Bach, and Brett Pettichord, offered up experiential context driven thinking to help individuals and teams responsible for testing systems discuss and determine what makes sense for the problem being solved. Hence, a conversation of good enough for the situation.

"Furthermore, we think it's better to live with uncertainty about testing than to embrace false certainty. A good decision about how much testing is enough is necessarily based on your skill and judgment, ..." (Kaner, Bach, Pettichord, 2001, p.171).

What is quite positive about this statement is the encouragement to make a good decision based upon customer expectation, business and technical risk, coupled with one's individual experience and context. Ironically and unfortunately, people yet seem to want someone else to prescribe 'exactly' the way things should be anyway and it simply cannot be responsibly so; hence, the conflict with good enough thinking. Good enough decisioning is relative, often subjective, and is not just about testing, but rather about making decisions in general. To further explore context-driven good enough efforts with regards to testing, consider the 1999 book titled, Testing Computer Software. Said idea is discussed quite thoroughly with regards to test coverage and is fundamental to maturing one's ability to decision effort versus return comparisons. Pay particular attention to Chapter 3 titled, "Test types and their place in the software development process".

A single, minute example of good enough testing is evidenced by the below matrices showing a number of possible variable combinations that could be tested, and which ones common-sensically will be tested right now through redundancy elimination and prioritization. The cross-pollinization of this concept to other work is limited by one's mind, only.

Oh, should testing any system be so simple. When we add dynamically generated screens, conditional business workflows, multiple statemachines and sub-statemachines, variable user level permissions, integrations, third-party content, government and private sector regulations and security, multiple languages, and things with and without specifications or customer declaration - we have a bit more to code and test. Good enough conversations come into play when we have three days, three people, and a system too big to fully verify in arrears.

Choosing what we will and will not code, what we will and will not test, and what we will and will not deliver given time, risk, and value is not a conversation of good enough, it is specifically and directly a conversation of do what is necessary to meet the expectations of the customer - no more, no less. In fact, the balance of doing no more or less than is required harkens to lean logic doesn't it? Waste elimination sound familiar?

Someone always has to decide what will and will not be addressed right now, in what order and to what extent. In order to do it right, it must always include the customer, else we're simply gambling - which, if we don't understand the math and probability behind gambling, is waste also.

Lean Logic

With regards to lean logic, let's focus on one very simple, very powerful concept - value stream mapping. Any company, in any situation, will benefit by understanding and using this very simple concept on a frequent and continual basis. Take a look at the below diagram for explanation and consider its use. Take the time to look to Mary and Tom Poppendieck's book, Implementing Lean Software Development: From Concept to Cash, which discusses the ideas of eliminating waste for anyone, including particularly those people in the software and systems business.

Consider the following behavioral steps when trying to determine what is required and what is waste in terms of adding value to your business and customer:

Step 1: Lay out the primary sequential horizontal steps for any process in question. One can always be more detailed and analyze process, sub-process and the like; but concentrate on understanding the primary path of activity first as it usually points out wasteful activity with near immediacy.

Step 2: Within each box, identify 'how long' each step takes to be executed, and the number of people, forms, tools and repositories required therein.

Step 3: Between each box, identify 'how long' each step waits between execution.

Step 4: Add up the execution time identified in Step 2 and put it out to the side. Thereafter add up the wait time identified in Step 3 and put it out to the side.

Step 5: Add up the wait time and execution time which gives us total investment time to execute said process. Then take the total execution time and divide it by the total investment time to discover what % efficiency this process truly is for your organization.

Simple, true? Think about lean concepts like this:

Anything that does not contribute to cash in the pocket may very well be waste. Identify it, isolate it, ensure you're not overlooking something important, then eliminate it - mercilessly and without fanfare.

During this experience, take special time to consider how one could reduce and eliminate wait time (which is also known as waste); reduce the number of steps, people, tools and time taken to execute the 'execution' path, and so on. We're discussing the window between when a company has a contract, concept, service or product, and when a company will be delivery done and enabled to put cash in their pocket.

And a bonus feature, this idea works seemingly all over the company across multiple mediums. For example, using logic like this helps minimize key strokes and screens necessary to accomplish a task or set of tasks. How many clicks to get to the end of my workflow? How many screens? How many people across how many screens and key-clicks? This conversation is not about what is good enough, though it plays an embedded role in conversation and behavior; but rather understanding what directly contributes and what does not. What contributes is useful; what does not is waste.

Let me take a moment here to differentiate something that I perceive some still struggle to understand based upon those believing a CMM 5 certification or Six Sigma Blackbelt means the same thing no matter the application...just because something works in one company does not mean it will work in another. Similarly, just because something works in the manufacturing industry, does not mean it will work in the software industry. The process dissension between manufacturing and software delivery paths are voluminous given the differences between hardline assembly streams (hardware) versus softline construction, configuration activity paths (software), and the speed at which logarithmic change can be experienced. However, one very same application of an idea between the two unlike industries is the need to understand what is minimally required to be successful and eliminate associative waste. Manufacturing is in many cases, better at it. The exercise we just discussed is precisely the activity to be pursued...understand the time it takes to execute and wait; eliminate wait time, compress execution time, and perform this exercise continually, often and frequently.

We've lightly touched the ideas of good enough and lean so far. The next section discusses the idea of user stories and acceptance criteria to be used as the juxtaposition of doing good enough work, in as lean a manner as possible, all defined and managed by the customer.

User Stories and Acceptance Criteria

If you're new to the idea of a user story, and you serve customers - consider the following ideas:

  • Customers know their problems better than vendors know the solutions
  • Customers know what they want and will get it, with or without the vendor
  • Customers don't speak industry or vendor jargon; they speak native to their own culture and personal lives

In a previous post titled, Simplifying Test Construction, the article discussed the role and value of User Stories and Acceptance criteria and how they help define 'done'. If you are familiar with requirement specifications articulated as "shall" statements or use cases, they tend to work in context-driven situations ... though both require their own level of detail, weight and grid-iron for a 'delivery framework'. User Stories provide a clear definition of the problem a customer is attempting to solve and succinct acceptance criteria by which the the customer will discern 'done' in a light-weight format that is not too big and not too little ironically (or not) designed to mitigate waste collection.

An example user story and acceptance criteria format is:

As a <>, I would like to perform <> so that I can accomplish <>.

An example of the story statement in use is:

As a banking customer, I would like to deposit money into my account so that I can later access it if and when needed.

Example Acceptance Criteria that you and I would likely use to define "done" or "success" are:

  1. The ATM machine should take my cash, checks, deposit slip
  2. Whatever I deposit should not get mangled, ripped or stuck
  3. I should have sufficient time to deposit whatever it is I'm depositing
  4. The ATM screen should reflect my successful deposit transaction
  5. The ATM screen should reflect my increased account balance after the deposit

We can easily polish up these statements to be more consistent with each other and consistent with anything else we capture from the customer at a later time. For now, recognize the following:

We know who wants to accomplish what action for what goal
we know what criteria the end-user will use to determine success and done-ness.

What do we have here? The observation that the pursuit of good enough software systems is actually achieved by applying lean concepts with user stories and acceptance criteria as the medium.

In other words,

  • STOP discussing good enough software as it only contributes to confusion;
  • CONTINUE pursuing lean software systems implementations using value stream mapping; and
  • START leveraging the simplicity of User Stories and Acceptance Criteria to understand and define 'done' using the language of your customer, not your template.

There is an inherent relationship between those who practice lean implementations of anything, those who pursue good enough solutions to anything, and those who practice user stories and acceptance criteria in the fields of Agile/XP software system solutions - simplicity. What's missing is the ability for many to recognize when their US$10k certification, current classwork, company or university reputation is irrelevant.

Hard-core capitalists would articulate the goal to be 'achieving the highest return for the least investment in the shortest time possible'. Since I tend to favor the inclusion of people in these conversations, I reword it a bit.

"If you're not a little embarrassed about how simple your solution to the problem is, it likely isn't simple enough."

Note: If you want to study history with regards to successful lean implementation, study Toyota. Should you want specific coaching, education and application of lean logic to software, see Mary and Tom Poppendieck.

(Kaner, Bach, Pettichord) Kaner, Cem. Bach, James. Pettichord, Brett. Lessons Learned in Software Testing. Wiley. 1st Edition. 2001.

(Kaner, Falk, Nguyen) Kaner, Cem. Falk, Jack. Nguyen, Hung Q. Testing Computer Software. Wiley. 2nd Edition. 1999.

Poppendieck, Mary. Poppendieck, Tom. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley Professional. 1st edition. 2006.