2
votes

Is it possible to have a kind of view of the tasks in Boards/ Sprints of a common backlog but for the different people in teams?

I have already built several teams and gave them the same backlog iteration in "Team Configuration -> Iterations". Now the board/sprint is empty.

If I select the overall area in "Team Configuration -> Areas" it shows the tasks of the backlog, but not in relation to the people in the team, but for all the people. Is there a way to change that?

Thank you!

1

1 Answers

4
votes

Boards (and Backlogs) are for teams by Area

If you are wanting to have a different "view" of the work items in a backlog between teamA and teamB, then the answer is YES. In this case you would have the items in a common backlog and then divide that backlog into sections using areas, allowing for each team to create their own sprints under that common backlog.

Illustrations from our setup

Our project configuration is thus:

You'll notice that DEV and MOAB have visibility into (almost) all other areas, but other teams have visibility only into their area. This is to allow "product owner" teams to create and prioritize items in their area on their backlog and view progress on their board. Of course they can move those items into different board columns and maybe screw some stuff up, but that's when we start to shame them publicly using mass email and the blame tool (read: work items history) (jk). The boards for these teams are used for visibility only.

Our team configurations are thus:

The DEV (and MOAB >> Mother of All Backlogs) area settings are more complicated because we want the area to remain in the product owner teams view for query purposes and to allow them to see their items move across the board (if they're watching). For this reason the default DEV (and MOAB) area is root, and DEV has access to all other team areas and sub-areas.

<Edit>

The DEV teams select view of what is visible to MOAB is driven by the "Backlog Iteration". In the illustrations you'll see that DEV has a backlog iteration path of SYB\Backlog\Planned where MOAB has root SYB.

So, for DEV, only items that are in or under SYB\Backlog\Planned iteration path are visible on its boards, where MOAB sees everything. We have added the SYB\Backlog\Planned iteration to the MOAB settings to allow MOAB team members (planning admins) to drag-n-drop prioritized items from the MOAB backlog (not board) into the DEV team(s) backlog.

Having 2 DEV teams you'll probably employ separate backlog iterations (ie. SYB\Backlog\d1_Planned and SYB\Backlog\d2_Planned) and add those iterations as visible to MOAB for the drag-n-drop functionality.

This setup allows planning admins and BA types to pull from the product backlog and fill the team backlog, while the team leads can plan sprints from the team backlog.

SYB
 +--+ Backlog -> _product owners prioritize their backlog based on the area_
    |
    +--+ d1_Planned -> _team1 leads plan sprints from here_
    |  |
    |  +---\ s1 (sprint)
    |  |
    |  +---\ s2 (sprint)
    |
    +--+ d2_Planned -> _team2 leads plan sprints from here_
       |
       +---\ s1 (stprint)

</Edit>

The only reason we are not using the "include sub-areas" at the root level for DEV and MOAB is because we have an area that no team sees and is for query purposes only: "Released". Moving items to this area after an iteration keeps the closed column of the board(s) trim.

Sub-areas can add further categorization/filtering to the board visibility such as by topic or project, and allow additional charting for queries by project because results queries don't need to be "hierarchical" if they query by area convention.