The Agile201 view of Agile

The Agile201 view of Agile2017-10-12T22:05:26+00:00

The first thing to be said about the Agile201 view of Agile is that it is flexible.

There are many flavours of Agile – Scrum, XP, multiple approaches to scaling Agile, and others – and all add value. Agile201’s approach is to identify the practices and techniques that add the most value, and integrate them into a single, systematic flavour of our own.

In most respects the Agile201 interpretation of Agile is to be as simple and direct as possible, so we use standard terminology wherever we can. Where there are multiple ‘standards’, we stick to well-known and widely-used terms and concepts. These are listed here.

There are a few aspects of Agile that Agile201 interprets in innovative ways. They are all related to unresolved complications within Agile itself, though, and we are sure that they are all valid extensions and interpretations of Agile’s founding principles.

 TopicConventional Agile positionThe Agile201 view

Story types

Originally only user stories were allowed. This was probably never universally accepted, especially not by teams working in large, complex corporate environments.

Nowadays there is a tendency to allow for at least one other class of story, typically called an Architectural Story.

Agile201 assumes 3 classes of story:

  • User – stories of direct interest and value to users.
  • Strategic – stories needed for but not directly traceable to  particular User stories.
  • Foundational – stories needed by the Agile team to implement User or Strategic stories, but not traceable to particular Strategic or User stories.

Agile201 is agnostic about whether all stories should be traceable to user value, as is often argued. But all stories should be traceable to value of some kind – even though the stakeholder who actually receives the value may be far removed from the standard ‘user’.

Click here for more on different types of story.


No clear position – in fact Agile contains multiple conflicting positions! Feature remains a term with no clear or unambiguous conceptual basis.Features are treated as a specific type of epic-level item. See here for more details.

Working software

The goal of every release is to deliver working software.Especially in complex modern organisations, ‘working software’ is a very modest ambition. It is also unlikely to satisfy many stakeholders, who generally want fully operational functions, not ‘working software’.

At the very least that means a complete technical solution, and is likely to mean training users, complex deployments, process updates, organisational change and much else. If the goal of Agile is to satisfy its customers, it needs to think in terms of what will satisfy them, and leave behind the parochial notion of ‘working software’ as a meaningful goal.

With this in mind, Agile201 frequently refers to ‘working software’, but in most contexts the issues is likely to be a complete solution.

Users or stakeholders?

In conventional flavours of Agile, the user is firmly at the centre of the delivery process. The delivery team delivers user stories, and collaborates directly with users to understand what exactly it is they need to create.

  • This was largely the result of Agile’s origins in web-oriented environments, where rapid, user-focused development was the norm.
  • It also reflected the belief that traditional (especially waterfall) development processes were bloated by activities that did not ultimately deliver real value, and that all deliveries should be able to explain their specific value to the system’s real users.
Agile is now widely used in areas where the idea of ‘user’ has become more complex (e.g., who really represents external customer ‘users’?) or the key stakeholders are not users of the system (e.g., in architecture development).

In this increasingly important context, exclusive reference to users is no longer appropriate. It remains firmly the case that an Agile team should work exclusively on items that deliver demonstrable value, but the definition of value has expanded to include value not only to users but also to customers, internal functions or units, and the organisation or business as a whole.

This complicates the judgements Agile teams have to make: whose priorities come first, and what exactly would deliver ‘real’ value? Agile201 makes no attempt to answer these questions, but only repeats that it is the question that must be answered.

However, Agile201 certainly assumes that:

  • Stories can come from any stakeholder.
  • Value to users is certainly still an important measure, but not the only one.

More generally, though, as all these levels of testing are dealt with in the same user/developer cooperation, we generally refer to TDD, BDD and ATDD under the same umbrella term – Test-Driven Development.


Definitions of these terms tend to be confused, overlapping or (self-)contradictory.
  • BDD (Behaviour-Driven Development):
    • This is the level on which the user is likely to think.
    • It consists of defining tests to satisfy the standard Agile story structure:
      • As a… [role]
      • I want… [function]
      • So that… [outcome/benefit]
  • ATDD (Acceptance Test-Driven Development):
    • ATDD should test from the business’s point of view: it is asks what the application does.
    • This forces testing to a higher level, as characterised by the story’s acceptance criteria:
      • Given that…
      • When…
      • Then…
    • This has the merit of making sure that you keep thinking about the story, its acceptance criteria and the code all in the same terms.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Toggle Sliding Bar Area
Want to do more than just build systems?