I'm new to Jira so maybe my question is trivial. I need to get a statistics about a whole team and individual members. Currently I'm mostly interested in a mean time a person spends on a task (all our tasks have similar complexity).
How can I get this information in Jira? (Currently we don't arrrange sprints, we just create tasks and assign them to developers.)
On your filters you can show the attribute "Time spent" as column. Click on the top right on "Columns" and search for this attribute to enable it on your filter list.
Furthermore you can add Gadgets to your Dashboards. I see two gadgets here:
Resolution Time
Time Since Chart
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.
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...
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am trying to get my head around how story points are assigned to sub tasks and how the story points are managed in Jira.
I have a user story which we have estimated at 25 points.
A developer will take this user story and split it up in to a number of tasks.
Should he allocate a number of story points (of the 25) to each task? So in all, all tasks should add up to 25 points? And if the user closes a task of 10 story points, will Jira know that 10 story points have been burned from the main user story of 25 points?
Also, if at the end of the sprint the user story is not complete (say only 20 points have been completed), do I create a new user story of 5 points in the next sprint?
Let's pretend Jira isn't the issue for a moment.
First, tasks should be estimated in hours, not points.
Second, stories should only be counted toward the burn down when they're complete. (https://www.scruminc.com/sprint-burndown-by-hours-or-by-story/)
Third, consider what value you are getting from the tasks. In teams where we have done tasks, I've found the work of creating the tasks a great validator of whether or not the story has been defined well enough. Marking off the tasks has been of less use to my teams.
Fourth, when a story is not complete at the end of the sprint, it should go back into the backlog for the product manager to re-prioritize. It may be that it's no longer a priority (especially if it's taking much longer than expected).
https://pm.stackexchange.com/questions/3990/unfinished-stories-in-a-sprint
From teh scrum guide - "All incomplete
Product Backlog Items are re-estimated and put back on the Product Backlog."
Personally, I don't like to re-estimate because then some effort is "lost". If you don't re-estimate, then your velocity balances out over time, even if each individual sprint velocity bounces up an down.
In some cases, when stories tend to be large, when they are estimated to take more than 4 or 5 days you can easily lose track of progress within a sprint. This is especially true if the sprint is 2 weeks long.
Teams I've worked with have moved away from tasks in favor of smaller stories. (Currently, we use a rule that if it's > 13 story points, it's probably too big and should be split up).
All this considered, Jira should fall in line fairly well.
I find sub-tasks to be the hardest feature to use in conjunction with agile in JIRA. It always ends up being one of two scenarios, reminding why I try to never use sub-tasks to begin with:
Each sub-task is actually a story, and the initial story was way too broad. Every time I'm in this situation, the original story goes over 1 sprint, if not many sprints (causing the developer to rush, shirk, be stressed, etc)
Or, the sub-tasks themselves are too detailed and aren't worth putting in JIRA as their own issues; instead you should just add a comment to describe progress or ruminations to the original issue/story and avoid the JIRA overhead.
EDIT: In response to #DaveHillier
I don't like creating subtasks because it's more JIRA pushups. I think the allure of subtasks is that it makes your use of JIRA appear more structured, but I think an important part of using JIRA well is to keep issue count as low as you can, and yet still be effective for the team. I can't possibly justify this why I think issue count should be low in this thread, other than to say, ' with JIRA, less is more'.
Let me show you what I do that satisfies the following requirements:
transparent progression on the issue (other users can be notified if they want)
lets me organize my own thoughts
remains inline with the issue, letting someone look at my one story and understand quickly where I'm at
I make a list in the description of my main story, using JIRA markup like so:
Build the thing. Lots of words blah blah.
h3. Progress
* code it
* test it
* deploy it
Then using JIRA markup, I can add little green checkmarks as I get done using (/) next to each bullet point, letting any 'listeners' of the bug stay abreast of my progress.
Build the thing. Lots of words blah blah.
h3. Progress
* (/) code it
* (/) test it
* deploy it
Should he allocate a number of story points (of the 25) to each task? So in all, all tasks should add up to 25 points?
No, tasks of a story are not assigned any points because one completed task will not provide much value to the client / enduser. All the tasks combined will deliver a working piece of code much would be of some value for the enduser. In essence a story is not complete till all of its tasks are done. Remember: Working software is the primary measure of progress.
if the user closes a task of 10 story points, will Jira know that 10 story points have been burned from the main user story of 25 points?
Since task dont have any points (as mentioned above), this becomes obsolete.
if at the end of the sprint the user story is not complete (say only 20 points have been completed), do I create a new user story of 5 points in the next sprint?
If a story remain incomplete at the end of the sprint then you have two options, either move the whole story back to the product backlog or if any part of the incomplete story can be salvaged and treated as a working piece of software then split the story into two. Working part will be considered complete in the current sprint and non-working part will become part of the product backlog. This part will be treated as a new story and it should be estimated as a separate story. You cannot split story points between the working part and non-working part.
Sub tasks don't work well in with Jira Agile.
In my current team we don't use them.
I disagree with sethcall, that there are no reasons that I should be using sub tasks.
I'd like to track that I can't easily at the moment:
tasks for completing each point of a definition of done
tasks to make acceptance tests pass
There are plugins that support acceptance testing, (e.g. Behave for JIRA) however I have no experience of them.
Some have suggested to use custom fields for your definition of done (and acceptance tests), but I'm not keen on that idea as there are too many exceptions to the list.
Here is an article that suggests using checklists for acceptance tests.
Might be worth a try.
To manage the scrum development process of a big community website, we decided to move to JIRA/Greenhopper/Bonfire.
I have created elaborate Epic, Stories and Tasks, all well linked to each other.
I would like to develop the "Product Story" in more detail all the time by adding new Epics, new Stories to (new or existing) Epics, etc.
To be able to do this properly, I want to have a hierarchical overview of all issues: Epics, Stories, Tasks, etc.
Question: How do we set this up in JIRA?
Why?
=> My approach is from the point of view of project management: getting everybody aligned around the same vision. However, I think it is part for everyone in the team -especially for the ones who are actually building the product- to have a quick view of how their current or planned work fits into the big picture.
Stories have sub-tasks, which will be shown hierarchically in the Sprint, but all sub-tasks have to be completed in the sprint of the user story. I also think when you create a story you can specify an epic, which will create a hard-link ( the same as story -> sub-task). Is there a reason you want to use a Jira task? To me it looks that in a SCRUM environment you only need Epics, stories and sub-tasks. Maybe some spikes and support tickets from time to time.
Coming from a tool like Rally, I can appreciate you wanting to see the big picture. We transitioned from Rally to Greenhopper over a year ago mainly because of costs. Lets just say you get what your pay for. I haven't found the feature you're looking for in Greenhopper, it only has a single threaded view for things like Epics to Stories (on the planning page) or Stories to tasks on the (on the work page)
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.