What are the main differences between the Implementation tab and the All Link tab in TFS 2010? I ask, because we have a need for Requirement work items to have an Affects/Affected By (or maybe Predecessor/Successor) link type with Task work items...instead of the parent/child link type you are limited to in the Implementation tab. Essentially, we want the ability for a given task to be able to have links to multiple Requirements.
As extensible and free-form as TFS 2010 is...I still hesitate a bit to go this route without knowing what kind of possible negative impact this approach could have when it comes to future reporting needs or something else.
Any thoughts? Thanks!
The implementation tab is constrained to only Task work items that are children of the Requirement. The All Links tab shows every link associated with the Requirement (including Tasks). The FORM section of the WIT definition defines the layout... and the links controls. You can adjust these tabs (or add new ones) there.
As for this particular change, I would tread carefully. Having tasks with "multiple parents" can lead to a lot of confusion and over-engineering. I've seen many teams try this approach only to abandon it in favor of a simple parent/child relationship.
What is the main reason for wanting tasks to be tied to multiple requirements?
Related
I want to create a project in the JIRA.
The project should be able to select the type of work and choose another project.
I wish user can create selected another project because there are many large numbers of projects.
and type of work can choose two or three depth.
First.
type of work use customfield.
choose another project use component.
-Team member should be an administrator permission in project.
Second
type of work use customfield.
choose another project use label.
Is there a better plan?
Last I want to know difference between label and component and version.
I think user can create label and project admin can create label, component, and version. The label applies entirely. But component and version applies project.
It sounds like you may be trying to do something which I don't think is possible: an issue is in exactly one project at a time.
Components are a lot like labels, but are selectable from a set defined for a project. It can sometimes be useful to define components which align across multiple projects. You're correct that creating components requires admin privileges, while anyone can create labels; this can make for an excess of different labels if they aren't used with some care and discipline, but the components list will stay as clean as the admins keep it. An issue can relate to multiple components and have multiple labels. Sharing labels or components across projects may achieve what you're after.
Because components are a "privileged" class of labels, it's often wise to spend a bit of time considering a sensible scheme for them based on the anticipated breakdown of issues; changing them in bulk midway through a project can be tedious.
I'm less familar with versions; I'm not sure whether an issue can be linked to multiple versions. They are usually used to group issues for release planning, but that isn't imposed by the tool, they could be used for something else; it might be confusing for users making assumptions about what "Version" means, though.
It's difficult to answer your question, as there are some grey areas, but will try to briefly explain the difference between labels, components and version.
Project and components
First of all, a project is (a project) a collection of issues (stories, tasks, bugs, etc.), so components are just sub-sections of a project. They could be either defined based on the architecture of your product. Also, a component can be assigned by default to a particular user or group. An example of components could be database, UI, notifications.
Labels
Labels help you categorise and search for an issue and have the advantage of allowing multiple labels to an issue.
Versions
A version is a set of stories and bug-fixes and helps you plan the release of those stories and fixes to the customer.
The main way to categorise the type of work within a project is to add different types of issues and for each one define custom fields, screens, and workflows.
Hope that helps you address the problem!
This blog has a definition of epics in JIRA:
Epics are significantly larger bodies of work. Epics are feature-level work that encompasses many user stories. Using the above example, an epic might be the entire account management feature and the ability to see previous purchases.
So if (as a product owner) I have a large feature I want delivered that will comprise many smaller tasks and likely span sprints, then an epic is a good choice.
However, I could just as easily create a (using the example from the blog) "Account Management" component, and any task related to that feature have that component assigned.
Similarly I could also just as easily use a label of "Account_Management", and any stories/tickets that are a part of the Account Management feature simply get tagged with that label.
So my question: why/what circumstances would you use an epic? why/what circumstances would you use a component? Why/what circumstances would you use a label? Ie - all three (epics, labels, components) seem to serve very similar purposes (grouping a collection of issues), what's the difference?
With labels and components if you want to select a group of them you need to use issue search. If you are using epics you can use issue search as well, but you also get built-in functionality in JIRA Agile.
In the backlog view of a JIRA Agile board you have an Epic tab. This tab allows you to select the issues associated with individual epics. Plus it has functionality that makes it simple to add new issues to an epic. The final advantage is that the epic name is displayed brightly coloured alongside the issues in the list. This can be very useful when viewing the backlog and getting a feel for what work is coming up next.
You can see more about epics on the Atlassian Working with Epics page.
Components are useful for the technical team as they can span across many epics. A typical component might be 'database' or 'UI'. JIRA offers the option to assign work for a particular component to a particular JIRA user. For example, all issues created with a component of 'database' could be assigned to Jill Smith.
Labels are much more adaptable and they have the advantage of allowing multiple assignments (so more than one label can be associated with an issue). With labels it is very much up to you how you use them.
Epics by definition are short-lived issues when compared to the project as a whole. Components and Labels on the other hand are forever. And, you should stick to use them by their true meanings however tempting it may be otherwise.
Create Epics for features, or as mentioned by #Sateesh, for bigger stories. They should solve their purpose, and once the business need is done for, they should then be closed/done.
Components are not features. They are the technical parts of the system. They can also be used for categorizing your parts or... well, components :P... of your product.
Labels can be anything, as mentioned by #barnaby. Typically, they are keywords, catch-phrases, words people may want a task to relate to, etc. I use it mainly to make issues better searchable from a long-term perspective. There is a JIRA plugin which gives you a JIRA label cloud (for purely fancy purposes, I feel :D) that might interest you, too.
Addition:
Atlasian now have created a new article explaining this from their perspective.
https://www.atlassian.com/agile/delivery-vehicles
My opinion / usage.
Labels and Components are almost straightforward and well answered already.
Components examples
Android client app
Server API
Database
etc.....
Labels examples.
Business logic sectors (ex Orders,Invoices,Users, Products)
Code Quality Improvement
Refactor
Usability
User request/complain
Generally whatever helps categorize things.
But let me give my two cents about Epics because i find this phrase way too generic.
Epics are significantly larger bodies of work
Larger? 10 Sprints? 10 Stories? 20 Stories? or what?
Personally i would classify Epics as Goals or Major Releases.
At a Yearly / Quarter Retrospective your company holds a meeting with all members and stakeholders , and concludes to the following
We need to target more platforms (epic = Platform Expanding)
Our support personnel needs more tools to handle issues. (Enrich Support tools)
The software is too hard to use! ( Redesign UI UX)
This would mean 3 epics with set of stories to cover each of those generic requirements
Epics are bigger stories which require more than one sprint to complete. One Epic may involve several user stories. Each user story may belong to one or more Component. Say, you have an epic airline availability search. This may have multiple User stories like OW search, RT search etc., Some or all of them may involve components like cache, travel policy & booking engine.
Labels are just for convenience. It may not have physical significance.
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.
This is likely by design for big teams with proper QA departments, but we are only 3 devs and do round robin QA on each others work.
The problem is say person A creates a bug, and assign it to person B, and the person B resolves the bug, TFS reassigns the bug to the creator.
This makes keeping track of your own fixed bugs nigh impossible.
Is there any way to change this behavior?
Thanks
leppie
The easiest way to make changes like this is with the TFS Power Tools. Among many other things, it will add a "Process Editor" area under your Tools menu in VS. Use the "open WIT from server" feature to download the work item type that's bothering you, make the changes you want (under the Workflow tab in your case), then run "import WIT" to upload it back to the server.
The complete XML specification for work item types is documented on MSDN, but as usual it's quite dense. Here's a series of blog posts that walks you through the possibilities.
In the default TFS setup there are three work item types: scenario, task and bug. That last one is quite straightforward, and task also: it's a specific job for a team member to complete. But I think scenario is a bit vague.
I usually create a scenario for larger and more general units of work: for example "Create functionality to add employee lines to an employer." Smaller, more specific work items would then be tasks, for example: "Create detail form.", "Create save method on server.", etc
When I check in changes I link the changeset to the scenario AND to the specific task. Is this a good habit? How do you deal with tasks and scenarios? Any resources to best practices?
I've also heard scenarios are actually meant for use cases, is this so?
Scenarios can be any user story.
You only need to check in to the task.
When tasks are created, they should be linked to a Scenario first, before assigned to developers.
That way the association between checkins and scenario is automatic (and reportable).
No point double handling
In the MSF Agile template, Scenarios can also be thought of as "User Story" - kinda like a lightweight agile use case.
The Scenario details the broad picture of the functionality that is wanted to be implemented, recording a single path of a users interaction with a part of the system. For example, in Stack Overflow a couple of Scenarios might be "Ask a Question" or "Answer a Question". Scenarios and Quality of Service Requirements can be thought of as top level work items in MSF Agile (i.e. the work items that define the system) with Scenarios being functional requirements and Quality of Service being non-functional requirements.
I tend to create multiple tasks from each scenario and typically only record my check-ins against the task. In TFS 2010 properly hierarchical work items are coming which will make this way of working easier to report on. Currently work item associations are bi-directional (i.e. you can say that a task is associated with a scenario but you cannot say that it is a child of it).
There is nothing wrong with marking your check-in against the task and scenario, just that it creates more work for you when checking in. Also, the scenario might be getting delivered by a number of developers were-as a task tends to be down at the granularity of individual person activities.
If you are doing a lot of associating of a work item to a scenario, then the following tip might be handy for you (http://www.woodwardweb.com/vsts/top_tfs_tip_3_r.html). It shows you how to modify the standard MSF Agile process template to remove the ability for check-in's to resolve the Scenario but just associate the check-in with that work item. Resolving on check-in for a long running work item like a Scenario is nearly always not what you want to happen - but is the default behavior out of the box.
Hope that helps.
If by "default TFS setup" you mean the "MSF for Agile Software Development" project template, then a scenario is defined as follows:
A scenario is a type of work item,
recording a single path of user
interaction through the system. As the
persona attempts to reach a goal, the
scenario records the specific steps
that they will take in attempting to
reach that goal. Some scenarios will
record a successful path; others will
record an unsuccessful one. When
writing scenarios, be specific as
there are many possible paths.
To get a bit more info on this, have a good look at the "Documents/Process Guidance" folder under the project in team explorer - it explains the recommended process fairly well
You can think of scenarios as representing the users perspective, whereas tasks are the developers perspective. According to the MSF Agile documentation a scenario "represents a single path of user interaction through the system you are building.", and a task "identifies a specific item of work for a team member to perform."
Tasks can be linked to scenarios. When checking in you, as a developer, have solved a task, not the scenario, so you should relate the changeset to this task.