We have a project with multiple teams managed in TFS 2013 update 2.
The problem is that if i have two teams, and a person works 5 hours in each, when i look at the teams parent, i dont see the value automatically updated to 10.
In other words if i make a mistake and define a capacity that sums up to more than the actual work day, there is no way for me to see it.
I can develop a server extension that will update the capacity of the parent team, but i am stil hoping for an easier solution.
There currently is no solution. Team Capacity is not easily queryable, the UI has no option to do it and it's not part of the Data Warehouse.
TFS kind of assumes that a team member is part of one team. And one team only. And have work flow to the team, instead of people swicthing between teams. I suggest you file a suggestion on Uservoice.
Related
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).
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
We have a team of around 10 developers working on a new product.
We have split this product into two team projects on Visual Studio Online. Developers can work on both projects during any one sprint. Although we have two team projects, the entire team works together as one agile unit.
Why did we do this?
We want separate product backlogs
Each project has their own Product Owner
But this has led to two problems:
We have two burn downs, which can make it difficult to track team progress.
We have to split individuals' capacity between two projects, which is not easy to do in Sprint Planning and also makes it difficult to track individual progress.
I feel like this may be a common problem. Does anyone have experience here? Any suggestions?
You should have both teams in the same team project. You c Dan create multiple teams that all exist within the same team project and get their own backlogs.
http://nakedalm.com/creating-nested-teams-visual-studio-alm/
Most of my customers have moved to a single team project and I have a simple rule:
"If you have assets that are related (with assets defined as code, people, or work items) then you should be in a single team project."
I just got done in London merging about 15 team projects into one so that the entire org can work together. This was 6 teams across about 12 products, all moved to one team project.
The only effective way to collaborate is within a single bucket of work.
So we recently upgraded to TFS 2013 Update 3 from TFS 2010 SP1 and my product owners do NOT like it at all. This is because of the sparcification logic that was added (I think in Update 2). Now their backlog priorities are all messed up and they have this huge number in the billions as a priority.
To compound this, there are multiple product owners, so if product owner A prioritizes something and then product owner B prioritizes something, the backlog items get re-ordered and chaos ensues.
I was thinking maybe the answer is to use the Features work item and then a po could just map work items they care about in the order they want, but I'm not convinced this is the right answer.
I want to do well by my user base (POs, devs, etc.), but I do not know a best practice solution for this. What would you guys recommend?
After meeting with the POs, this is the solution that I have come up with. I'm going to remove the backlog priority field from the work item form (this is coming in a future update anyway). Then I'm going to add a new custom field to represent a priority which is meaningful to us. Tagging will be used in scenarios where a PO may want to call out something specific about the work item.
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.