We are now starting development using Jira.
I currently have a team of 5 software engineers who can work on different projects and also on the same project a few times. What is the recommendation to use Jira? Do I create projects by "projects" or by team? How does the board formatting work in this case? When would you use an Epic?
I would like to understand cases of using Jira for you.
You should create a project per a project in your organisation, most likely it will reflect your organization structure. When it comes to the boards, you can display issues from several different projects on a single board so all members of your team can do a standup meeting without boards switching (Read more about boards here).
To the epics, consider creating an epic if you have a large user story that you want to split up into smaller chunks. You could also create an epic if you notice a pattern amongst several user stories you've created, and you want to bundle them into one group (you can read more here and here).
Related
I am to set up Jira in my organization and there arise some questions, for which I could not yet come to a, for me convincing, decision... may you give me your opinion, what the best configuration would be?
(I will be talking here about projects but it might be found out, that should later be boards or whatever)
I have requested my org the creation of a Jira account for my department, and as seen from the settings, I got created a Board associated to me as an admin
We are a team of 15 people in the department
We want to start setting 10 different projects, some might be related to the other ones but still keep an individual sense, thus, each should have its own Backlog
The scheme of the projects should all be the same (notifications, workflow, issue types...). Ideally, if changing something lately in the scheme, all projects should actualize to this automatically
We will be all teammates allowed to work on all projects within the department, always, no restrictions
We want all to be able to check for the statistics etc. related to any project in the most easiest way
Users want to have on their board (screen) all projects and tasks, in the order planned for them to be performed, don't matter if they belong to different projects. Desired view would not be a flatt Kanban but issues being classified by Project > Epic > Sprint
The ideas I came up with are:
(1) Me --> Board --> 1 JiraProject --> n Epics (each = OurProject)
Having just one project (namely, the name of my department) and then create one Epic for each "real" project we want to handle. Then, to each Epic create the Issues related to each of our real projects. The problem with this is, that we would need a second level of Epics to suborder into each of the main Epics (representing our real projects) so that we can group their issues into logical parts of the project. This second level of Epics seems to me not to be possible. Additionally, this approach will just provide us with one Backlog common for all our projects (here provided as Epics).
(2) Me --> Board --> n JiraProjects (= OurProjects) --> each JiraProject
This seems to me to be the best approach, but has the inconvenience, that when a person has to work on several projects he has not the insight of the order of the tasks he has to perform, nor if any of these collide in time with any other of any project.
I ended up creating a single Project with a single Board.
In Project Settings (left side panel, bottom):
I enabled Components to appear on the left side panel
I set Issues to show the field "Component" when they are created
The Jira logical classification will be now like this:
PROJECT is my department
BOARD is the common view all users will share
VERSIONS are Versions
EPICS are my different Projects
COMPONENTS are now a kind of Epics for my projects, but with the disadvantage that:
a) they are all shown in a separately view, not as a side panel similar to VERSIONS and EPICS
b) they are all listed straight forward, which requires to give an identifier at the beginning of their name to differentiate to which Project they belong to
USERS: all Users will manage to see the main Project (which is my Department) and inside of it, all the Epics (which are my Projects). This was initially my requirement, so it is ok.
I wish Jira was a bit more flexible on letting us creating some additional group categories similar to VERSIONS and EPICS, so that we could get and extra group layer.
The use of Components here is not really very useful, but also confusing and not intuitive, but is the only option available at the time of this post to extra group somehow my Issues.
Problem:
Customers that become access granted, can access and see all or projects, what is naturally not good!
In our company there are a lot of projects that are connected by resources (people). So, people from one project works in onother one too. We are going to create Global Iteration (Iteration Path) that to assign items on it from different projects that to see all planned work in one common backlog.
But as far as I know it is not possible to do that for different projects.
Moreover, combining two projects is not a solution for me. Any ideas?
PS: I know the advantages and disadvantages of Single project (see topic) but it is not my case.
Currently, you can't show work items from multiple Team Projects on a single Kanban board in TFS.
As a workaround, you can either create your own query as #DaveShaw mentioned, or use one Team Project with multiple Teams and use features from Agile Portfolio Management. See https://www.visualstudio.com/en-us/docs/work/scale/portfolio-management
We have a five-member development team and will be building multiple internal projects in parallel. Upon researching, I find it is best to create one team project, even for our situation, correct?
If so, would you please recommend how to set up proper iterations for the projects and timelines?
TFS question - small team, multiple projects sounds similar to my situation, but I can't seem to get more than one "current" iteration in the TFS Agile process board.
Per team project you can have only one iteration tree (and therefore only one current iteration). You should decide based on how you plan your team resources. Do you want to have only a single backlog for the whole team or different backlogs for each project?
Each has its pros and cons, depending whether you want to use Visual Studio Team Service mainly for planning your team resources or planning your projects.
Using a single team project / backlog
With this approach it is easy to plan your whole team's resources for the next sprint. You can assign people to different tasks in different projects and have a good overview on what the team currently is working on. To assign work items to different projects you can use the area path.
Planning and tracking the progress of individual projects is a little bit harder with this approach since you have the same iteration structure for all projects and also only a common set of tags.
There are external tools which can integrate with Visual Studio Team Service available from the marketplace though, which can help you with planning individual projects.
Using a team project per project
With this approach you have a clear overview of the progress of each project and you can have individual iterations, tags, etc.
On the other hand it's harder to plan your team's resources since you won't have a single backlog and no place to see what your team is working on at the moment at a glance.
You can create one team project and set several child projects in it. With this, you can have the things configured for the whole project and also the child projects. Refer to this link for details: Multiple teams
I have two different projects within same Project Collection.
Is it possible to display the bugs of both the projects in same backlog or kanban board.
Currently, you cannot show work items from multiple Team Projects on a single Kanban board in TFS.
Kanban boards in TFS are currently associated with an Iteration Path. An iteration path only exists within the context of a Team Project. As such, Kanban boards by their current implementation live only within a Team Project.
As #Wouter stated, you could move the two projects into the same Team Project and use different iteration paths or area paths to differentiate your work items. This is actually a best practice. The name "Team Project" was actually a poor choice because they a Team Project isn't really mean to be the same as an actual development project. This has led to much confusion because it is not recommended to create a "Team Project" per actual project. It makes reporting and visualization a real problem.
Remembering that iteration paths are a hierarchical attribute, if you move both of the projects into the same Team Project, you can create an iteration path for each under the root and you can then get Kanban boards for each project. The root of the iteration path will also have a Kanban board and this board will be the rolled up board that shows all of the bugs from both projects on it.
I had this issue myself and found a solution when switched to Kanban Tool; simply by creating swimlanes on one Kanban board (one swimlane for each project) and then allowing bugs to be placed in the backlog and further development tasks in the next columns. So I have a complete view across many projects in one board. Happy to share my findings.
If you want to have information from different Team Projects, you can create your own query. By default, the queries limit their results to the current project but you can easily remove this clause. You will then get results returned from all projects you have access to. MSDN can help you get started with creating queries.
However, it sounds you are looking into having data from multiple teams roll up into a single project. This is supported by using one Team Project with multiple Teams beneath it and using features from Agile Portfolio Management. See MSDN: Agile Portfolio Management: Using TFS to support backlogs across multiple teams
"You could create a query for each collections"
OR
"Create a query like this and select the “Query across projects” checkbox to find all workitems in the current collection"
https://developercommunity.visualstudio.com/content/problem/122305/all-work-items-from-all-projects.html
My company is a Software development company.
We planned to use TFS 2010 for our future customers development.
TFS 2010 introduce Team Project Collection in order to split related Team Projects.
So my question is, should i use Project Collection per Customers or should i use a unique Project Collection with a Team Project per Customers which will contains some customer solution projects in it
It depends on how independent your projects and customers are.
For example do you what change set number series to increment within a project, per customer or within your farm? See the following link for some of the implications:
http://blogs.msdn.com/bharry/archive/2009/04/19/team-foundation-server-2010-key-concepts.aspx
Here's what we've decided to do, since we're a pretty small company...
We're going to have very few collections. Our primary collection is called "Production" and we'll have a few others called "Playground", "Proof of Concepts", and "Educational References".
The reason for doing it this way is that our rules/workflow/data needed for work items/etc. for how we handle things is very consistent company-wide and rather than recreating this customized configuration for many different collections, we'll just use different projects for that. The collections will be for when we need to go by different rules (for example, there will probably be no check-in requirements in the "Playground" collection but there obviously will be for the "Production" collection.
So in case it's not obvious at this point, it sounds like a different project per customer is what I'm suggesting for you. But of course, it really depends on your company, how large you are, how similar your project management style is (if you do CMMI for some projects and agile for some others, you might want to separate them), and some other needs.