I need to start using JIRA for estimation and came across a scenario I have not found a good solution for yet. Consider an installation with more than one project which is already populated with many existing issues. Many of these issues are linked to other issues (not necessarily in the same project).
How can we configure a special link (say "parent of") and fields to record both effort estimate and logged work so that when any of the "children" are updated, some special field in the parent gets updated to reflect the corresponding aggregated values?
Just to be clear here, two issues A and B may be linked in more than one way (e.g. "parent of", "duplicate of", "relates to", "depends on", etc). However, aggregation of the special fields should only happen for a specific type of link. You can see the point when you think of the "duplicate of" link which clearly should not be aggregated.
Task & Sub-Task has exact same behaviour. Logging work in Sub-Task updates Task's work log counter.
Related
I am working in a big company and we are having a lot of JIRA projects, I would like to have a dashboard or a way to know if the projects that exist in JIRA are used, e.g if there are any issues in them (I don't need to see the issues just to have a number).
Can I do it without accessing to the database, do I need a plugin, is there a functional way to get the info? :)
thanks a lot
best regards
Adrien k
You can easily do this with the built-in Two Dimensional Filter Statistics gadget:
first, search for all issues in your JIRA instance. There may be an easier way to do this, but you can certainly use JQL like project=ABC or project != ABC.
save the search as a filter
go to a dashboard, add a new Two Dimensional Filter Statistics gadget. Select your newly-saved filter, select "Project" for one axis, and something small in number (like Issue Type) to the other axis. You'll also need to adjust "Number of Results" to exceed the number of issue types in your system.
save the gadget
Note that the Projects gadget also provides somewhat-similar information with fewer configuration requirements, but as far as I know, it doesn't show the numeric issue totals unless you hover the mouse pointer over the bars.
The company I work for makes a plugin that can do that - Structure
That's an example structure containing all issues in available projects, they are then grouped by project, and there's a column showing the number of sub-items (issues) in each group (project).
You can also add a structure to a dashboard/Confluence page.
On a large JIRA instance it be a bit on the expensive side to use it just for that alone though...
Jira has epic typed tickets and normal issues, and subtasks. Normal issues can be assigned to epics and ordered inside it. It is a visual thing only because it does not effect the dependency settings (blocks, blocked by, relates, etc...). In the view screen of an epic ticket we have the "Issues" section where we have
Rank to top
Rank to bottom
features for each item which is fine. But I really miss the "Rank one up" and "Rank one down" features. Using the Rank to top / bottom feature to move an issue by one in the list is a pain. I can also make the "Rank" field visible on the "Edit" view and see the associated number and edit it, but it is still very inconvenient.
Do you know any plugins, easier practices for it?
(The "Structure - The issue organizer" seems OK, but is to expensive for our setup (10-25 users, $600) just to achieve this goal.)
The Rank functionality (renamed Send To Top in a recent release) is implemented as a WebWork action (e.g. RankTop.jspa which then calls the RankAction class). To have your own action you'd need a plugin that implements a new action and uses the existing RankServiceImpl class to move an issue up or down one rank.
I don't know of any existing plugins to do this but I agree it's annoying trying to move an issue around in a backlog of more than about 40 issues
In Jira, linking items together is easy and useful.
For example, you can clone an issue easily: Create issue 100, clone it to 101. 100 then shows "this issue has a clone: 101" and 101 then shows "this issue is a clone: 100"
Similarly, you can mark issue 201 as being duplicate of 200 (reverse is 200 is duplicated by 201), and there are a few other link types.
My question is around the use of related tickets. One side of the relationship is marked "This issue is related to ..." and the other side says "This issue is a relative of ...".
How does your dev team define those two items? It wouldn't matter much except the display is different, making the link types slightly different and it just looks like they are different when one issue is "a relative of" a few other issues, but also is "related to" some others....
In JIRA, links are directed, i.e. not symmetrical. One part of the link is the "source", with one role, like "duplicates", the other is the "target" with another role - "is duplicate of".
When you have a symmetrical link semantics, like issues related to each other, this just does not work well. You can name both roles equally ("is related to" -- "is related to"), and this will work to some extent. You can expect "is related to" appear twice where you select a link type, for example.
In your JIRA configration, this probably lead administrators to define the roles for the "related" link type differently. But I guess this is more a bug than a feature, and you can safely ignore the differences between two names of the same relationship.
An example of link that we implemented is
Feature <-- describes --> Epic <-- details --> Story
A feature request is something that gets planned in a release.
The feature is described by a number of high level epics.
Stories are used to provide the details of these epics. Stories
are 'INVEST'
The link relationships are
Describes
x 'is described by' y
y 'describes' x
Details
x 'is detailed in' y
y 'details' x
Drawing a entity relationship model and naming the relations is helping a lot to develop the issuelink definitions.
Francis
Facing the very same question I've read seredas answer and it is explaining the background of directed links vs. symmetrical semantics nicely (+1) - interestingly though this explanation led me to a different conclusion for practical use in JIRA:
As Steve Melnikoffs comment correctly puts it, it comes down to how the reader interprets the text, here is how I do now: while Relation has the least specific link semantic, kind of a catch all link in absence of a more specific one, there is usually still one issue (the source) triggering this relation to another one (the target), and this fact is visible in the JIRA UI by listing the the active participants of a link in the left column and the passive ones in the right one.
I've checked this conclusion against a couple of projects I'm participating in, and I'd confirm this impression now, i.e. trying to apply relates to from that angle makes the participating issues a bit easier to interpret for me at a glance.
I have encountered similar feature in JIRA lately and I must say I was pretty much convinced that there's no feature hidden behind. I can understand the need of addressing the orientation of the relation between two task theoretically .. but practically it might not be that relevant because from my experience if you work with task tracking system on regular basis, you begin to ignore the features without any noticable effect very quickly.
.. what interests me is whether there's any plugin for JIRA that bases its functionality or UI on this attribute of relation orientation.
It really depends on the interpretation you and your teams agree upon.
In our JIRA we found the default "relates to" labels to be too ambiguous, so we modified the default inward & outward labels to read "relates to" and "is related to" to distinguish link direction, while agreeing that the issues are related in a nature that can only be understood by reading both issues on a case-by-case basis, and that the direction only indicates from which issue the link was created and means nothing more. Even with these changes, we have found that this link type doesn't actually provide much meaning beyond serving as a sort of reminder depending on context. Recently we created several new issue link types to more concretely indicate the nature of related issues, serving us /much/ better.
If you want to dive a little deeper into issue links and the default issue link types in JIRA, we have published some info here.
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.