I have written this article in the hope that it will help people avoid experiencing the mess that I have seen companies get themselves into on enterprise projects. I say enterprise projects here and this refers to your large program / project corporate environment. On small projects, other environments or in a ‘heaven’ scenario where people buy-in and accept test first as the detail, then this is not applicable. I once witnessed a project in an organisation that after 12 months of execution they had a backlog of 1000+ user stories with the requirement bound to the story, all I observed was chaos.

So what is a user story?

• A user story implements a need or a portion of need to meet a given business outcome

• A user story has conditions of satisfaction (acceptance criteria) that tells a developer when to stop implementing (the development boundary)

• A user story has conditions of satisfaction that tells the tester what implementation to validate and confirm (the testing boundary)

• A user story has conditions of satisfaction provided by the product owner (or proxy) that allows them to confirm that what they agreed with the team has been implemented successfully by the team

Why is binding a requirement to a user story dangerous?

Here is a hypothetical example showing how details (the requirement) bound to stories is flawed, the user stories below were implemented in order. Please note that I am only showing an example and not putting it into any specific format or practice, the intent is to show the problem.

User Story 1

Acceptance Criteria:

Capture customer first name, last name, physical address, mobile, landline and email address

Product owner realises they missed something so we cut a new story

User Story 2

Acceptance Criteria:

Capture customer fax number

User Story 3

Acceptance Criteria:

Capture customer postal address and lookup suburb from national postal records

Stakeholder tells product owner that the organisation is not supporting fax technology anymore and a new need has arisen where an email gateway is to be delivered and digitised email deprecates faxing due to the new relaxing of legislative requirements.

User Story 4

Acceptance Criteria:

Do not capture fax numbers

This poses a serious problem, the only way that I can ‘see the whole’ for capturing the customer is:

• I have to look at the acceptance criteria for the stories in the exact order of implementation

• I have to collate the information into a single format to see the whole

• I have to analyse the information to see if the requirement for one story does not undo a requirement for another story

This is costly, increased margin of error and becomes a requirement nightmare

The other important thing is how do we know we have implemented everything to meet the desired business outcome i.e. capturing the customer?

I am a strong believer in collaboration and I hope one day that the test first as specification will be mainstream but agile maturity is still far off in many organisations.

The solution

‘The stories (implementation) are bound to the overall specified business need’

This is where epics (features, agile use cases) come in. Epics allow us to provide the information for the need and then using that information we can ask ‘How do we implement this?”, in answering that question we get story decomposition and associated conditions of satisfaction.

Taking our example above, the epic would look like this:

Epic: Capturing Customer Information

Customer first name, last name, physical address, mobile, land-line and email address

A new need arises to add fax number, epic is updated and a story is cut

Epic: Capturing Customer Information

Customer first name, last name, physical address, mobile, land-line, fax number and email address

Postal address need comes along , so epic is updated and story (s) are cut

Epic: Capturing Customer Information

Customer first name, last name, physical address, postal address, mobile, land-line, fax number and email address
Lookup suburb from national postal records when capturing postal address

Change in corporate direction to not support fax technology anymore so no need for fax numbers

Epic: Capturing Customer Information

Customer first name, last name, physical address, postal address, mobile, land-line and email address
Lookup suburb from national postal records when capturing postal address

What are the benefits of binding the stories to an overall container (epic, feature, agile use case)?

• The need is expressed in a single location i.e. see the whole

• It is a great practice when modeling or scouting ahead as it makes story decomposition easier by asking how do we implement all this?

• Allows us to confirm that we have implemented the intended need as a whole

• Makes tester’s lives easier

• Makes the product owner’s life easier when making decisions and confirming with stakeholders and SME’s

• Solves the biggest problem of outdated lightweight documentation, the documentation is always up to date

• Training and development have a reference point so reduces number of queries on team members

• Strongly supports offshore development and testing

• Architecture (if applicable) have the WHAT in the epic to do their work

• Epics are a good candidate for test-suite layout

• Business and organisational change groups have a single reference point

• Documentation is lightweight but valuable and experience shows less resistance is encountered on agile transformations, especially from business analysts

What is essential to the success of this model?

Collaboration ! It is essential that as new needs are realised that they are shared with all participants. You cannot have people making updates to epics without sharing that information as there will be a gap between implementation vs outcome. What I normally do is as a new need arises, the epic is updated and shared and as a group a decision is made on how to handle this. For example quick session to decompose, size and write conditions of satisfaction.