There are five different types of ‘story’ the master story teller will deal with. The first two are Enterprise stories and Back stories which are related. These types of ‘story’ are discovered by the story teller when the project is already ‘in-flight’ and the job is to demonstrate traceability. Typically the first two types of story are not told in the classic format of (As a… I need to… So that…). They may be in any format, and it is of limited value to convert them into the standard format. The story teller should consider these types of story as a source of ‘reference’.
Enterprise story: (1) a management aspiration that is not project specific e.g. ‘Recapture the number one position in the market within 12 months by customer satisfaction and sales revenue’. ‘To reduce maintenance costs by 15% over the financial year’. ‘To increase expenditure on frontline services by 12%.’ ‘To reduce customer ‘churn’ by increasing customer satisfaction. (2) A ‘command’ from senior management that is project specific. ‘The new content management system (CMS) will use templates’, ‘The CMS will delegate content management to content owners i.e. without the need for technical resource’.
It is unnecessary to write enterprise stories in the classic user story format (As a… I need to… So that…). Enterprise stories are not directly implementable in code.
Back story: a back story is an input to the requirements gathering process that has been uncovered by the analyst during investigation of pre-existing requirements artefacts. Back stories are similar to the second definition of Enterprise stories, however they do not originate from senior management i.e. ‘The new content management system (CMS) will use templates’ could equally be a back story if it is discovered in a document written by non-senior management. The reason for separating out back stories from this type of enterprise story is to demonstrate traceability to different audiences in the organisation.
There are three types of ‘classic’ user story, all of which are hierarchically related.
- Project story
- Release story
- Iteration story
Project story: states the goals of the project from the perspective of the individual users who will use the system under consideration. Project stories are the basis of user acceptance testing. Project stories describe the end-to-end navigation of a particular business process. Project stories satisfy enterprise stories. Project stories are not directly implemented in code as they are satisfied by the aggregation of release/iteration stories.
—
As a customer
I want to explore opportunities
So that I can take advantage of new pricing plans
—
As a customer
I need to get answers to my questions
So that I can get the most out of my service
—
As a content owner
I need to provide answers to customer questions
So that customers can get answers to their questions
—
Release story: a functional decomposition of a project story that represents value to the customer/users in a standalone fashion. Collectively release stories satisfy project stories.
—
As a content owner
I need to create new content
So that information informs customers about new pricing plans or answers to questions, or general information of value to customers
—
As a content owner
I need to maintain existing content
So that information is relevant and current to inform customers about new pricing plans or answers to questions or general information of value to customers
—
As a content owner
I need to find relevant and related content
So that I can maintain the information and avoid creating duplicate or misleading messages
—
Iteration story: a functional decomposition of a release story that is of a size that it can be delivered in a single iteration. Collectively iteration stories satisfy release stories.
As a content owner
I need to find all content that relates to pricing plans for a given mobile device
So that a summary can be returned and the relevant information displayed.
—
As a content owner
I need to be able to modify the text on the page relating to prices
So that pricing data can be modified
—
And when you put this work together you get a graphic representation that looks like this:
The story teller will encounter other kinds of inputs to the ‘big picture’. It is tempting to consider all stories, all types, and all other inputs, when you put them all together, as being the ‘epic’. Unfortunately, the word ‘epic’ is already used in the Agile world to mean ‘a story that is too big’. This is unfortunate because there is a shortage of suitable words, and epic is such a good one it’s a shame it is used for such a non-specific concept. Instead, you can use the term ‘big picture’. The epic/big picture includes the story types we’ve just looked at plus the following:
- Constraints
- Acceptance criteria (related to stories)
- Business rules
- Implementation tales
- Non-functional requirements
The story teller has to know how all these inputs fit together. This is the subject of a later posting though. I’ll also be publishing graphics and spreadsheets that show how these elements all fit together so you can tell the epic, show the big picture to other people in the team in readiness for the first and subsequent iterations. Stay tuned.