What is nevertheless mandatory to make your Scrum project a success: “How to correctly fill in your stories?”.

Story fields

First, let’s review their fields in their order of appearance.


Keep the story name as simple and short as possible. It is always better to see the full name of a story with a quick glance. Further details should rather be provided in the description/notes if needed.


There are 3 types of stories in iceScrum: User Stories, Technical Stories and Defect Stories. The type is visually identifiable on story post-its thanks to a small icon on the top right. This visual categorization helps manage stories when you have a large backlog. Charts will show the proportions of stories by type over time. Of course, it is better for your project to have less and less defects and to keep technical stories to a minimum!

Affected version

If you chose to create a Defect story, then this new field is displayed. Indicate the version of your product that is affected by the defect to make it easy to maintain traceability, reproduce the bug and fix it.


If you have been following our documentation on how to start with iceScrum, you have probably created features in your project (if you did not… you really should create some!). Features define categories of stories so they help classify them and refine the vision of your product. You may know about “epic”, “feature” is just another name for the same concept! Each feature gives its color to its stories so it is also a visual facilitator to identify them. Features can be planned into releases thanks to the Roadmap in order to share the future of your product with your Stakeholders.

The story properties panel
Story fields in the create / update form

Depends on

It may be useful to indicate that a story depends on another. Such story will not be able to have a state higher than the story it depends on and it cannot have a higher priority in the Backlog.


In the description you describe the goal of the story. This is fundamental to well understand the story and follow the right direction in your work. The description is pre-filled with a template with 3 sentences:
– ”As a…”
– ”I want to…”
– ”In order to…”
Indicate a user (you can autocomplete an actor created in the Actor view by typing the letter ‘a’), a wish and a purpose in those sentences to make it clear who will execute the story, what they want and for what purpose. Understanding and stating the purpose may be hard, but it is worth it because it can lead to new ideas to solve the problems faced by your users.


Tags further helps categorize stories, but contrary to Type/Feature, you can have define many tags on a story and there is no predefined meaning behind them. That means that you can add custom meta-data to a story, e.g. in reference to another tool or framework. You can search for stories associated to a tag either in a view by typing “tag:” in the contextual search bar, or in the Finder view. It is helpful to avoid spending too much time looking for stories in a big project.


Add and share documents relevant to your story understanding, documents you are working on, etc. For instance, add a screenshot of the bug in a Defect Story or a UI mock-up in a User Story.


The notes field helps you freely provide information that doesn’t fit in the description (e.g. meta-data, external links, examples…). You can use markup to format the text at your will.

Story items

In addition to their properties, story can be further defined thanks to Comments and Acceptance tests. To add them on a story, open its details (either by the “Details” menu or by clicking on the story ID). We will not review tasks here because they don’t define the story, they rather define the work required to deliver the story!


Comments are text fields associated with a date and an author. Thus, they serve as a platform for discussions that are relevant to the story. They are specially useful for distributed team, but they are also interesting for any team to keep track of past communication. For example, if the story is created by a Stakeholder, the Product Owner can ask for further details by adding a comment (the creator will receive an email). Alternatively, a developer can ask for clarifications regarding a business issue faced when implementing the story.

Acceptance tests

Acceptance test define conditions for a story to be considered “done”. Writing them requires discussing and understanding precisely the details of a story and its boundaries, which will help estimate it. Acceptance tests should be as precise and specific as possible, providing real sets of values that can be used to validate the behavior implemented by the team and decide whether the story is done. When the story is in progress, the state of its acceptance tests can be changed to reflect their result, read more about it on this blog post: https://www.icescrum.com/blog/acceptance-test-states/

Now your story is correctly filled in, it is clear and visually identifiable, ready to be estimated, prioritized and planned! If you want to read more about the topic and get closer to create the perfect stories you can refer to the “INVEST” mnemonic by Bill Wake.