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?
Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.Sign up to join this community
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:
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.
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.
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).
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.
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.
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."