They won't Log Work, and They won't set Original Effort on a Card- So They won't get any Benifits

[Brenda Higgs]

Hello Atlassian Community, I have a client that does not want to have their people logging work to a card, but yet they want to be able to use JIRA to forecast new work coming into the queue by skill set, by a person.  Other than a custom field that would have to be updated is there a plug-in that would allow a person to be allocated to a thing by start date - end date and then show if they were over-allocated or under-allocated?  Right now they are using a simple spreadsheet, but they want the data in JIRA.

[Bill Sheboy]

Hi @Brenda Higgs 

There could be marketplace addons for such date-based capacity planning.  You may want to try searching on those terms in the marketplace...or perhaps a vendor will respond to your post here.

Another idea...If your client doesn't want people logging work (time tracking?) on Jira issues, and they want to be able to forecast, that would leave counting things and how long they actually take to build. 

If the team was using some form of Kanban methods, they could use actual build cycle time (start of work to "done"), the amount of work in progress (WIP), throughput, and the consistency of those measures to forecast.  For different skill areas you would need a way to identify issues by skills-needed, and adjust accordingly.  The built-in Jira reports could help do this.  If you have agile/Kanban coaches available, perhaps have a chat with the team to see what they think.

Best regards,
Bill

[Brenda Higgs]

Thank you Bill, The client has 1 project so it would be possible to roll up metrics by a person using the workload balance or timecard feature, but without wanting to log original hours on a work item and there is no bucket card to put the capacity.  I have seen many companies I support resort to an excel spreadsheet for capacity planning and the two never really tied to the actual work except in a atomic way.

[Alex Koxaras _Relational_]

Hi @Brenda Higgs ,

My two cents would be to convince your client, that using:

• Original Estimate
• Time Spent

Is on their benefit and not on spying if people are working on not. Metrics can be used only if they have actual values in them, and not guessing. Following empiricism, they should guestimate the amount of work that needs to be done, based on what they know on the date they do the guestimate. Logging work can be done after the work has been finished (approximately that is).

Alex

[Brenda Higgs]

Thank you Alex,

Yes, it all starts with a change in thinking.  Start at the work item and it will flow up to a EPIC, to a Release to a Value Stream.  Makes sense, but the effort to move the organization there does not support the time the simple spreadsheet provides.

[Alex Koxaras _Relational_]

Hi @Brenda Higgs 

You shouldn't expect this change to take immediate effect. It will take time. Time your company should invest. :)

[Emre Toptancı _OBSS_]

Hello @Brenda Higgs

First of all, I want to say that I agree with the other answers. Making entering worklogs is the most healthy way of getting data for future estimation. People in your organization are like production machines in your factory. You want to know what they spent their time on.

The next acceptable thing might be to use issue status times for this. You can measure how long each issue stays in each status to make estimations. Before giving more details I must warn you that:

• This method gives good data only if Jira issues are updated on time. That means, people must move issues to InProgress as soon as they start working and resolve issues as soon as they are done.
• This method is weak on overlaps. If anyone is working on more than one Jira issue at a time, this will give inaccurate results because there will be more than one issue in In Progress at any given time but the user will be working on only one of those issues.

Anyway, if you choose to use status times to get some information, the needed data is available in Jira issue histories. But Jira does not give this as a ready-to-consume report.

For an automated solution that offers great flexibility and details, our team at OBSS built Time in Status app for this exact need. It is available for Jira Server, Cloud, and Data Center.

Time in Status allows you to see how much time each issue spent on each status or assigned to each assignee. You can also combine statuses into consolidated columns to see metrics like Ticket Age, Cycle Time, or Lead Time. 

You can calculate averages and sums of those durations grouped by issue fields you select. (For example see the total InProgress time per Epic, or average Resolution Time per issuetype).

    

The app calculates its reports using already existing Jira issue histories so when you install the app, you don't need to add anything to your issue workflows and you can get reports on your past issues as well.

Time in Status reports can be accessed through its own reporting page, dashboard gadgets, and issue view screen tabs. All these options can provide both calculated data tables and charts.

Using Time in Status you can:

• See how much time each issue spent on each status, assignee, user group and also see dates of status transitions.
• Calculate averages and sums of those durations grouped by issue fields you select. (For example, see average InProgress time per project and per issue type.)
• Export your data as XLS, XLSX, or CSV.
• Access data via REST API. (for integrations)
• Visualize data with various chart types.
• See Time in Status reports on Jira Dashboard gadgets

https://marketplace.atlassian.com/1211756

EmreT

[Brenda Higgs]

Hello Emre,

Yes, I've used "time in status" "tempo timesheets" and "timesheets" in JIRA all would give the client what they need.  But what they are looking for is a resource capacity matrix in JIRA that would so resource allocation over a period of time, and as cards are created the hours would drop for availability, but without logging original hours it's a black hole for what the need is.

Bob S.  30 30 30 30 30 30 - Available

Bob S.   10 10 10 10 10 10 - Used

Bob S.  20 20 20 20 20 20 - Remaining

Not necessarily tied to a work item.