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...
Related
Want to build a report showing each team member's percentage contribution per a completed Sprint.
We break up the work in Tasks and assign a Remaining Work value to indicate the time needed. The problem then is that remaining value is clear or decreased as the sprint progresses.
Have been looking for a way to find the original remaining value, so I can use it for reporting post the sprint. All in an effort to try and build a relation between originally set Effort and Actual hours.
Any assistance would be appreciated.
First I have to say this, as a Professional Scrum Trainer with Scrum.org, we highly discourage the breakdown of effort to the individual team member as part of standard reporting. Where scrum is concerned, the individual contribution is of little consequence outside of the team context, and inside of the team we feel that team members should be able to openly discuss the perceived value added by other team members as part of their Sprint Retrospective.
Secondly, because TFS can't register multiple users being assigned to a task, nor support the trackign of hours spent by multiple team members on the same task, your report will either be incomplete at best, cause additional administration overhead in most cases and may even cause team members to not work together at worst.
That said...
TFS tracks all assigned and saved values for work item fields. Using the API it's easy to iterate through the work items and retrieve their previous Revisions. As an alternative, the API offers asof work item queries which allow you to track what the values of a workitem were on a specific date. This information is also store in the TFS datawarehouse, if you are using it, aggregated at the daily level.
But if you need accurate tracking of time spent, the only reliable way is to add the Completed Work field to your work item type definition:
Completed Work
The amount of work that has been spent implementing a task. You can specify work in hours or in days. There are no inherent time units associated with this field.
Reference name=Microsoft.VSTS.Scheduling.CompletedWork, Data type=Double
Task, Bug
This is required to cover cases where the original estimate was lower than the actual time spent, remaining work would in that case remain the same, or even increase, while a team member had spent time on that item. without also tracking CompletedWork, this data is lost.
The Agile and CMMI template use this field by default. The Scrum template doesn't, you can guess why based on my initial cautions.
We can search for work items under an iteration per project, but we'd like to search in ALL of our projects, if possible.
The My/Team query builder won't let you use a wildcard in the Iteration Path, which means you must select a specific iteration in the Iteration Path 'Value' dropdown...
I figure we may be able to run a SQL query on the backend, but there is red tape involved in that solution...are there any other solutions?
As to the 'why' question: we would like to track all open 'hotfix' work for all of the projects. Aside from having someone enter the term hotfix into the title of a work item (which introduces human error, but would be searchable), we're not quite sure how to do this by searching for iteration.
No, there is no way to do this without a great number of "or".
You should consider merging the team projects that you are encountering this issue with. In addition you should upgrade TFS to take advantage of the new team entity for splitting up the work.
http://nakedalm.com/one-team-project/
I have setup Jira and Greenhopper and set up an initial sprint. I have mostly done scrum during my years via a whiteboard and face-to-face communication. I wonder how I should handle unplanned items using greenhopper? I don't just want to add a New Card and have it screw up the statistics. Would be nice to be able to get a figure of the ammount of unplanned work when the sprint is done. My initial guess was to add a New Card on the Task Board and tag it as an unplanned. But I don't seem to find any unplanned tag for a Card.
I've been using Greenhopper for about 1 1/2 years. It works pretty well and is invaluable to our team but isn't a substitute for post-its on the well for the daily stand-up. Over the 1.5 years, we've ended up collecting a lot of tasks, bugs, and other items in Jira that aren't immediate backlog items. Managing them is the most difficult in Greenhopper. These are the Unscheduled items.
I have these versions set up in Greenhopper:
Unscheduled: this is a holding pen for a few hundred items that we may or may not ever get around to. Some are ideas, some are bugs that we can't fix at the moment.
Unscrubbed bugs: as we find new bugs that aren't related to the current sprint's work, they go in here. Every week or so, we go through them and place them in one of the other versions.
Short Term Roadmap: stuff we'll get to soon but not in this or the next sprint.
Sprint Planning: this is the backlog we work from during planning. It's the higher priority items.
v2.3 - Sprint 2 (or whatever version/sprint we are currently working): This is the sprint backlog.
During the current sprint and before our sprint planning session, I organize the backlog and place the high priority items in Sprint Planning so we will get to them next. After the meeting, we place the items we sign up todo into the v2.3 - Sprint 2 and them manage it on a daily basis.
I think when you say 'unplanned items' you are referring to critical 'hot fix' tasks that need to be done ASAP. In my group we use a split team. We have one team that commits to the sprint. The Core Team. They are the only resource we calculate on to determine the amount of work we can do in a sprint. Another, much smaller team called the Firefighter Team is set aside to work on unplanned, critical items that, for example, might be needed in the next release.
We track these side-by-side. The Core Team is NEVER permitted to work on a hotfix item. However, the Firefighter Team is permitted to lend their skills as 'servants' to the Core Team if they do not have any critical items at the moment. Our split on one project is typically 4Core/2Firefighter. We rotate the Firefighter members each sprint, taking care not to remove someone from the next sprint that is in the middle of a big project spanning multiple sprints. So far so good. The only issue I have right now is tracking what amounts to parallel sprints in a meaningful way. I'll tackle that when it becomes a real issue.
See my feature request to Atlassian and Vote for it.
"As a Product Owner, I want new PBIs quarantined from the Backlog until I rank them"
https://jira.atlassian.com/i#browse/GHS-11139
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.
If you are using TFS 2005 or 2008, how do you user iterations and areas?
Do you create an area for specific parts of the application you are building?
Here is an interesting article on areas and how the TeamSystem team uses them:
http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx
But, i'm even more curious about iterations and I would be grateful if you could show me few concrete examples.
Do you create iterations based on milestones or based around certain functionality?
What happens when you finish v1, how do you manage v2 or updates to v1?
We are using MSF Agile template.
We use areas to represent product lines.
Since we use SCRUM, the iterations in TFS are used to define our release cycles, and the sprints within those release cycles.
Backlog items are assigned to release cycles and work items are assigned to eash sprint to ensure those backlog items are completed.
After a release, it is perfectly fine to add bug fixes/updates to the backlog while working the next version at the same time.
The Iteration and Area Paths are what you want them to be. Its how you can describe your project in space and time. An easy example are as follows:
Area Path (Space) - can be used to describe the parts of your system/project. Say you create a TeamProject for a GUI application, some areas will discribe its modules (Data Input, Reports, GUI, Printing, etc...)
Iteration Path (Time) - describes Versioning or Release Cycles of your project. On company that I worked for used release versions as their iterations (major, minor, build, revision). It helps track the work items to mark what iteration it was expected to be completed by. We had a static TBD iteration which was the default for all work items created. Management would decide later where to target that work items and assign them or close them.
I assume you are using iterations as part of MSF Agile, or some other type of Agile methodology. If so, in general, you figure out how much work can be completed by your team over the next n weeks. In general, we used 3 weeks, but your iteration length may be different.
How you determine the items for the iteration is generally based on priority, which should be based on market/business impact (hotness of item) and ease of implementation. The impact score is the heavier weight, but you should consider ease of implementation in your score as you may have a few "bang for the buck" items.
The rule, with Agile, is features that cannot be completed get dropped. You NEVER extend an iteration date.
This should answer the milestones versus functionality question. It is neither. You base an iteration on time. It is time boxed. This way you can figure how optimistic your team is an adjust next iteration to get more accurate on estimates. If you base an iteration on functionality, you will always miss dates. The same is true for milestones.
NOTE: If you are talking waterfall, the rules can be based on milestones and functionality, but with Agile, time is king.
Now to areas: This one is more subjective. One way of dividing into areas is grouping use cases. I like this method. But, when it comes to user interface, you can also create areas for particular forms, etc.