Backlog - Is this to (i) List outstanding 'user stories' or (ii) List outstanding 'tasks' or (iii) Can one be used for both purposes?

Question

Any good links to example backlogs would be appreciated.

I understand from a backlog user stories can be refined, added, removed and so on.

I'd imagine tasks or a WBS would be constant or tweaked by the team responsible for the sprint?

Answer 1

The Scrum Guide does not say that a backlog item has to be in the form of a user story. You may write the backlog item the way you like, or more precisely the way the team prefers it to be.

Answer 2

Backlog should contain all workable items

According to Scrum Guide:

Product Backlog is the single source of work undertaken by the Scrum Team.

So in my opinion the Backlog should contain all workable items including but not limited to:

• user stories from all your stakeholders
  • this is business functionality
• risk mitigation items
  • eg. when we need to do some work or investigation in order to remove uncertainty / mitigate project risk
• enablers (also called 'spikes' in XP)
  • eg. research aimed at removing uncertainty and enabling further complex feature development
  • these build knowledge (as opposed to user stories that build functionality)
• tasks to implement non-functional requirements
  • eg. performance, security, maintainability
• defects, production issues
• technical debt and refactoring activities

Working with Backlog

Backlog items should be prioritized using common scale – the order these to be picked by development team and worked on.

Any of these can be added, refined and expanded by anybody on your team, while only the Product Owner should maintain the priority order. Removal of items should only be done when agreed by all members.

There should be single backlog

This is important. If you have separate backlogs / lists for the items mentioned above and not estimate and plan for all of them together you would have hidden conflicts between project members and would likely fall behind in some areas.

Answer 3

In Scrum, backlog is a list of outstanding user stories

You are using the terms backlog, user stories and sprint. So, I will answer this in the context of Scrum. Scrum is recommended for projects, such as software development, where requirements can change late in the cycle and technology could throw some unpredictable challenges.

Let us say that you want to build a product. The Product Owner will create a list of user stories that will roll up to the vision of the product. Scrum Guide calls the user stories as Product Backlog Items (PBI).

Here is a sample backlog for a job posting site:

As a site member (?), I can scroll through a listing of jobs, so I can see if there any I’m interested in. (There won’t be enough at first to justify search fields.)

As someone who wants to hire, I can post a help wanted ad so that I can attract candidates.

As a site admin, I need to approve each help wanted ad before it gets to the site so that we’re sure of the quality of jobs being listed. Note: May not be needed long term.

The dev team decomposes the Product Backlog items chosen for that sprint into smaller work items, often referred to as tasks, at the time of sprint planning (not before).

Work Breakdown Structure (WBS) is a term often used in the context of more predictive or planned approach projects such as constructing a building or moving a data center to another location. These projects are typically managed using a Gantt Chart.

Answer 4

I generally agree with Ashok's post above, but I find that in actual practice a "task-based view" and a "story-based view" often exist side-by-side, and that "tasks" are not strictly tied to "stories." Because they don't have to be.

I find that "a 'user story' is exactly that: an expression from a hypothetical-user's point of view." Very useful, as far as it goes.

Creating a software feature which fully implements that "story," however, might involve the creation of many "tasks," not all of which can be done at the same time or "in a single sprint." Therefore, it proves to be valuable to look at the undertaking from both perspectives, using "stories" to guide the "tasks."

"Tasks," and "work breakdown" in general, prove to be very important when you have a large team or a team containing specialists or SMEs, such that the decision of exactly how to "implement a story," and by which team members, is not altogether obvious.

Answer 5

In my opinion, "backlog" is an unfortunate choice of terminology, because what we should be referring-to here is not really a "backlog" at all – in the human sense of "falling behind."

Apple uses an internal management system they call RADAR, and there are (or, used to be) posters on the walls(!) which said: "Put it on the RADAR." And, to me, "put it on the radar" is a good way to describe what I consider to be "the backlog's" true purpose. It is to make the project members, the project leaders, management and stakeholders formally aware of everything that needs to be attended to. It also provides a mechanism for tracking progress and completion for each item – "whatever that actually may mean." But it may actually consist of many different sub-lists containing different "types" of things.

Entries on the backlog roster might need to be understood in the context of other things, such as "work breakdown structures." Because a "task" that a development team might be working on might be tangentally related to several "user stories," or it might be "foundation work." Still, the most important thing is that, whatever it is, it is "on the radar."