How to organize the Team Sprints in Jira

As new teams shortly will start there first sprints. The question is, how this should be organized in Jira. @aertmann sent me some questions from the prioritizer meeting. I’ve created a copy of the Flow / Neos Team board (https://jira.neos.io/secure/RapidBoard.jspa?rapidView=36&sprint=15) and here are my thoughts on that.

1. we need separate overviews for each team so each team only needs to see a limited set of issues
My suggestions is to add sprints, named after the teams. For example: „Team Minions Sprint 1“ . The issues will be added to the sprint. By selecting his teams current sprint, every team member can focus on his teams issues.

2. We need a way to have individual tasks as well as epics with stories in the same board, if possible
Stories and Tasks are shown on the board, Epics can be selected in left epic panel.

3. There will be some projects that multiple teams will work on, so we need to figure out how we organize that… e.g. the website where different aspects will be in separate teams
A story can be only assigned to one sprint and thus to one team. But that should be ok. A big epic, like relaunching the website should be divided in several stories which then can be spread to separate teams.

Then there’s the question what to do with the release planning the current boards are based on, if we just drop that entirely… might make sense, since it only really works for the current sprint and I think we’ll do that in another way in the future
A release will consist of several sprints done by different teams. I would suggest to use Jiras Target versions to categorize items that should go to the next version. A separate board / filter can the be used to get an overview of the open Tasks for the next release.

1 Like

Thanks for setting up a new board. Pretty that setup can work.

As far as I understood, we don’t plan to do scoped sprints but more fluid. Meaning we don’t need “Team Minions Sprint 1”, but just a “Team Minions” sprint. At least I think that is more flexible, allowing projects to be pulled in when needed and not setting end dates for sprints. Although that could be up to each team, how they prefer to work.

Personally I prefer the grouping of EPIC like it’s done in https://jira.neos.io/secure/RapidBoard.jspa?rapidView=19&sprint=16. In our team we decided only to have a couple of projects simultaneously, which provide a clear overview.

I don’t see that? Only in planning mode.

Yep, already started doing that with that project actually.

Sounds like a good idea.

2. We need a way to have individual tasks as well as epics with stories in the same board, if possible

To clarify, this is regarding kitchen duties. So that can be bugfixes, reviews and other tasks.

Grouping them like it’s done in https://jira.neos.io/secure/RapidBoard.jspa?rapidView=19&sprint=16 under “Other Features” could work.

Alternatively we create a kitchen duty epic to group them.

1 Like

Didn’t knew that. But for me, the concept of defined portions of work and time - as sprints are - is really an asset when working in agile teams. So I would prefer having a sprint done, closing it and starting over again with a new one.

We could use an own issue category like “tasks” for the Jira representation of kitchen duties. I would not use epics to group such things. In my opinion Epics also should have a defined scope like stories and thus a defined lifetime in Jira.

If need another thing to hold these issues together, I would prefer Categories over epics.

Hey Daniel and Aske,

I very much like your ideas! Looking forward to their implementation!

All the best,
Sebastian

i think this is the diffence between kanban and scrum.

if you set a defined set of stories/tasks within a defined slot of time this is definitely the way to go.

so my question is: do your team plan to do scrum cycles, if so then you should adapt your board to this needs like u suggest.
if another team does it with an continuous input of stories/tasks without time cycles but continously - they shouldn’t.

so just have a look at the process in your team and than adapt the board to your preferred working mode, which not necessaryly has to be the same in every team…

just my 2 cent
cheers gina

My 2 cents about the vocabulary that we can/need use.

Based on our “instable” availability, I not in favor of using any “scrum” like vocabulary, we can not support real sprint, we don’t have product owner, scrum master, …

I agree to be agile, but we need to have a vocabulary that we can respect, and “kanban” (or scrumban) fit more what we can do, read “try to push every thing from left to right, as fast as possible”.

even better pull everything from the less right to the more right (meaning you always have a look which is the most right ticket).

Hey everyone, thanks for the input.

Seems there’s different opinions on how we want to organize the team boards (scoped or not).

Good news is that scoped and unscoped can work together just fine.

We discussed it in our team and from my understanding so did the other teams. Our team concluded to try out the non scoped approach and see how it works for us.

Since we need the boards to start working I created the following proposal based on the feedback received so far.

As @kdambekalns summarizes:

And set it up.

Team Boards

Currently only two teams have boards since the last team didn’t have anything in their board, so the sprint couldn’t be started.

Issues are grouped by epic and tasks without an epic will be grouped in the bottom.

Additionally I replaced the old version overview board with a new one Neos & Flow Versions

I think these boards can work for us, so let’s try and see and adapt if necessary. Also feedback welcome of course.