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.
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!
How Features are put-together?
What goes in a Feature?
Following are some key attributes of a good Feature definition:
TitleFeature title in shortEg: Ability to Provide
DescriptionFeature title in shortEg: Ability to Provide
Source BucketFeature title in shortEg: Ability to Provide
Acceptance CriteriaFeature title in shortEg: Ability to Provide
AttachmentsFeature title in shortEg: 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.