How does a team come into agreement about what needs to be done and how? I have been asking these questions for several years, and for the small scale of multidisciplinary teams I prefer to use Acceptance Criteria(AC), a subset of ideas of SCRUM.

There are many ways of delivering software projects (Kanban, SCRUM, DFD, RUP), as many and varied as we have sources for generating electricity, I associate AC with Eolic generation, in the sense that it’s clean and circumscripted to a given scenario, it is not a solution for the entire product vision.

In 2008 the gold standard for medium/large projects was the PMBOK, with it myriad of artifacts, documents and endless meetings :( . We used to write verbose, and somehow over-complicated, use cases written in Rational with its diagrams: a funny ellipsis or two placed within a box and arrows that link them to stereotypical users.

Use case diagram (from: Wikipedia)

However, sometimes these didn’t highlight the inherent complexity of the software essence, were too simplified to grasp the best of it. So the use case had to include an extensive narrative of the situation which becomes challenging when you need to refer to conditional logic, almost writing a pseudo-code.

In spite of all its problems, Use Cases were the defacto document for teams to communicate over and we didn’t have a product manager at that time, we would have several functional analysts that communicated these narratives to programmers, and the sum of the writings was usually called the Product Spec. Overall teams somehow deliver but we were very rigid in terms of accepting changes during development in the phase. Challenging and even heated discussions would happen if a request for change was introduced, and then the team meetings turned into a tank of sharks swimming around, waiting for the first to draw blood so the rest can attack.

Over the years, the entire community of software practitioners moved over to the outcomes of the Agile Manifiesto, trying to develop sofware with agility. A new set of practices (methodologies or cookbooks?) appear, and SCRUM became the defacto standard for processes.

Then Dave Hunt, one of the signers of the Manifiesto, declared that Agile was dead; and Kent Beck, also talked in favor of Waterfall.

Oh my, should we re-shuffle again? Are methodologies fads as with fashion clothes? Well, maybe, there are things that repeat themselves.

Nevertheless, one of the key agile principles to apply is the People over Process: writing steps that commit the entire team to produce accountable results, not only working software.

The story is a succint narrative of what happens and provides the boundaries to what does not happen so the team is on the same page on whether the story is done or not. It is a clear WHAT. It is not for displaying the HOW the software works, that’s more about documentation of the tasks. It is also insufficient to provide a higher vision of a product so needs to be complemented when scaling to a product spec but small enough to be iterable. And once all stories appear the same, as all the mills in the windfarm look alike.

Therefore, Stories with AC allow you achieve sustainable development in a similar way of eolic energy.

The Need of Sustainable Development by using applying the principle of Simplicity — the art of maximising the amount of work not done — is essential.

More interesting readings to read further:

The Acceptance Criteria for Writing Acceptance Criteria

The Definition of Done

Clear Acceptance Criteria and Why They're Important

Manifesto for Agile Software Development (from 2000!)