Business Project, Multiple Boards but not able to have multiple sprints

[Philipp Dewies]

Hello,

I'm confused. I Have a business project (Jira Server 7.9) and created two different boards. Board1 and Board2.

I thought it would work as follows:

I have two different teams. One board for each team. Every team should be able to go to their board, put together some issues from the backlog (create a sprint) and start their very own sprint. Every team should be able to monitor their progress with the burndown chart.

What really happened:

I start a sprint in Board1. I'm able to see the progress in the burndown chart from Board1. All good. The problem is: When I switch to Board2 it looks exactly like Board1. I can see the Sprint from Board1, I can also see the burndown chart from sprint i created in Board1 and I'm not able to start another sprint. Due to this fact I'm confused: Why I whould use two different boards when there is acutally not a difference at all?

Can anybody explain what I'm doing wrong and give me some advice?

Thank you so much in advance

[Scott Theus · Accepted solution]

Hi Philipp, 

Can you tell me how you are tracking your backlog? It sounds like it it a shared backlog that both teams pull from and that exists in both scrum boards, an that your workflow looks something like To do...In process...Done.

If this is the case, then I suggest adding a third board for the overall product backlog, and making it a Kanban board with an additional status column of "Backlog." That way anything waiting for a team to grab and move into a sprint sits in a general pool, while the two Scrum boards have a backlog of "to do" items for that team that they can move through the workflow and manage in a separate sprint backlog. 

There are other ways to separate it out, but this is how I've managed Product Backlogs with more than one Scrum team in the past.

Hope this helps, 

-Scott

[Thomas Schlegel]

Hi @Philipp Dewies,

I think, you have the same Filter query on both of your boards. Therefore, the same issues are included in both boards. 

With such a configuration, you'll see every sprint, an issue of the board is involved. And it doesn't matter, in which board the sprint was started.

So, I would recommend the following:

• Start two parallell sprints within the same board or
• Change your filter query, so that an issue belongs either to the one or to the other board, but never to both (e.g. create two components and seperate on them) 

[Philipp Dewies]

Hallo Thomas,

ich antworte gradmal auf Deutsch, hoffe das ist okay. Bin ganz neu bei Jira und stehe seit Tagen auf dem Schlauch und verzweifel komplett. Danke schonmal für die schnelle Antwort! Ich wäre dir super dankbar wenn du mir weiterhin helfen kannst.

Also sagst du, dass der Sinn von Boards folgender ist: Du erstellst gewisse Suchfilter für jedes Board, so dass dir auf jedem Board nur die Issues angezeigt werden die deinen Suchkriterien entsprechen? Falls ja, wie genau mache ich das am besten?

Im Projekt gibt es mehrere Arbeitspunkte und mein Plan war für jeden Arbeitspunkt (AP) ein Board zu erstellen um jedem Team welches jeweils an einem AP arbeitet die Möglichkeit zu geben eigene Sprints zu erstellen und den Arbeitsfortschritt auf dem eigenen Burndownchart zu überprüfen. Tatsächlich gibt es übrigens mehr als 100AP's und über 100Mitarbeiter. Wollte es oben nur möglichst simple halten um das Problem zu verdeutlichen.  Hast du eine Idee wie ich das am besten Umsetze? Es gibt nur wenige (im Prinzip vernachlässigbar wenige) Abhängigkeiten zwischen den einzelnen AP's (falls diese Information noch wichtig ist).

Es wäre super super toll wenn du mir dabei helfen kannst Jira für das Projekt ans Laufen zu bekommen!

Vielen Dank und Grüße aus Aachen,

Philipp

[Thomas Schlegel]

Hallo Philipp,

ich melde mich morgen, jetzt ist erst mal Feierabend.

Viele Grüße 

Thomas

[Thomas Schlegel]

Moin Philipp,

also 100 Boards für ein Projekt zu bauen halte ich für keine gute Idee. Arbeiten diese Teams denn unabhängig voneinander? Müssen sie auf dem selben Projekt arbeiten?

Ich würde 

• in Jira mehrere Projekte erstellen, vielleicht nicht eines für jedes AP, aber wenn es nötig ist...  - du kannst ja auch sehr einfach beim Erstellen eines Projektes ein anderes Projekt als Vorlage benutzen.
• für jedes Projekt ein Board erstellen

Ist natürlich aufwändig, so viele Projekte und Boards zu erstellen. Aber das macht das ganze auch übersichtlicher. 

[Philipp Dewies]

Hi Thomas,

danke für die Antwort. Die Teams arbeiten größtenteils unabhängig voneinander, das ist richtig.

Frage zur Unterteilung der Issues:

Wenn ich jetzt ein Projekt erstelle (beispielsweise AP1), würde ich für den Unterpunkt AP1.1 ein Component erstellen, für AP1.2 ein weiteres component. Mit components zu arbeiten und die Issues auf Unterpunkte zu separieren ist am sinnvollsten in dem Fall, oder?

Vielen Dank und Grüße

[Thomas Schlegel]

Hallo @Philipp Dewies,

ja, das klingt vernünftig. Du kannst dann auch auf Komponentenebene einzelne Boards erstellen. Es muss dann nur die Komponente in den Boardfilter mit aufgenommen werden.

[Philipp Dewies]

Hi @Thomas Schlegel,

vielen Dank für die Antwort Thomas! Das bedeutet, ich gehe in die Konfiguration des jeweiligen Boards und erstelle dort einen Filter wo ich einfach alles zulasse und nur nach z.B. dem Compontent "AP 1.1" filtere? Ich möchte, dass der User auf das Board geht und nicht erst diverse Filter auswählen muss, sondern automatisch nur die Issues angezeigt bekommt die seinen Unterarbeitspaket betreffen.  Vielleicht kannst du mir erklären wie ich das am besten umsetze.

Wieso ich das Frage und nicht einfach ausprobiere ist, dass ich nicht ausreichende Berechtigungen habe. Ich bin zwar "Administrator" Aber ich kann z.B. keine Boards oder Projekte erstellen.

Noch ein weitere Frage: Sollte ich noch zusätzlich mit epics arbeiten? Gibt es da besonders sinnvolle Cases wo ich das brauche, oder reichen die Components zur Unterteilung der Arbeitspakete erstmal?

Danke für deine Hilfe =)

Philipp

[Thomas Schlegel]

Hallo Philipp,

Epics sind sinnvoll, um die Issues eines Boards weiter filtern zu können. Nach Scrum müssen Stories innerhalb eines Sprints erledigt sein. Epics nicht. Daher legen wir größer, langandauernde Themen als Epic an, denen dann die Stories zugeordnet werden.

Ein Board hat immer schon einen Filter. Der ist meist "project = XXX", also nichts anderes als ein Filter auf das Projekt. 

Diesen Filter kannst du ändern, z.B. auf "project = XXX and component = AP 1.1". Dazu musst du allerdings Board-Administrator sein. Mit dem neuen Filter werden nur noch Issues auf dem Board angezeigt, die als Komponente AP1.1 haben.

Aufwändig wird's dann halt, wenn du 100 Boards erstellen und anpassen musst.

[Philipp Dewies]

Hi Thomas,

erneut vielen Dank für deine Hilfe. Noch einmal zwei Verständnisfragen:

1) Also verstehe ich richtig: Sowohl Epics als auch Stories sind eigenständige Objekte in einem Softwareboard.

• Epics dienen zur Gliederung einzelner Themengebiete die über einen längeren bzw. unbestimmten Zeitraum bearbeitet werden (epic Beispiel: "Vorbereitung monatliches Meeting")? Man erstellt Epics um "Menüpunkte" zu erstellen denen man Issues zuordnen kann, richtig?
• Stories haben einen ähnlichen Zweck. Man möchte mit einer Story einen schriftlich fixierten Rahmen schaffen um Anforderungen und Zweck eines oder mehrer Issues zu verdeutlichen. Stories werden genau wie Issues in einen Sprint gelegt um neben den eigentlichen Aufgaben (Issues) eine kurze Beschreibung und Zweck  bzgl. dieser Aufgaben zu liefern. Beinhaltet eine Story die Beschreibung für ein einzelnes Issue oder für mehrere Issues oder für den ganzen Sprint? Man würde eine Story während des Sprints in die "erledigt" (done)-Spalte schieben wenn alle Issues die von der Story beschrieben werden abgearbeitet sind, richtig?

2) Unterschied zwischen: A) 20Projekte und 10Boards pro Projekt VS. B) 1 Projekt und 200Boards:

Der einzige Unterschied wäre doch folgender: Wenn ich mit Möglichkeit A einen Sprint in einem meiner Projekte erstellen will sehe ich im Backlog lediglich die Issues/Stories die ich im aktuellen Projekt habe, richtig?

Mit Möglichkeit B (also nur ein riesen Projekt) würde ich bei der Erstellung von Sprints, sämtliche Issues/Stories des ganzen Projekts im Backlog sehen, richtig?

Ist das der einzige Unterschied, oder gibt es weitere Gründe FÜR mehrere Projekte um das ganze übersichtlicher zu gestalten.

Vielen Dank!

Philipp

[Alec Jasanovsky]

Oops, misunderstood. 

agreed w/ scott