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.
