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."
Related
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):
Having recently migrated to TFS 2010 I was wondering what the best or most widely accepted definition or configuration is for an Area?
The only useful article I can find online is this one and is what I would have assumed to be correct. However it got me thinking if any of the following is indeed more widely accepted.
Areas by business functionality
Areas by technology
Areas by system layer
Areas by physical or geographical location
It really depends on the product/project you 're building, I suppose it was made available as a general-purpose placeholder which can get its meaning from the context of the team & the team mission.I can imagine projects, where ignoring it on the grand total, would also be a perfectly acceptable solution.Our initial TeamProject structure in fact did ignore Areas for our flagship product we construct in a Team Collection. This resulted in a reporting nightmare, since we needed it on a platform-level (TeamCollection), rather than a distinct part of it (Team Project). When we realized the problem, we went searching & found this article, which made us change course: we are now using TFS Areas within one single Team Project & found what fitted best to our situation. In our universe Area = a distinct release line within the platform.
Areas in my opinion is a grouping mechanism, with Areas you can group your wortitems in any kind you want.
I think everything which fits to your development process and or make you more productive is ok.
All of your items on the list are valid types of areas, I saw all of them in projects.
But too deep hierarchies are not really helpfull, because if you create a workitem you than you have to choose/select the right area.
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.
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.
In FogBugz 6, how do I represent the concepts of a "feature" versus a "task"? As defined by Joel Spolsky, the owner of Fog Creek Software (which makes FogBugz), a feature is essentially a user-visible capability. To estimate the time to implement a feature, the developer should break the implementation into short tasks (2 days max) to ensure they think about each step.
FogBugz has only cases. I can't tell whether they're supposed to correspond to features or tasks. Some FogBugz documentation indicates that each case is a task, which is fine except there is no way to group all the tasks for a given feature together. This is especially odd given that, before FogBugz 6, Joel advocated using a spreadsheet with that grouped all the tasks for each feature. But his own software doesn't appear to meaningfully support that grouping.
I realize that the Joel article I reference includes a disclaimer pointing to a later article. However, the later article does not settle this issue, in fact it doesn't discuss features versus tasks at all, which is surprising given how well Joel advocates for those concepts in the first article.
For FogBugz 6.0 and earlier:
Make a case for each work item (task). FogBugz calls them "Features," only to distinguish them from bugs, but you do want one case for each task.
The best way to group a bunch of tasks is to make a Release (Fix-For) and assign all of the tasks to that release.
Responding to AviD's comment/question to Joel:
So, if you have 10 new features coming
in the next version, with each feature
needing 5 tasks to implement, you
recommend creating 10 releases? And
how do I define that these are the
features/"releases" that are to be
included in the upcoming release?
Here is how we dealt with this specific problem in our development process:
First, we made a regular release schedule: monthly internal releases and quarterly external releases. This schedule never changes but task assignment / feature completion does. This is hugely important in terms of simplifying our inter-human communication: don't try to argue with the calendar.
Major features ("10 new features" in your example) are turned into cases (e.g., case 101 to case 110).
Each task that is a sub-component of a major feature also gets created as a sub-case with a description of what makes this chunk of work an important part of the larger picture. Previously, in Fogbugz 6, we used the "See also" feature by allowing it to search the text for us ("This is a sub-component of case 101" for example). This was effectively the same thing but less aesthetic.
Now that we've broken down the work to its finest level of usefulness, we bring the actual developers into the discussion. Each task and major feature is individually assigned to a particular developer.
The developer determines when they can get their assigned work done by picking the appropriate internal release date that they think they can commit to.
At this point, we have a rough sketch of what will get done for each release. Further refinements continue as the working people actually estimate the hours that they'll need to do the work, enabling evidence-based scheduling, etc.
For AviD's question, though, he would have the release-assignment problem solved by step 5 above.
However, I think point 6 is the most interesting as that's where you really get a solid schedule. For example, if developers are having trouble estimating a larger task, they break it down into sub-cases even further. Notice how my assessment of "finest level of usefulness" can differ (perhaps greatly) from the person who really needs to get the work done.
This is also a time when a developer can reach out to someone else and say "I can do most of this but it would really help if person X could help me with this little piece Y." This is actually where I get most of my development tasking: I personally sit in multiple places during this process, from large-scale planning meetings to little fiddly tasks that no-one else has time to do.
PS: Making it a personal goal to get this answer rated higher than Joel's.... ;-)
PPS: My original response is now overcome by events since Fogbugz 7 has lovely sub-tasks. Program managers love those reports.
You may have better luck asking your questions in the FogBugz Discussion Forum
We use a combination of projects in order to accomplish your grouping goals. We also commonly setup a project "parking" Wiki where links to development cases, technical documentation, systems requirements, user documentation, external links to resources etc. can all be placed. It provides a good "one-stop-shop" for everything related to that project.
As part of that Wiki, we would then setup two specific projects. One in relation to the large overall goals/outlines similar to what might correspond to your Project Management charts/whatnot. One in relation to the development tasks of each feature as they are broken down into the smaller and more manageable chunks. You can then, as was mentioned use case linking to both reference the "master" cases in the other project as well as reference the project Wiki itself so that you can quickly and easily get back to all of your project related information which is conveniently in one spot.
You can accomplish a pile of different organizational structures using FogBugz, you just have to approach things a little differently sometimes in order to hit each and every situation.
Hope that helps.
haha, that article has a disclaimer, but I understand what you are saying.
We use Fogbugz and the only 'Feature' that I am aware of is under category and I don't think you can associated it with sub-tasks.
You can type in 'Case N' is the feature for this task if you just wanted to reference it in the case text.
That kind of stuff sound like is lies more in the project management domain instead of software used to track bugs.
thats a good question, i have asked that myself, too..
we currently test-drive fogbugz for 45 days in a group of 5 developers, and we currently create a "release" for major features. in fact we do not release it, but multiple releases together when something is ready.
there should definately be some sort of advanced task grouping in fogbugz.