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.
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.
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.
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…
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”.
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.