What is a story?
The story is the basic unit of Agile development and delivery. It describes a small, independent behaviour that can be implemented within a single iteration, provides some value, and meets the standards for format, acceptance criteria and ‘Definition of Done‘.
At the same time, the story itself is only the written element of a much more complex flow of information and decisions. Agile development prefers to emphasise the direct connection between developers and users, and treats the story itself as only a placeholder or reminder to have the more important conversation between the developer who will implement the story and the user who wants it.
So a story is not like a specification, by which the product is defined and against which deliverables are checked. It includes its own Acceptance Criteria, but they too can evolve with the story. Rather, the story encapsulates the basic facts about what the story’s author wants and needs, but it does not define it exhaustively. That detail – and the final decision that the user’s needs have been met – comes from the direct, active interaction between the individuals directly involved in implementing it.
Although they occupy a similar place to requirements in waterfall development, they are by no means the same.
Features, epics and requirements
Stories, epics and features
To understand the story’s status as Agile’s basic unit of development and delivery, it’s important to understand its relationship to epics and features.
- Epics are just large stories – but too large to be manageable in an Agile framework. So they need to be converted to stories first.
- Features are user components (such as a common user interface or report menu) that are needed to manage multiple stories, but which aren’t actually explicitly required by any individual story. They’re just a good way to deliver a group of stories.
- In other words:
- An epic is usually the user’s (rather large) idea, which needs to be broken down into smaller components (Stories) if the developers are to manage it effectively.
- A feature is the developer’s idea, as a way of supporting and integrating many stories, usually making them easier for the user to manage.
Aren’t stories really just requirements?
Especially when making the transition from a more traditional (e.g., waterfall) lifecycle to Agile, it’s easy to think of ‘story’ as simply Agile’s rather eccentric translation of ‘requirement’. But this is not correct. Stories are very different from requirements:
- Stories describe complete units of valued capability – not a detail in a larger solution. Unlike requirements, they can – and should – be implemented independently of one another.
- Stories are short and easy to read.
- Stories include verifiable acceptance criteria.
- Stories, acceptance criteria and acceptance tests are all written by the same group – not isolated
- Stories details are elaborated just in time as development proceeds – not fixed upfront.
- Stories are only as detailed as the developer needs – not defined by a standard.
- A story is a talking point for working with users – not a fixed specification.
- Stories are delivered as part of a rapid implementation process – not buried in a massive project or programme.
- The status of stories is always transparent – not hidden in a larger development.
- Stories are easy – and expected – to change, without formal change control. All the experts and authorities needed to agree changes are already in the team (i.e., the Product Owner, plus experienced and empowered users).
- Stories are on constant view to – and under constant review by – the team.
Unfortunately, there are many aspects of a large, complex corporate entity such as a multinational business or a government department where tracing back to user stories is not feasible, and sometimes making everything a user story would not correctly reflect its ultimate purpose.
Agile201 is also agnostic about whether all stories should be traceable to user value, as is often argued. It is a useful safeguard to ask exactly what the value to the users is of a change in architecture. If there is none, what value is it offering?
The limits of User Stories
Yet there are problems with limiting stories to a single type, all of which relate to the realities of large, complex, quite possibly global corporations:
- Although a general case may be made for some changes benefiting users, it may not be possible in practice to identify who specific users are or to estimate what benefit they will receive. So using the standard structure of a user story isn’t practicable.
- E.g., architectural changes that will accelerate the performance of various system functions, but the specific value of this to individual users or even user classes may be unquantifiable.
- New functions often have no users yet. So it’s impossible to engage real users or, sometimes, to identify specific value or benefits with a useful level of precision.
- E.g., creation of a new business function.
- It’s not obvious that replacing, say, a database logging tool is of any positive value to the database’s users or administrators. It may however have a real (but very indirect) impact on the organisation’s finances.
- There are quite a few groups who are not system users in any meaningful sense but whose interests need to be taken into account.
- Architects have a legitimate interest in areas of business integration, technology, data, etc. that are of no interest or value to individual users.
- Senior management may desire many changes in the structure, flow and efficiency of the organisation as a whole, even where no single user group will notice any improvement.
- The organisation’s executives, representing its shareholders rather than its personnel, may want to move to a radically changed strategy – offshoring entire organisations, closing business units, mergers and acquisitions, etc. – even though the effect on literally every user is negative. This too is a legitimate story.
User, Strategic and Foundational stories
To support this complexity (but in a minimal manner), Agile201 assumes not one but three classes of story:
|User||Stories of direct interest and value to customers or that make users more useful (this is the classic Agile ‘user story’).|| For direct users, customers, front office.|
For managers, PMOs, back office, etc.
|Strategic||Stories defining background changes needed to support and enable User stories.|
|Foundational||Stories needed for the Agile team to implement the User and Strategic stories.|
In brief, Strategic and Foundational stories are both necessary if the required User stories are to be implemented, but neither can be defined, traced or justified by referring to any particular User story. So they are separate types of story.
Agile stories are basically very simple. However, this only makes it more necessary to write them well.
In Agile, stories are continuously under development:
- They may start life at any time.
- They may evolve from epics, features or just high-level ideas.
- They are always as accurate as can be, but only as precise as they need to be for immediate purposes.
- Change is welcomed, as it brings the story closer to what its owner really needs.
In fact no story is considered complete until it has been implemented and accepted. So there is plenty of opportunity to enhance stories:
- In the original drafting.
- During Iteration 0.
- As the story is developed with the user.
- As other stories evolve.
- As feedback is received from the Product Owner.
- As test results (including exploratory testing) come in.
- As the outside world changes.
- As the business changes.
Agile stories have two mandatory components:
They may also include other elements, such as:
As much of these elements should be included as the development process calls for. Contrary to Agile mythology, users and developers are very welcome to use detailed technical specifications, practical examples, pencil sketches or any other method of explaining what they mean. In the case of work done to meet a contract or satisfy a regulatory requirement, the implementation team almost certainly must use formal documentation. Agile only advocates limiting the use of supporting information to what is really needed, and not forcing a predefined (and often documentation-driven) formula onto the process.
Stories are written in the language of their owner (the user, customer, etc.), not technical language. They should always be documented using the standard Actor/Description/Benefit format:
|As a..||<who: role>|
|I want/need to …||<what: task/function>|
|so that…||<why: goal/ benefit/ outcome>|
Any of these elements can be elaborated to any degree, limited only by the user and developer agreeing that:
- They agree on what the story means.
- They believe they know how to proceed.
Agile is unusual in requiring the Acceptance Criteria to be written as part of the item being accepted. Acceptance criteria (define both ‘good’ and ‘done’ at story level) take the following form:
|Given…||<entry conditions/system state>|
|when…||<user action, system state, etc.>|
There are a few basic rules for defining Acceptance Criteria:
- The criteria must be defined by the user.
- They define:
- what the solution must do…
- …but not how it does it.
- A single story can have many Acceptance Criteria.
The Acceptance Criteria must also be:
- Testable by the user & team.
Agile Acceptance Criteria are different from waterfall acceptance criteria:
- Stories include their own acceptance criteria.
- They are prepared when the story is written.
- The story isn’t ready for development until the Acceptance Criteria are agreed.
- The Acceptance Criteria are written by the people who write the story – not by a separate UAT team.
There is no standard way of including non-functional requirements in a story. You could:
- Include them in the Acceptance Criteria.
- Include them in the story-level Definition of Done.
- Embed them in tests.
If shared by many stories:
- Include them in the Definition of Done for the iteration or release.
- Document them as constraints.
Agile emphasises developing stories to minimise their inter-dependencies. This makes it easier to develop therm independently, which in turn reduces bottlenecks and work-in-progress,
Despite this, many have dependencies – on other stories, on existing or planned functionality or architectures, etc. If your story has known dependencies:
- What is their functional/technical impact?
- What order do they need to be completed in?
- Is it clear:
- What specifically the dependency is?
- Scope, content, documentation, supporting materials…
- How it is being tracked?
- How it is being managed?
- Responsibilities, schedule, quality, handover, verification…
- What specifically the dependency is?
But you only need to detail dependencies if they are likely to have a significant impact on:
- What the story means, or…
- … how you will develop it.
There are no fixed rules about how large or small an Agile story should be. But given the Agile principles of organisational flexibility, responsiveness to change and minimising work-in-progress and the associated bottlenecks, the maximum size of a single story should be no more than 10-15% of the total effort available to the iteration.