Features represent parts of the product that bring significant value to its users. Features are usually too big to big worked on directly so they are broken down into smaller business units: stories. As far as planning is concerned, producing a feature is expected to last several sprints. Features help materialize the vision and share it to the agile team and the stakeholders.

In iceScrum, features can be given a unique color and each story associated to a feature will get the same color. This is an effective way to visually discriminate stories, e.g. to know the feature that will receive the most effort within a sprint.

The Feature workflow consists in three states:

• Todo: has no story with state above Planned,
• In progress: has not been marked as Done and has at least one story with state above Planned
• Done: has all its stories Done and has been marked as Done (either manually or automatically). No story can be created on a Done feature.

Learn more about feature permissions in the dedicated documentation.

The concept of a high level business item is sometimes called “Epic”, in iceScrum we call it “Feature”. The word “epic” also exists in iceScrum but it has a different meaning: epic stories are stories that are too big to fit into a sprint so they should be split into smaller ones. Features stay there and help categorize stories, while epic stories are temporary: they are replaced by the resulting stories.

A story is expected to be done within a sprint so they must be as small a possible.

In iceScrum a story can be of 3 types:

• User story: a story that brings value to stakeholders / users, such as a new function or an improvement in the product.
• Defect: something removing value that should be fixed, usually what is called a bug.
• Technical story: a story that brings value to the team, e.g. to reduce risk, increase technical knowledge, improve technical quality…
• Epic story: a story that is too big to fit into a sprint, so it should be split before being planned.

In iceScrum a story will go through at most 8 states in its lifetime :

• Suggested: Each idea is first submitted in the sandbox.
• Accepted: If it is acknowledged as a valuable idea for the project by the Product Owner, it is accepted to the product backlog.
• Estimated: Once the team has estimated the effort to achieve the story, it is ready to be planned.
• Planned: The story is planned in sprint that is not in progress yet.
• In progress: The story is part of the current sprint
• In review: The technical work is done and the story is being tested / validated (only with the Story workflow App)
• Done: The story has been validated by the Product Owner
• Frozen: The story provides value but doesn’t fit the current vision (only with the Story workflow App)

Below is a simplified representation of the story Workflow. It includes story states, the story location for each state, and roles who are allowed to go from one state to another. Some actions allow jumping several states, but for the sake of simplicity they are not shown in this diagram.

Learn more about story permissions in the dedicated documentation.

Acceptance tests (often named acceptance criteria) are attached to a story to define what exactly is expected from this story. They are the place where the business rules and constraints related to this story are defined. They should be written for each user stories before the beginning of the sprint. The team is thus aware of the expected result as soon as they start working on this story.

When the sprint is in progress, the state of an acceptance test can be manually changed:

• To check (default)
• Failed
• Success

Until a story is In progress, all its acceptance tests are To check. Once a story is Done, all its acceptances tests are Success.

Learn more about acceptance test permissions in the dedicated documentation.

In order to produce a story, the team needs to perform some activities structured as Tasks. As opposed to the other items presented here, a task is not part of the outcome of the project, it is rather the mean to produce the outcome. A task can be done by a single team member, while producing a story is the responsibility of the whole team. In addition to story tasks, tasks can be created outside a story as urgent tasks and recurrent tasks. The tasks attached to a story may evolve as the story progress.

When the sprint is in progress, the state of a task can be manually changed by drag and drop:

• Todo (default)
• In progress
• Done

Once a story is Done, all its tasks are Done.

Learn more about task permissions in the dedicated documentation.