I have a few questions on JIRA and I was wondering if you folks could share your thoughts on this:
We are evaluating JIRA for use as an agile development management tool and for issue tracking. Right now we have the OnDemand trial but I've tried Download as well and that is certainly an option.
We have several independent business units that will be using JIRA within our organization. Most of the time each business unit works on its own Backlog and only solves issues related to its own Products/Projects. Each business unit has several projects, some of which are active at the same time. Occasionally, people from different business units have to work together on a single cross-functional project/product so they share the same Backlog at those times. Our management also wants to see the entire organization’s backlog and track progress on it as a whole. I believe the answer to most of the questions above is in “Federated JIRA”. I however have a few more questions from a single business unit’s operational perspective:
Within the organization, our business unit creates a specific set of Products. It consists of three separate teams. Each team is in a different part of the world. Each team has distinct expertise, and often distinct responsibilities, but they do sometimes work together with the other teams within our business unit and sometimes with teams from other business units.
Each of our teams has its own Scrum Board and Sprint. However, the backlog is shared between each team. In other words, while each team works in its own sprint, the sprint itself can consist of stories from multiple projects.
Coming to the projects, each project consists of multiple Epics and Stories. Each project can also have multiple releases if needed. For instance, Project Mars may have several releases for Mars Lander e.g. release 1.1, 1.2, 2.1 and so forth.
We have a Product Owner that prioritizes the backlog. We have our backlog segregated by Project because of the large number of stories for most projects e.g. some projects may have 200 individual stories. The product owner prioritizes each Project’s backlog individually and the team estimates the effort for each story as well. During Sprint Planning, the product owner then pulls in the highest priority stories from the different Projects based on business need.
We have three sprint planning sessions because we have three teams. Each team’s sprint consists of stories from the projects that fall within their expertise.
At any given time we have:
§Three sprints running simultaneously, one for each of our team’s
§Stories from multiple projects being worked upon in one Sprint
§Each team working on stories from any of the projects
How would you setup JIRA so that we can track the progress of each Release within a Project and also of each Epic within the Release? We would also like to track overall progress on each Project.
Ideally I want to know how long each Release and Epic is expected to take for completion based on the Story Points (Effort) that have been identified and the average Velocity of the team (or set of individuals from various teams) working on the project.
How would you setup JIRA so that each Team can have its own Sprint? I thought of setting up a separate Scrum Board for each team. This however was quite cumbersome because I had to manually configure each Project to show up on each of the three Scrum Boards. Without doing this configuration I could not pull in stories from multiple projects into the Sprint.
It was also quite awful because I could not see a clear distinction between stories from different projects, so that all of my 400+ stories appeared one after the other in the backlog. Can I configure the Backlog (Scrum Board) to display stories grouped together by Project or Project> Release? I do see that Epics can be easily identified. The project key prefix is absolutely inadequate in this regard. A simply group- or filter- by Project and Release would be really helpful on the Scrum Board.
We can change the way we work and have just one sprint for all three teams i.e. one shared sprint but that still does not provide an adequate answer to the questions above.
Please do not say that 400 stories are too many and that we will never be able to get all of those done so we must change the way we work. That statement is usually a result of inadequate information. We have successfully completed releases with several hundred stories on time. We cannot make each release shorter, or create a new release after every few months because: 1) it is very expensive to have each release approved by a 3<sup>rd</sup>party which is a requirement in our line of business, 2) business drivers may require some features sooner than others so we may package a release with only 2 or 3 very high value stories.
Thank you for taking the time to detail your challenges.
I recommend configuring projects using our guidelines which follows below.
More specifically, once projects are created and configured along with appropriate permissions, the rapid boards that would follow would be associated to each project accordingly (1-to-1 or 1-to-many). The end result has the effect of partioning data so access is only visible to those that are deemed appropriate.
Here are guidelines for reference:
I hope this response helps get you on the right path.
Jason | Atlassian
The grouping tutorial is nice but only works as is if your projects don't span teams or if you have a team that works severl projects. We have the latter so much like we have feature teams we also have project teams. For example Red Team owns Feater A and Feature B but also all of small Project4.
Each project represents and actual project. Each team then gets a scrum board based on a filter that include the projects they are able to work. We have instances when a project has single team access and we have a project that has muti-team access.
Each team then has their own backlog to pull from. Only issue is that some stories will show up in multiple places. We handle this by add "Team Assignment" to our Definition of Ready. You can then actually change the Scrum Boards to be filterred by Team (we use component).
Now you could do all of this with quickFilters on a single board but it gets pretty congested running 4 active sprints in the backlog. The benefit would be a unified back log for prioritizing. We also do the with a Master Scrum Board that shows all projects in one place.
Build different views to the data for different needs. This has made multiple projects across mltiple teams easier and allows us to keep teams together instead of assigning them a project that doesn't have the flow to support the whole team. With this approach the under utilized teams can assist where needed while still having ownership of their core features and projects.
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG