Our development team is upgrading to TFS 2015 and we're able to start our Work item tracking from scratch, so I'm looking to take advantage of this to re-organize some of our current processes.
However I can't figure out a logical way to organize the iterations across multiple products, here's some background on what we do today
- We have 1 small team with 3 developers, and we all work on 3 different products concurrently, desktop, web, and mobile are the 3 products and they're all closely related owned by the same client
- I have TFS setup as 1 large team project as I've read this is the best way to organize work rather than separate team projects
- Each product has a different build number so we can identify different release versions for each product
Things I've tried for iteration organizing:
- Iteration number for each product (desktop/build1.1 mobile/build3.1 web/build4.1) This doesn't work because I can only set one of these as the 'Current' but in reality we're working on all 3 of these at the same time
- Single iteration number (root/build1.1) this also doesn't make sense logically for us because 1.1 only applies to one of the products, when I create a build for the products they will have different build numbers that won't match TFS. Also not all 3 products are released every time, so even if I used a single release number for all 3, there'd be gaps in the release version numbers for the products that weren't updated in the current release
- Child iterations, I can put mobile/build3.1 as a child of desktop/build1.1 for example, but it doesn't display this way under 'Current' so we wouldn't visually see that the current release will include mobile3.1 items also
- I've read that we can create separate teams for each product, but then we would have to switch dashboards to see the current build for each product. This also feels strange since it's just the same 3 people working on multiple products
My goal is to for us to be able to see each different product release number that has current items assigned to it in 1 single place, can anyone suggest a way to organize this?
I don't feel that Iteration Path is the way to go here, nor is multiple teams. Use Iteration Path to track your team's sprints and keep to a single team as you are a small team as it is.
There was a Similar question a few days ago which was well answered by Jesse Houwing.
Tags may be the simplest way to go but you might find creating a custom Work Item type (Release) that you can link to the Backlog Items is better or perhaps just a custom field on the PBIs.
Related
Background: A person I work for has her TFS set so that her ToDo, Impeded, InProgress, and Done columns show two items wide in each. The number of tasks has mushroomed recently as management wants to track work at a finer level of granularity.
I'm thinking this is an individual option set (or loaded) on her PC. I've gone through as many of the configuration options that I have access to. This might be something that she has special rights to (she is an software development manager and I am just a scrum master)
Microsoft Visual Studio Team Foundation Server Version 16.131.28106.2
Question: The standard view I have had in TFS and Azure DevOps allows for a single item in each column. What do I change/load/configure/sacrifice in order to get a two wide listing in the columns on my work board?
Thanks for any ideas, help, etc.
According to your description, it seems that you want to Split columns on your Kanban board to show work in progress.
In your Boards >> Setting >> Columns. Enable the Split column into doing and done to make the columns show two items wide in each. Please notice that, you can’t split the first and last columns(To Do and Done). Since they are always mapped to the initial and last state.
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!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We have one Dev Team (Approx 20 Team members) currently working on 5 products with 5 product owners (one for each product). We are struggling with story prioritization between different products and lots of meetings for the same.
Below are the two options we are looking at:
1. Merging product backlogs to a single product backlog
So that team can pull stories from one product backlog to sprint backlog. (And does not have to bother about priorities anymore). But a single product backlog maybe too huge and unmanageable.
2. Separating the team into 5 teams for each product
But this is not currently possible as we have resources specialized it a particular skillet and needs to be shared across the products.
Any suggestions?
I would suggest a third option.
Form teams around the products that generate the most work. Then have the remaining developers work on teams that cover the remaining products.
Something like:
Team 1 - Product 1
Team 2 - Product 2
Team 3 - Product 3, 4, 5
Hopefully this will reduce the struggle with story prioritisation (although not completely eliminate it).
The most important thing is to identify what you want to gain by the new organisational structure and how you intend to measure success.
Get some suitable metrics in place, try the new structure and see if the metrics get better or worse. Then inspect and adapt your approach.
I have a couple of things to point out, the tasks priorities are not responsibility of the development team at all, this is something that is managed by the PO for many reasons, but lets not discuss about that.
As you don't have a single PO this is transformed in a fight of interests. If there is no common goal between them every PO will want their US to be done ASAP because is the highest priority for them (and this is totally understandable).
So, if you want to keep one single team for all this products you will need a PO that works as single point of contact for the Dev team, a single backlog for them and then you can try to make sprint goals focused on single products so the dev team does not have to change their "environment" in the middle of the sprint (but this is a bonus point, not mandatory).
The main thing is if it is possible to have this single PO to manage this single backlog, at the end its the same as if your current 5 POs becomes stakeholders, they will ask for what they want, and this single PO will put those thing in order. Based on what ? could be company need, if there are blocking issues or it could go as easy as money ... who is the one that is paying the most and thats the one you will attend first.
In resume, remove the responsibility of picking the task to be developed off the team, it could be by this single PO approach, by a forum between the PO where they manage the single product backlog all together. And those are my 2 propositions.
There are too many factors in place, the company, the POs shared vision and needs, the reason why there is 1 single team that is managing all this.. etc.
We are currently working with one single team for multiple products as well and we have just one PO and a single product backlog and things goes smoothly.
Hope this helps! Any doubt just tell me!
This is a common problem and one that can be solved by discipline and team work.
5 Products seams like a lot for 20 people, and hopefully some of that work is similar and you can include it together. I would encourage the group into a smaller number of teams of 6+-3 and have them choose how best to meet the work.
If you have a self organising set of teams they will be able to figure out how to cross train enough that you will not have the need of so many specialists. Have a look at the Scrum Guide (http://www.scrumguides.org/) and follow the guiding principals in there.
I'll make some assumptions first:
The products are loosely related - e.g. if your company produces HR software, the products may be Timesheet, Training, Performance Management etc...
There is a certain amount of shared code between the products e.g. login, logging, deployment etc...
It is possible to have smaller teams that would have the skills necessary to ship product features.
The Product Owners are able to understand the business value of a product feature and negotiate between themselves on priority.
In this case I would...
Divide into 3 teams of 6/7 - this is enough people with the skills to get significant features done.
Have the 3 teams "own" 1 or 2 of the products - this is so that the team can really understand and contribute to the longer term vision of the products, and ensure that technical backlog items are prioritised appropriately against the product value.
Have a backlog for each team - that the product owner(s) and team own.
Have an explicit method that the product owners use to prioritise features - e.g. business value, WSJF, Kano etc... Agreeing this and writing it down may help stop arguments over the approach
Have the 3 teams co-ordinate changes to the shared code - maybe an Inner Source type approach.
Have a coach help the team and stakeholders through the change.
Too many fronts open maybe? Take a step back to revisit your companies goals, consider lowering expectations and re-organise the teams accordingly. If you postpone a product and do 4 products instead of 5 is not the end of the world. This will give you a good boost in the other products. Be smart and pick your battles. You don't need to fight every battle to win a war.
Just like the title says, I would like to know if there is any way in TFS 2013 Update 4 to query a whole week-long activity for a certain User (a team member of a certain project) across multiple projects.
An example scenario will be as follows :
User_A is a team-member in Project_1, Project_2, and Project_3.
On Day_1, he performs some work in Project_1 (development : 2 hours, testing 1 hour). He also performs another work in Project_2 (bugfixing : 3 hours).
On Day_2, he continues his work in Project_2 (bugfixing : 2 hours). And then due to some circumstances, he is required to solve an urgent issue in Project_3 (3 hours).
And so on until Day_5, shifting back and forth through multiple projects.
Now, our PM would like to know the details of his work during this week (from Day_1 until Day_5).
Is it possible to generate data, perhaps through a query in TFS Web Access to aggregate data for
User_A in a given timespan ?
Thanks.
There are a number of questions in here and I will try my best to answer them all:
Query Across Team Project in Web Access
First, you can query in Web Access across multiple Projects by just removing the "Team Project" part of the query.
You can even create charts based on this data...
However for anything more complicated you should use the built in Reporting Services tool and the Data warehouse that comes with TFS. If you don't have it installed then you can add it.
http://nakedalm.com/integrate-reporting-and-analyses-services-with-team-foundation-server-2013/
This will gave you access to much more powerful reporting but it is much more complicated to configure. You get a cube (multi-dimensional data) and a warehouse (lists) that you can query to your hearts content both across team project and across collections.
Time Tracking in TFS
TFS is an effort management system and is not good at time management. While you can get a query to show you the amount of time applied to a Task you can tell when that time was applied without some serious giggery pokery. In TFS (well the MSF templates anyway) you store "Remaining", "Completed", and "Original Estimate".
So today I have a task that I completed 4 hours and tomorrow it will have a value of 8 hours in the completed field.
So did I complete 8 today? No, I only added 4.
What if I decided that it was only 3 the day after I entered the data? Can I fix it? No,
I could go on and on with the issues and caveats for trying to track time in TFS, however, if we just assume that it is not possible (or at least more effort than it is worth) then we are left with finding another solution. (Yes, I know there are third party tools that plug onto TFS and do time sheets or other stupid stuff, but they all have issues.)
I recommend tracking course grained time against a Project in a tool is separate from TFS, that is designed to collect this information. I have used Harvest and Freshbooks but there are other time sheeting systems out there. Do not integrate it with TFS. I have never once seen that work effectively and there is no value in it.
Is there value in tracking time - Not actually asked but it goes to the crux of the issue
The only demonstrable value I have ever seen in collecting time sheets is a) if you are billing your customers for that time, or b) you need to understand capex vs opex against a project. If both are true then a simple Project in Harvest with two tasks, one for Feature work and one for Maintenance work, will be sufficient and way simpler to manage.
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.