Bug-vs-Feature: The Acceptance Criteria Game
Bug-vs-Feature: The Acceptance Criteria Game
In the Acceptance Criteria Game, we all have roles to play. If somebody doesn’t play the game correctly, you will end up with the Bug-vs-Feature debate and frustration.
Join the DZone community and get the full member experience.Join For Free
Is the concept of adopting a continuous everything model a daunting task for your fast moving business? Read this whitepaper to break down and understand one of the key pillars of this model in Continuous Governance: The Guardrails for Continuous Everything.
Search any issue tracker and before long you are sure to find many examples of the “Bug-vs-Feature” debate. Sometimes the debate can become quite comical, as parodied by XKCD:
Often times the Bug-vs-Feature debate is seen as an excuse not to do something.
Well, actually, that’s not a bug but a feature, closing as WONTFIX.
This type of thing can - quite rightly - get users very upset.
At this point, we could start to drag out the Myers-Briggs personality types and try to identify the kinds of personality that would be drawn to software engineering… Perhaps more tempting would be to use Lacanian psychoanalytic theory to place this behavior into the Lacanian structures label software engineers as suffering forms of perversion.
I would like to offer a different perspective.
This behavior is part of the Acceptance Criteria Game. The problem is that you didn’t realize you were playing the game. And you probably don’t even know the rules.
This is not a game in the traditional sense, nor is it one where you can be co-opted just for observing - as some bees learned when watching other bees play bee-Corey’s variant of Mao which includes a penalty for “observing.”
Rather, this is a game in the sense of Game Theory.
In the Acceptance Criteria Game, we all have roles to play. If we all play those roles correctly, then we will end up with wonderful products and everyone will be happy. If somebody doesn’t play the game correctly, or chooses not to play, then eventually you will end up with the Bug-vs-Feature debate and frustration.
I will attempt to explain the game.
- The aim of the game is to evolve a product.
- In order to evolve the product, we must change it.
- Each change has associated acceptance criteria.
- The change is not applied to the product until the acceptance criteria have been met.
- The game centers around defining the acceptance criteria.
The game works best when the acceptance criteria are explicit and documented in some form, but for small teams that trust each other verbal acceptance criteria and shared domain knowledge can allow the game to be played well.
The game does not work when the acceptance criteria are fuzzy.
There are two roles in the game:
- The change driver’s role is to define the acceptance criteria exactly as precise as required for the change.
- The change implementer’s role is to implement the acceptance criteria as minimally as required by the acceptance criteria.
When the implementer does more than required by the acceptance criteria, they are failing at the game, just as when the driver under -specifies the acceptance criteria.
Let’s play the game.
- The product is the USS Enterprise NCC-1701-D.
- It has come to the attention of management that the shields need to be engaged quite often.
- A time and motion study was performed and the results showed quite clearly that several seconds were lost between:
- the bridge commander saying “Engage Shields”;
- the security officer opening up the shield control console;
- selecting the “Shields” screen, and finally;
- clicking the “Engage” button.
The result was a request to change the UI: add an “Engage Shields” button to the bridge commander’s screen.
This change could also include a REST API so that the functionality could be invoked from the bridge commander’s tri-corder in the event that they are away from their station.
The change driver has not played their role correctly, so let’s see what happens when the change implementer plays the acceptance criteria game:
The game is afoot!
First, that whole “This change could”… well you used “could”, so we don’t have to do anything there. So, no need for the REST API then.
Next, you said add a button to the screen but you never said that the button should do anything, from which we conclude that we can just add the button and have it do nothing.
The result is that the change gets implemented and the ship blows up at the next encounter.
In other words, because the change driver did not play their role correctly, we end up with a crappy, sub-optimal product and everyone is a loser.
What should happen after this is the change driver should recognize the ship destruction was their fault resulting from a failure to play their role correctly. There should be learning, and the next request to change should be accompanied with better acceptance criteria.
Add an “Engage Shields” button to the bridge commander’s screen.
The button will not require any confirmation and will engage the shields.
Pressing the button should engage the shields within no more than 50ms.
Let’s see what could happen if the change implementer does not play their role correctly.
Ok, we have added the “Engage Shields” button…
It doesn’t make sense to keep the button there when the shields are already engaged.
For completeness, when the shields are engaged we will replace the button with a “Shields Down” button.
The result is that the change gets implemented and more besides. This time the ship blows up because the shields were being cycled rapidly because the bridge commander had left their finger on their console for more than 50ms and activated the “Shields Down” button that was not requested in the original change.
In other words, because the change implementer did not play their role correctly, again we end up with a crappy, sub-optimal product and everyone is a loser.
So, how can we play the game so that everyone wins and we end up with a superb product?
My answer is that we should recognize this is a game, and reward playing it correctly… but reward it before you start making the change.
Before you start work on a change, make sure that there is agreement on the acceptance criteria for the change.
- The change driver should ask for the holes in their acceptance criteria. Do not wait until the change has been implemented to find out that you left holes in your criteria!
- The change implementer should seek to confirm the minimal effort to deliver the change. Do not implement more than required.
If we do the above before we start, ideally as part of the review of the acceptance criteria, then it is clear what each change will provide.
Now, of course, there is another problem with maintaining an accurate description of what the aggregate functionality of the product is as it is changed, but we can just add updating that description to the acceptance criteria, and we are done!
Published at DZone with permission of Stephen Connolly , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.