Welcome to the Jazz Community Forum
Ordered backlog
Hi, I'm trying to figure out how to represent a per-development-line
backlog. Maybe this has been documented somewhere, but the best I've
come up with is to create an iteration called 'backlog' as the last
direct child of the development line. It will always be the last
iteration and will never be started. Teams can create plan documents
for the 'backlog iteration' and order the work items as any other plan
document. Once a real iteration is complete, the backlog is inspected
and work moved from it to the next real iteration. A shortcoming is new
work items marked as unassigned don't go on the backlog - they have to
be put there manually by changing the 'planned for' field.
Has anyone found a better way to represent the backlog? (btw: I'm not a
fan of using a query because the order of the results is not down to the
product owner).
Any observations, good or bad appreciated,
Jeremy
backlog. Maybe this has been documented somewhere, but the best I've
come up with is to create an iteration called 'backlog' as the last
direct child of the development line. It will always be the last
iteration and will never be started. Teams can create plan documents
for the 'backlog iteration' and order the work items as any other plan
document. Once a real iteration is complete, the backlog is inspected
and work moved from it to the next real iteration. A shortcoming is new
work items marked as unassigned don't go on the backlog - they have to
be put there manually by changing the 'planned for' field.
Has anyone found a better way to represent the backlog? (btw: I'm not a
fan of using a query because the order of the results is not down to the
product owner).
Any observations, good or bad appreciated,
Jeremy
2 answers
Jeremy Hughes wrote:
Recently, a similar topic has been discussed here:
news://news.jazz.net:119/gg1jgd$qdg$1@localhost.localdomain.
For 2.0 we are going to improve our support for SCRUM, especially in
terms of backlog management. In the first cut (2.0M1) we will offer
release plans which also show top-level work items for child iterations.
https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/64178
https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/64126
Feedback on these topics is greatly appreciated.
--
Cheers, Johannes
Agile Planning Team
Has anyone found a better way to represent the backlog? (btw: I'm not a
fan of using a query because the order of the results is not down to the
product owner).
Any observations, good or bad appreciated,
Jeremy
Recently, a similar topic has been discussed here:
news://news.jazz.net:119/gg1jgd$qdg$1@localhost.localdomain.
For 2.0 we are going to improve our support for SCRUM, especially in
terms of backlog management. In the first cut (2.0M1) we will offer
release plans which also show top-level work items for child iterations.
https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/64178
https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/64126
Feedback on these topics is greatly appreciated.
--
Cheers, Johannes
Agile Planning Team
Hi Jermey,
even with the improvements Johannes pointed out I still recommend that
you have an iteration capturing work that is not planned for a specific
release/iteration. We in Jazz use the Post X iteration for this purpose
a unplanned iteration (e.g an iteration without start end/date) named
backlog is definitely another good name.
The reason is that every new work item filed against a component is
planned by default for unassigned. Treating all work in unassigned as
the back log might be misleading. IMO it requires an explicit action of
someone from the team to decide that the work items is a valid backlog
item.
Dirk Baeumer
Agile Planning Component.
Jeremy Hughes wrote:
even with the improvements Johannes pointed out I still recommend that
you have an iteration capturing work that is not planned for a specific
release/iteration. We in Jazz use the Post X iteration for this purpose
a unplanned iteration (e.g an iteration without start end/date) named
backlog is definitely another good name.
The reason is that every new work item filed against a component is
planned by default for unassigned. Treating all work in unassigned as
the back log might be misleading. IMO it requires an explicit action of
someone from the team to decide that the work items is a valid backlog
item.
Dirk Baeumer
Agile Planning Component.
Jeremy Hughes wrote:
Hi, I'm trying to figure out how to represent a per-development-line
backlog. Maybe this has been documented somewhere, but the best I've
come up with is to create an iteration called 'backlog' as the last
direct child of the development line. It will always be the last
iteration and will never be started. Teams can create plan documents
for the 'backlog iteration' and order the work items as any other plan
document. Once a real iteration is complete, the backlog is inspected
and work moved from it to the next real iteration. A shortcoming is new
work items marked as unassigned don't go on the backlog - they have to
be put there manually by changing the 'planned for' field.
Has anyone found a better way to represent the backlog? (btw: I'm not a
fan of using a query because the order of the results is not down to the
product owner).
Any observations, good or bad appreciated,
Jeremy