There are several terminologies used in various implementation of agile process such as scrum, kanban etc… Epics, Features and so on… It can be easily confusing at times.. In Agile3 recommendations the approach being taken here is to simply use the terms that are minimally needed and good enough to implement even the most complex project.

Backlog & Features


A backlog is simply a ordered list of features.


The Institute of Electrical and Electronics Engineers defines the term feature in IEEE 829 as "A distinguishing characteristic of a software item (e.g., performance, portability, or functionality)."  It is simply a set of requirements that is independent enough to be developed, tested, released and consumed by users or system.

  • Stories

    A feature can be further broken down into story. A story is ideally again a independent enough functionality that can be tested. However, the main difference is often in real world it is impossible to have every story to be adhere to independent and testable criteria. For example at the beginning of feature you might have a story just for design and to arrive at various breakdown items involved in that feature. OR you might have a story just for backend component while UI story is developed by someone else. As long as Story can be tested and can have a well defined done criteria, it is OK to have a story that is not necessarily consumable yet. Feature is the primary delivery item.

Many agile processes go overboard in dictating what a feature should be, what a story should be, how it should be written. These are unnecessary, confusing and most time people who are dictating these are not even software development experts!

Backlog FAQs

How Features are put-together?

What goes in a Feature?

Following are some key attributes of a good Feature definition:
TitleFeature title in short Eg: Ability to Provide
DescriptionFeature title in short Eg: Ability to Provide
Source BucketFeature title in short Eg: Ability to Provide
Acceptance CriteriaFeature title in short Eg: Ability to Provide
AttachmentsFeature title in short Eg: Ability to Provide

What goes in a Story?

Are features my requirements OR stories?

There is always some confusion as a project manager what would you track as deliverable? Is it Feature OR Story or Both? A simple solution for this issue is keep Feature as deliverable. Stories underneath features are needed due to SDLC where in multiple resources can be working on a feature, simultaneously and it is best practice to always check in code in smaller testable chunks.

If Feature is really small does it need to be broken down into stories?

No. Many people do this due to tool limitations. Ideally this should not be the case.

Who writes a Story? What about duplicate content between feature and story?