Build Backlog

Backlog & Features

Backlog

A backlog is simply a ordered list of features.

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?

 

Backlog Process

What goes in a Feature?

Following are some key attributes of a good Feature definition:

AttributeDescriptionExample

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.

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