|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.
|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.
TDD, BDD & ATDD
|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:
- 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.