User Story “Import a text or document file”

This post is the third one in the first Build-Measure-Learn cycle to build a Minimum Viable Product. In the last post, I broke down the epic ‘Storing text files’ into major user tasks. With the new set of major user tasks, I was able to tell into detail Anton’s story of importing some files into the Text Analyzer Platform. From the set of major user tasks I will pick the story “Importing a Text or Document File” for implementation. I will flesh out the story and then analyse the story applying the INVEST characteristics. As a result, the story has to be split up into even smaller stories.

Selecting a Valuable User Story

In the last post I identified a bunch of major user tasks. Regarding the development, the next step is to pick the task with the highest value for the user and to describe the user story. A user story tells about, what the software does and why it is valuable to a user or a customer, see [Cohn2004]. Here we will go on with our persona Anton as main user type. In our case, the decision of which user task has the biggest value is answered quite easily. It is the story ‘importing text files’, because text files must be present in the system to be analysed.

Describing the User Story

To describe the story, I will use the traditional template developed by Connextra, see [UserStoryWiki]. This is the first draft:

As Anton
I want to import text files and documents
so that the content is available for further analysis

Anton is a student of computer science currently working on his diploma thesis. I was describing the persona Anton in the third post in detail. The story describes the expectations of Anton. The user story tells us that Anton will be able to import text and documents into the Text Analyzer Platform. Moreover, it tells us why this is valuable to him.

Checking the Story

To check the quality of the story we have to check the six characteristics for a good user story (see [Cohn2004]):

Independent, Negotiable, Valuable, Estimable, Small and Testable.

Independent means that the story should be self-contained; it should not dependent on any other story, if possible. In a given set of user stories, independent stories can be worked on in any order. This story is independent because it doesn’t dependent on another story and technical concepts don’t overlapping. However, definitively there are other stories like the major user task ‘Viewing Documents’ which are not independent. They depend on this story.

A good story captures the essence of a requirement. It is not a contract; it is an invitation for conversation. In this story, there is enough space for discussion and negotiation. The story does not dependent on details.

The value of the story is obvious; it was already assessed above. Before a user can analyse a document, the document must be available in the system. Therefore, it has a fundamental value to the users.

To answer the question if the story is estimable we have first to answer if the story is small enough for planning and implementation. I doubt whether the story is small enough. I think it is more likely of epic size. Let me explain why.

What does this mean ‘import a text file or a document’? I would see a difference between a text file and a document. A text file contains only text. Whereas a document may consist of text, tables and images and can be of any format. Please note, I also differentiate between text and table. Of course a table contains just text, but it has a structure, which consists of header, footer, rows and columns.

Considering the difference between text and documents, I have drawn the conclusion that the user story is not a small one. Since the story is a big one, how am I able to make an estimation? Also ensuring that the story is testable is more difficult. Therefore, I decided to break the story down further according to the content types of a document:

  1. Import a file with a single text paragraph
  2. Import a file with a chapter containing text paragraphs
  3. Import a file with a chapter containing sections and text paragraphs
  4. Import a file with a single table
  5. Import a file with a single image
  6. Import a file containing text and images
  7. Import a file with chapters containing sections with text paragraphs, images and tables

The file format is another point to consider. There are a lot of file formats for documents, like PDF, Word and so on. Should I further break the stories down according to the file format? I don’t think so. Because then the stories and the resulting value are too small.

What is next?

In the next blog post I will pick up the story “Import a file with a single paragraph” and flesh it out. I will especially describe some acceptance criteria for the user story.


[Cohn2004] Mike Cohn, User Stories Applied: For Agile Software Development
(1st edition, Addison-Wesley 2004)

[UserStoryWiki] Wikipedia; ‘User Story’, <>
accessed May 11th, 2017.

[INVESTWiki] Wikipedia, ‘INVEST (mnemonic)’,
accessed May 11th, 2017.

Leave a Reply