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.
Related
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...
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.
I thought that story points showed the effort (relative number) to put into a user story, but TFS 2015 have both Effort and Story Points. What to use when? What's the difference?
Detail view of a Product Backlog Item (user story?) shows only an Effort field, but the Feature list shows both (I might have customized the columns, I don't know if both is shown by standard!)
NB: I might be interchanging XP and Scrum terminology! Do say so, if I do!
Running TFS 2015 version 14.0.24712.0
The Scrum Guide doesn't say a great deal about what estimating approach to take. For this reason a lot of people doing Scrum have adopted the story points approach that comes from XP. But that is not the only approach to estimating that can be taken.
Another common approach is to combine both story points and time-based estimates. TFS seems to be set up to support this particular approach.
This is how that particular combined approach works:
Story points are used to estimate the relative size of stories. At the end of each sprint the team works out how many stories they completed and uses the total story points done to calculate a velocity. This velocity is then used as a guide to what the team can fit in to future sprints.
Once a Scrum team have completed the story point estimates they then go on to break each story down in to tasks. They then do time-based estimates on the tasks (e.g. Task 1 = 2 hours). There are several reasons for doing these task-level estimates:
The process of estimating tasks often draws out some design and implementation details
The task-level estimates may indicate that one particular discipline (e.g. testers) has been overloaded in the sprint
The task-level estimates also serve as a check that the story point approach hasn't overloaded a particular sprint (e.g. the team put 20 story points in which is usually fine, but when they did the task-level estimates they realised it is too much work)
This approach is particularly popular with teams that are first starting out with Scrum. A lot of teams start out using this approach and then drop the task-level estimates when they get more used to working with Scrum.
TFS is set up to work well with this particular approach, but that does not mean it is the only way you can estimate in Scrum.
By default it's only the Effort column displayed (Version 14.95.25122.0):
I'm looking for a work-item-tracking/bug-tracking system (or JIRA plugin, or TFS plugin, or...) which makes it easy to stack-rank work items without having to manually assign priority values to each work item.
Instead, our team wants to be able to see a list of open work items and be able to drag-n-drop one or a multiple selection of work items until the order matches the team's prioritization. This would be much easier than arguing about priority numbers and dealing with ties (e.g. "which of the 5 bugs marked priority=2 should I work on today?").
Our team is considering switching work-item-trackers (we use Gemini now) and availability of a good drag-n-drop prioritizer is high on our requirements list.
I realize drag-n-drop ranking is non-trivial because no team will stack rank all work items. Instead, we'll want to take a subset (e.g. work items for one sprint sprint or iteration, or bugs assigned to one developer) and stackrank those, then later look at a different subset and stackrank those, etc. And I'm sure we'll sometimes need to mix and match different stacks, so there'd need to be heuristics (ideally configurable) about how to show a stack of items previously stacked separately.
Pivotal Tracker is close to the drag-n-drop UI I'm thinking of from a UI perspective, but Pivotal's model of separating user stories from the underlying work items (plus a few other issues) doesn't match how we want to work. We don't want to have to deal with different artifacts (stories vs. JIRA/BugZilla work items)-- instead we just want a drag-n-drop UI to automatically fill out a "priority" field in the issue tracker, and which we can use later when sorting and filtering. And we wouldn't want to use Pivotal as our only work item tracker, because it seems to lack common features like bulk editing which are critical for large projects.
Anyone know of a tool like what I describe above?
Urban turtle is the best TFS add-on, making ranking/prioritizing a sane activity. Priority by number is a disaster so don't think you're alone there.
http://urbanturtle.com/
Urban Turtle is updated every month and used by quite a few teams including a number of my teams.
Eylean Board has what you are looking for. They offer a task board where the tasks are prioritized by moving them around, the priority tasks being on top. Interface is nice and clean and they offer other features such as integration with TFS, reports, etc.
The greenhopper plugin for JIRA has this feature. It's worked well for me ...though I'm not a big fan of JIRA in general.
http://www.atlassian.com/software/greenhopper/tour/backlog-management.jsp
Previous to this, I just used excel.
One of the best (and fastest) web UI's I've seen is on AgileZen, which supports something similar to this. Last I knew it did not have built-in integration with TFS, but it does have a REST API. It's basically a web-based, shareable Kanban board.
I was wondering if someone could tell me what area/iteration in Team Foundation Server WorkItems is and how it should be used with projects?
Is it as simple as:
Area = Project Collection?
Iteration = Version Number?
I can't seem to find much information on what these are and what they are used for?
The short answer is that the area classification is the logical division of your product or project, and the iteration classification is its chronological breakdown into releases and development iterations.
The area path describes the logical part of the system that your work item relates to, e. g., which module or subsystem some bug was found in.
Likewise, the iteration path tells you which iteration put release a work item should be handled in, for example, this task is for the third iteration of the fifth release.
The logical and chronological breakdowns can be done any way that makes sense to your team, as long add the structure remains that of a tree.
Does this help?
Assaf.
The application and usage of areas and iterations seems to be a difficult choice for quite a few (myself included). There is of course also the consideration that you might want to have one or two physical "TFS projects" and place all your projects under that separated by areas and a larger hierarchical structure.
This blog post has some intersting questions and answers showing pros and cons on the matter:
http://blog.hinshelwood.com/when-should-i-use-areas-in-tfs-instead-of-team-projects-in-team-foundation-server-2010/
One cool explanation that stuck with me is this one "think of Areas as slicing and dicing a team project by “functionality” (like UI, Business Layer, DAL etc), and think of Iterations as slicing and dicing by “time”. Iterations are like “phases” of a lifecycle, which can dissect the timeline of a project effort into more manageable time-based pieces."