We are using VS 2010 and TFS 2010 with the Microsoft Scrum Template.
We use the Team Queries for the Current Sprint like the Sprint Backlog query.
The problem is when we move to sprint 2 the "Current Sprint" still points to sprint 1.
Is there a way to to tell TFS that we are now currently in sprint 2 and have the queries use a variable to run against instead of hard-coding the sprint?
For example: If you look at the screen shot below you will notice that the definition of the query uses a variable called "#Project" for the team project. Is there a way to have a variable for the sprint?
Tom,
What you are asking for is not available in TFS 2010. There are not even dates on the iterations, so TFS does not know what the current iteration is.
In TFS11 (vNext) we have added the dates on the iterations. It now knows in which iteration you are, and this is also reflected on the backlog page in web access. In the preview version that is out now it is however not possible to add a filter clause to your queries to filter on the current iteration (something like #CurrentIteration). We have heard strong feedback to add this in the product before it ships. It is also very high on our wish list, but we need to fix other things first before we can ship.
You can add this request on User Voice. If the idea gets lots of votes it makes it easier to build a case that we need to put this in. But we cannot promise anything.
Ewald - TFS Program Manager
Almost all answers here say that you either need to wait until Visual Studio implements #CurrentSprint token or to change all existing queries manually.
I found another great practice that might help you which is explained here:
http://intellitect.com/transitioning-between-sprintsiterations-with-tfs.
Try to create a “release” called “Current” and move the specific current sprint under it. It's much easier and quicker than dealing with queries every time you start a new sprint.
You could modify the work item query programmatically: http://www.ewaldhofman.nl/post/2010/03/09/TFS-SDK-2010-e28093-Part-6-e28093-Replace-text-in-all-Work-Item-Query-Definitions.aspx
I've only ever read documentation/guidance (links unavailable at the moment), that said at the start of a new sprint there are a few various steps you need to take in TFS, e.g:
create the new sprint/release nodes
set the applicable PBI work items' iteration to the current sprint
set the applicable PBI work items as committed
update all the "Current Sprint" queries to reflect the new sprint number.
I've never seen documentation on doing the last step list (or any of them) in a hands-off (automatic) way. That said, I'm not suggesting it's not possible, just stating that I've never seen guidance on how to do it, but have seen plenty of guidance on doing it manually.
You could use a plugin called TEK workitem. TEK workitem is a Visual Studio extension for TFS that allows bulk edit of query definitions, besides other features like open in Visual Studio workitems and queries from a Hyperlink, delete Workitems from Visual Studio UI, etc.
You can download a demo from Visual Studio Gallery: TEK workitem
I am pretty recent to TFS Scrum 1.0 but this is what I do.....
I am currently managing my sprint dates outside of the template
I use the 'Current Sprint > Query’s' to give myself and team quick access to the queries on the current sprint.
When I finish a sprint and want to increment to the next sprint and have the queries under 'Current Sprint' point correctly I do the following:
Edit each query under ‘Current Sprint’
Right lick and select ‘edit query’
You may see an error dialog if you have changed the hierocracy of your iterations. OK to click through to the query editor.
Set the value of ‘Iteration Path > Under’ by selecting the correct sprint from the drop down (populated with your iterations.
Save the query and bob’s your anty…. Queries will display you current sprint. Just repeat each iterations.
Hope this helps....
I found in TFS 2013 that if you uncheck the sprint/iteration the one with the earliest dates get assigned to current automatically. If you want to keep the old one visible, move the dates out a year or so and it drops to bottom of list, but out of scope.
This is TFS online 2017
Step 1) Settings-> Work->Default team settings
Step 2) and then 'Default Iteration'->Change
Keep in mind that next time you might be starting in Step 2. So Step 1 is optional.
Related
In docs.microsoft article there is a statement:
The forecast tool ignores Scrum items set to Committed or Done and
Agile and CMMI items set to Active, Resolved, or Completed.
And so the tool includes in current iteration's forecast such items:
really moved to the current iteration and really active and resolved;
and next few iterms really moved to the next iteration;
WHY they are ignored? They don't complete and the team need time to complete ones!
I don't understand how to use this tool?
What kind of process proposed to use?
Thanks a lot!
You are correct that the forecast tool ignores the In Progress Items whether they are shown or hidden. Regarding why they are ignored, I'm afraid it's by design. Once your team has completed a sprint or two, they can use the team velocity to forecast how much of the backlog they can finish within the upcoming sprints. This doesn't include In Process Items, but for Proposed items.
If you have any suggestion for DevOps, feel free to submit a suggestion at website below:
https://developercommunity.visualstudio.com/content/idea/post.html?space=21
So I am trying to write a query that will show me completed bugs, of completed PBIs, that were handled within the same sprint. In other words, bugs we introduced with new functionality, but also closed before finishing the Iteration.
The issue is the hard reference to Iteration Path. What I would like is a variable like #ThisIteration, and I would place it both of the highlighted spots. This way I could return all of the Bugs and PBIs that were resolved with in the iteration for all time.
I assume this just doesn't exist within TFS Queries, so I am looking for work arounds, or clever solutions, like WIQL, etc.
Thanks,
Devin
Based on your requirement: "write a query that will show me completed bugs, of completed PBIs, that were handled within the same sprint"
The query you created should works. For the Iteration Path we can only use the macro #CurrentIteration in on-premise TFS. In VSTS you can use the #CurrentIteration +/- n to offset the iteration. Please see Query macros or variables and Query for items based on a sliding window of team iterations for details.
Note
Feature availability: The #CurrentIteration +/- n macro is supported
for VSTS only, and only when run from the web portal.
Besides, you need to adjust/modify the query based on the Bugs working as.
If Bugs are managed with requirements, then the Bugs and PBIs are
in the same level. So you can use Board Column field to filter...
If Bugs are managed with tasks, then the Bugs and PBIs are not in the
same level. Filter by Board Column will not work. So you need to use State field to filter...
WIQL would be the same...
My company uses TFS 2008 with the MSF for Agile process template. We are in the process of planning an upgrade for TFS 2010. We use Scenarios as a container for functional requirements with linked development tasks, bugs, etc.
In order to save the state of a Scenario as 'Resolved' or 'Closed', I would like to enforce that any development task or bug that is linked to the scenario is also closed. With TFS 2008, these are links, in TFS 2010 we plan to use child work items.
I have been reviewing the work item type definition schema and MSDN documentation, but nothing is jumping out at me as a solution to this problem.
Can it be done? Thanks in advance for any help!
What you want cannot be done directly. The saving of a work item is what is called a Notification (rather than a Decision). That means that you can only do TFS API stuff in an event after it is done. You cannot block it.
However, there are ways to get the "effect" of what you are looking for. If you modified your template so that your parent work item (I think you called it Scenario) had the State control (not the field) as read only that would make it so that only clients that don't use the normal Visual Studio controls can change that value. (This could be worked around by your users, but it would take some effort to break the rules).
But there is one more step. You need to get the parent work item to "Resolved" somehow. For this I recommend a open source tool that I wrote called TFS Aggregator. (Or if you plan to "roll your own" you could use the code there as a starting point.)
You can find TFS Aggregatoron codeplex here: http://tfsaggregator.codeplex.com/
It is a great tool for rolling up changes and totals to parent work items. You could put in a rule that when your child items are all "done" to move the Parent to "Resolved".
EDIT: I realize now from your question that you have more than one type of Work Item as a child of the parent Item. TFS Aggregator does not support that right now (but it may in the future). It was written to aggregate tasks to Bugs or PBIs. Still, it would probably be easier to modify the code of that project than to start from scratch.
I don't think this is possible "out of the box". I would recommend you write a query to find cases where the "rule" is violated and handle it that way.
If you MUST automate this - You could use the TFS Eventing Service which can invoke a Web Service.
Set it up for when a Task or Bug is closed - query the database for the Scenario and if all the Task/Bugs are closed - use the TFS API to advance the Status to Resolved or Closed. You could limit the allowed user to make advancement to the account the Service runs under.
In TFS when I setup a new iteration, I start out by creating "Requirement" work items, which are then associated with multiple child "Task" work items. On the task work items I put the estimate for the task and then as the task is worked on the completed and remaining hours are updated.
What I want is an excel report that will show a breakdown of iteration, requirements, and task, with the hours totaled at the requirement and iteration level.
I envision this to be some kind of pivot table but I can't figure out how to pull in the data so I can relate it.
There is no rollup available out of the box in TFS 2010. You could write a macro in Excel to calculate the rollup hours and pivot on that.
You could also use the SSRS report User Story Overview to see the value, but that value is delayed (which is probably not what you want).
You could also take a look at the Project Server Integration CTP, which has the rollup feature.
If instead of Excel, you use an Agile planning web application for TFS such as Urban Turtle, you will obtain rollup feature at the requirement and iteration level.
According to Microsoft, the premier Agile tooling for TFS is Urban Turtle. Discloser: I work with the Urban Turtle team. So do not take my words. Instead, read what Brian Harry, who is the Product Unit Manager for Team Foundation Server, said about Urban Turtle: "...awesome Scrum experience for TFS." You can read Brian Harry's blog here
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.