I am currently working on two projects, and I am using Fogbugz to keep track of my cases. My question is: if I enter one month worth of estimated work for each project, will Fogbugz estimate that the ship dates for the two projects will be TWO months from now?
Note: there's a discussion here but I don't know if it's still relevant. I'm not even sure I understand it correctly hehehe.
I decided to merge my two projects into one. I then created an area for each project. So while before I had two projects,
Project A
Project B
I now have one project with two areas,
Project: Company
Area 1: Project A
Area 2: Project B
The ship date for this one project is about two weeks later from the original ship dates before the projects were merged. I guess this confirms that FogBugz disregards any time spent on other projects when calculating the ship date of a project.
Another way I could have worked around this situation is to retain the two projects but change the '% time spent on FogBugz tasks" in the work schedule to 50%.
Related
Trying to figure out best way to setup Jira for cross-organizational project. We have a Continuous Delivery Program that will split off into separate backlogs to be worked by different teams based on Themes.
Wondering if we should setup one project to manage the overall high level project, and then different projects per theme of work that will be managed by the individual teams.
Are there ways multiple teams can work out of the same project but track their work separately (including if their work is Kan-Ban, Scrum-Ban or Sprint based?)
Regarding the question in the title. It's possible to move issues in JIRA from project to project. This feature is quite handy and you even can do bulk operations. See Moving an issue for more details.
Regarding structuring your projects. Out of the box there is no feature in JIRA to create such a workflow with projects and sub projects you have described.
A possible workaround could be using components as sub projects.
In this case you would create a project which act as your high level project and divide this project into several components. For components you can add a lead, do versioning but you can not set security permissions based on components for example. So this is not a perfect solution and have indeed some limitations since components are not projects. But you have to evaluate this approach by yourself if it is sufficient for you.
Another option would be to use a plugin e.g. Structure. I am pretty sure there are even more out there which promising to solve your problem. From my experience also using a plugin may be not the silver bullet you are expect. You have to evaluate it first if it really suits your workflow.
For the scenario you describe, the issues that you start from are probably more high-level than the actual work that has to picked up in the separate teams.
What I find to work well, is to keep 1 project (ie. Opportunity Backlog) for the high level issue (ie. an Opportunity) and when an opportunity gets detailed out, just create issues in the projects of the teams that will work on them. You can still link those issues to the opportunity so people who look at it can see what is happening in each team.
Another option is to keep everything in 1 project, but to make the relevant issues show up on the board for the team that has to work on them. A board can list issues of multiple projects. You just need to update the JQL query for the board accordingly. For more details, check the documentation. Note that working with sprints can get cumbersome if the same issues are listed on boards of multiple teams though. Best to configure things such that an issue is only displayed on the board of 1 team.
I wouldn't bother with moving issues too much. It's not a very user friendly action.
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.
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.
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.
I have installed TFS 2010 using the Scrum for Team System v3. The work item templates want you to enter a Project Backlog Item that includes story points, then you need to add linked tasks as a child of the PBI. It is at the task level where you can assign team individuals, update estimated hours left, etc.
What is the importance of the Story Points used at the PBI item if individual tasks are using hours?
Has anyone customized this template so that the child work item tasks use story point burn downs instead of hours? Also, I would be nice to have the total number of story points from each individual task roll up into the PBI item as a read only field for total story points.
Thanks for your time.
The company that I work for is also using TFS 2010 with the new Agile Template v5.0. We are going about the process in the following way and having some success. The hardest thing we have done to date is try to wrap everyone's head around the idea that Story Points do not directly equate to any form of hours.
We start the process with a Release Planning meeting, this is done once a week but if you have never done one you probably want to start with one first. We have 3 teams and only the product owners and team leaders are in the meeting, it would just be to large to manage if we were all there. It is at this Release Planning meeting that we, the team leaders only, play planning poker to assign Story Points to User Stories.
Then we have a Sprint Planning Meeting where a team and the Product Owners and Stake Holders will agree to a number of user stories to execute one in a sprint. The Story Points, after a few sprints, give you an idea of how many you can actually don in one sprint. Each User Story is discussed with the product owner and usually the Scrum Master is adding tasks to the User Stories as they hear the team talk them through.
Now the Product Owner and Stakeholders go away. The Team then goes about dividing the work amongst itself and assigning hours (Original Estimate) to each task. After that is done the Team goes to work, usually two weeks but I can see us doing a three week sprint if the sprint just couldn't be nailed down to two weeks.
As we work we adjust the Hours Completed and Hours Remaining with no regard for the original estimate. If we have spent 3 hours so far and after 3 hours we think it is going to take 2 more that is what is on the task, it doesn't matter that the Original Estimate was 4 hours.
Because we have "filled in the boxes" and not adjusted the template all of the reports and the cube just work. We don't need to make any large adjustments to the reports or anything to capture some really nice metrics. If you want a template that is simpler you should take a look at the "Microsoft Visual Studio Scrum 1.0" from the Visual Studio Gallery. It is simpler for sure but offers less reports and less support in the way of integrated Office documents.
Mircosoft Visual Studio Scrum 1.0
We ended up using the TFS Agile template, but just ending up using the "Effort Hours" in the work item tasks and refer to them as story points.