1

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?

1
  • 4
    You're going to have to better define what you mean by "backlog". For example, Scrum has two backlogs - the Product Backlog and the Sprint Backlog. Other methodologies may have various types of product, release, and iteration backlogs. The type of work item in each backlog will vary by process methodology.
    – Thomas Owens
    Feb 23 at 17:06
2

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.

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.

3
  • Many thanks Yaraslav. 'Backlog items should be prioritized using common scale – the order these to be picked by development team and worked on'. Should it not be only user stories priority selected by the Product Owner? Development Team to work on how tasks to make these come true get done?
    – colgor
    Mar 3 at 16:23
  • @colgor I think there should be single person responsible for priorities of all items in the single backlog. This person's judgement should be influenced by all project's stakeholders including development team using all sorts of reasons (money, vision, technology, short/long term strategy, total cost of ownership, etc.) but it is his/her decision to determine the final order. Because this person is the Product Owner. Mar 4 at 18:21
  • Thanks I get that priority is decided by product owner definitely for a product backlog. It seems you are saying there should be a single backlog for both products and tasks that the product owner decides priority on? I had thought the tasks would have been decided on by the development team.
    – colgor
    Mar 5 at 19:38
1

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.

2
  • Thank you very much all. The product backlog (for user stories) then a sprint backlog (for tasks to make stories come true) tells me backlog is a correct term and can be used for both but I have to make clear the type of backlog when I'm discussing or using them..
    – colgor
    Feb 24 at 14:51
  • Re. WBS. Could a mix of the two be used where a gannt chart displays all the various sprints of different projects that are are going on (that might have WBS of tasks effectively within)? I've not seen an example of one yet but I have heard of roadmaps and expect these serve a similar purpose but in a different way?
    – colgor
    Mar 3 at 16:03
1

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.

1

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."

1
  • That’s really interesting Mike thank you. I always thought similar but never put it into words as such. I am curious if you or others are aware of why the term backlog was used?
    – colgor
    Mar 30 at 23:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.