Resource/Capacity Planning in JIRA possible?

[Tudor Hofnar]

I'm trying to see if there is a way to setup Resource Planning in JIRA. Maybe there is a plugin?

Basically I need a way to limit the amount of issues added to a sprint in GreenHopper. So for example if we have 5 developers and 1 goes on vacation, the sprint should know this and limit the amount of issues we add (based on the hour estimate) since we have 1 less developer...

Is there any way to achieve this in JIRA/GreenHopper or a plugin?

Thanks! (JIRA, OnDemand, GreenHopper)

[Chris Pettigrew · Accepted solution]

??? Renjith, I think you are confusing a few things. For starters, planning poker estimates story points based on the level of complexity for stories. Team leaves should never be taken into account at this level because 'level of complexity' has nothing to do with the hours of work your team members are putting in for a given sprint. If we deem something has a story point value of 5, it doesn't suddenly become an 8 simply because I am taking 3 days off during the next sprint. Have you actually been involved in Agile software development before? Teams story point out the level of complexity for each story (initially). They then take that story and break it down into individual tasks for which actual time values are placed against them. Those tasks are then assigned to developers to fill up the total days allocated in a given sprint. The challenge that everybody is trying to solve is: Given a bunch of tasks that each have an hourly assignment to them, with GreenHopper, I have to manually tally up the hourly tasks that I assign to each developer to ensure I don't overshoot, say their 40 hour work week.

As you may have noticed, there have been a number of posts asking about this, and you have, for some reason, shot down every request to deal with resource planning. I'm not sure if you have reviewed your competitor's products, but to say this 'doesn't belong in an Agile development tool' couldn't be further from the truth. Your primary competitors, namely, VersionOne and Microsoft TFS BOTH have this functionality in it. Don't get me wrong, I am a proponent of Atlassian, but to simply say 'this is out of scope of GreenHopper' is being completely ignorant to the users of your product.

[Paul Alexander]

Chris' comment here is so very spot on:-). While I am still actually buried in work today, I took time to re-read this thread and his comment. Having just done 5 sprint planning sessions on Fri, I can't begin to tell you how vitally critical it is to get capacity planning, at least to some degree, incorporated into GH. I have a scribe with me who tallies up each resource's hours and we must keep doing so until we get each member's capacity satisfied...of course, with some padding baked in for unplanned work.

This is part of any forward planning effort. As a long time TFS user, this concept is very much NOT NEW. If the GH team does not see value in this, please help us understand how you do this in your sprint planning sessions today.

It's nighmare-ish, to say the least, getting a count on each resource's hours...and it all depends on who owns the parent issue and the subtasks. Before any good team starts a sprint, doing this exercise is critical if we expect to meet the committment and progressively see a steady downward burndown. I, too, am a huge fan of the Atlassian products, but I don't get it on this particular capability. Again, if we are not supposed to do this effort here, where do you do it? And at what time?

Lastly, I respect that some Agile teams do not use hours as the estimation value - they sign up for enough stories for their expected velocity, and they attempt to meet that committment...to me, this is purely a guess and doesn't provide the kind of metrics I need for my teams' growth and improvement (e.g., burndown (will we actually meet the committment based on hours remaining?, are my task estimates high or low?, etc). So, I don't want to hear someone suggesting that we just do the task level planning after we "start the sprint" in GH...this defeats everything IMO.

[Renjith Pillai]

Hey Chris,

My comment was not say that is not something which is important. I do agree that it an important aspect of any project and if JIRA Agile (a.k.a GreenHopper) was facilitating that it will be great. My comment was that, the current features or development is not aiming to cover that segment at the moment.

And to answer if I have done Agile software development before, yes, right from 2007 :)

[Nik Shornikov]

Okay, that was a rhetorical question... the real rhetorical questions is, have you been involved in Agile development before where sprints with half the devs on vacation were successfully treated like sprints with everyone on deck? Actual question: what do you mean by "current"? It's almost a year later.

[Matt Hart]

I've created a combination of fields, a report, and an Excel spreadsheet to enable capacity planning with JIRA.

Fields: added Estimated Hours and Hours Remaining to technical task/sub-task - basically our tasks in a story.

Report: I have a report I run that has these columns:

Summary | Key | Est Hours | Hours Remaining | Assignee | Sprint

The report is: "project = EM AND issuetype in (subTaskIssueTypes()) AND Sprint = 44 ORDER BY assignee ASC, key DESC"

In the Excel spreadsheet, I have 2 fixed sheets plus 1 for each team member. One sheet is simply labeled "JIRA". I run the above report, export to Excel (current columns), then copy/paste the entire report into that sheet. The second sheet is the capacity worksheet, containing sprint start/end, holidays, number of ideal work hours, plus planned sprint activity hours (like standups, planning, retro, demo).

Then I have a line entry for each team member with % capacity, days off, est hours, hours remaining, workload capacity. The hours fields link to each member's sheet.

Finally, I wrote a VBA Excel macro that reads the JIRA sheet and adds each team member's line item to their sheet, causing an automatic calculation back on the capacity spreadsheet. Works like a charm - we now do our standups directly from the worksheet, as it shows each persons work and is easy to see how things are going. The workload number is exactly what I needed to make capacity planning with JIRA work correctly - basically it's similar to Rally's Team Member viewpoint in a Sprint, plus the automatic calculation of available hours (that you have to enter manually into Rally).

[Ryan Thomas Correia Ortega]

Matt Hart , could you share your spreadsheet? Thanks!

[Maurice McCabe]

I would like to see it too.

[Alicia McLain]

Me too

[Herman Burema]

Can you share this solution of yours with me, I like to experiment to fit our JIRA implementation.

[Suresh Moorthy]

Can you please share the spreadsheet?

[mamta rathi]

Mat

Can you please share your excel sheet which will be really helpful

[Inprowiser Engineering]

Try this add on: https://marketplace.atlassian.com/plugins/capacity-tracker-plugin/cloud/overview. It allow users to configure resource capacity, leaves, working days, public holidays, and displays work allocation charts - in a nutshell - everything you need for Sprint capacity planning and tracking.

I worked with couple of scrum masters earlier who were using similar spreadsheets. But all of them and their teams complained about too much of manual effort and maintainability hassle. Then why not to use an add on which does the job for you faster, automatically and more elegantly!

Allen

[Amit Bismut]

too bad this basic functionality cost more $$$.

[searsfranchises it]

No doubt, I am consistently frustrated by JIRA's lack of basic functionality and response to buy a plugin from the marketplace. 

I think the lack of integrated capacity planning is a huge downside to using JIRA.

[Inprowiser Engineering]

Hi,

If you are using JIRA cloud instance, then check out this useful add on: https://marketplace.atlassian.com/plugins/capacity-tracker-plugin/cloud/overview
It allow teams to configure resource capacity, leaves, working days, public holidays, and displays work allocation charts - in a nutshell - everything you need for Sprint capacity planning and tracking.

Allen

[scott.fawcett]

New Jira user here (after 10 years with TFS).  We need to pay for a feature that's required for sprint planning?  And competitors provide it as base functionality.  Very odd!!

[Emily S Bishop]

Hi Scott - I think you're missing a point. There's nothing free in this world. I have worked on software procurements and vendor management for several years now, and most of the time when they claim or indicate something is free, its more often then not the cost is bundled or wrapped somewhere.

I know from a user standpoint we find something inclusive more convenient and comfortable but let me assure you that it has its own cost.

There is a huge different in Atlassian and Microsoft business model. Microsoft is a one stop shop, making everything possible bundled into their portfolio and charging their clients accordingly (huge!) while I see Atlassian as a marketplace, they have core framework and softwares but also offer place for independent people or teams to build or extend the functionalities, features and capabilities without any limitations. Also the cost model is pay per use, i.e. you choose to have less functionalities or add-ons and pay minimum, or you extend based on your needs with additional cost (which is not huge!).

So what I am saying is that its not apple to apple, when we say something is free in TFS but not in Jira, and again nothing is free anywhere! :) Bringing different perspective to the table and hope this help you understand the hidden costs of TFS.

[Bo Sanchez]

but it is free in tfs

[Jack Daniel Morilla]

This is my question as well, been using my whole life the TFS, then I transferred to other company which we use Jira, Capacity Allocation cost a lot, you need to procure another plug-in to for the capacity planning.

[James Sandlin]

Sad that we now much purchase yet another plugin to implement features which existed in Greenhopper Classic.

Atlassian is not listening to users, rather creating a system where we must purchase JIRA + Greenhopper + Even more plugins.

[James Sandlin]

Classic Planning board provided this capability. I could plan, knowing the workload of each member. I still cannot believe Atlassian is not providing a replacement. Is it in the schedule?

[Paul Alexander]

Yes, please, Atlassian...is this on the schedule? Is there an issue you can point us to in your dev backlog? I'm still suprised so few are here discussing this. What are folks doing to compensate? I really need to avoid spending another $3K/year to add the Tempo plugin, which may or may not provide this level of capacity planning. I don't have a test on-demand instance so really not interested in taking tempo for a test drive and having to explain to my population what all of that functionality is there for as I attempt to validate the product's form and function.

[Nimitt Desai]

Capacity planning clearly belongs to GH. I keep searching for a plug in for capacity planning because I need to maintain this annoying spreadsheet sprint after sprint.

[Renjith Pillai]

In fact I consider this as out of scope of GreenHopper. The way it should happen, IMHO, is that the team do the sprint planning, estimate using poker cards, and the results get into green hopper. Also in this process the leaves of team members are taken into consideration. The actual process of estimation is not really with green hopper. And once started, the burn down will tell where the team is.

[James Sandlin]

So what you are saying is we should pay thousands of dollars for GreenHopper aka Agile just so we can turn around and continue using stickie notes for planning? If I'm using poker cards (stickie notes) for planning, I may as well keep the scrum board with columns on the board with stickie notes. Oh well... no need for GreenHopper.

[TylerA]

If you want the system to reject your action when adding an issue to the Sprint, based on some arbitrary parameter, then you would need a plugin for that sort of power.

With an OnDemand instance, there isn't a way to prevent adding an issue to the board but this tutorial explains how folks tend to plan and track changes in GreenHopper with a team.

[Tom Ng]

I would recommend a new app in the marketplace TeamBoard Team Resource for Team management and TeamBoard Project Resource for projects and program, it has morden design and rich features. You can also request new features and the team react quickly.

Note: I am working for DevSamurai the maker of the app so my answer maybe biased

[Niall Rice]

Yes, very frustrated with the lack of features in JIRA and always have to refer to add-ons via the marktetplace, which is near impossible to get within a larger organisation.

JIRA has velocity, which means they kinda support SCRUM, but I cannot simply set the capacity of the sprint for the availibilty of devs. A capacity would calculate the velocity relative to the capacity. Now I need to do it manually in an Excel to find out how many points we might be able to achieve on a sprint where people are on holiday.

[Abhay_Tilwankar]

Same here Niall - thanks for your response and hopefully we will find something soon ! We tried a few add-ons but nothing seems perfect. It will be great, for the forum experts to guide us.

[siobhan]

Hi @Niall Rice and @Abhay_Tilwankar Float is a resource management software that has just launched an integration with Jira. You can check it out here. If you set up your sprints as projects in Float, you can assign a total budget in dollars or hours to track your spend and forecast your team's capacity against this. The integration imports and syncs your Jira projects and issues directly, to save any double handling!

[Dwight McPeak]

Capacity planning is something we did in painful ways back when we still used waterfall as our development process. If the question we are trying to answer is "Are all of the developers busy during the sprint?" then the answer is always yes. There is always something to do.

Sizing is how much work is there to do. "Populate three fields on the page from the database" would always be the same size for the team.

Estimates are how long it will take a particular person on the team to do that work. You get a different estimate depending on who picks up that particular task. Right now we are not bothering with individual estimates.

We size all of our stories and fill up a sprint based on our velocity. We break up the stories into sub-tasks with the guideline that no sub-task should take anyone on the team more than a day to complete. That way we expect to always see movement each day during our scrum.

We do NOT pre-assign the work. Whenever a developer finishes a sub-task, they go back to the board and start at the top of the list which is still in priority order and they find the next available sub-task and put their name on it. That sub-task might be a code review or documentation or testing or actual coding. You never know what you might get. It’s part of being on a multi-skilled team. We have members from our QA department embedded in the team. It doesn’t mean they are the only ones that test or write test scenarios.

The effect of always pulling work from the highest priority story is that the highest priority work gets done. We don’t have 10 stories that are all 90% done, we have 9 stories that are 100% done and 1 story that rolls to the next sprint.

If we get ahead we can pull the next story from the top of the backlog that has already been approved to work during our backlog refinement meetings.

[Abhay_Tilwankar]

Hi All Is there a better way to do it now ? This thread is an Old one - Tempo / Clockify .. Bare JIRA .. do suggest any links I could read up upon.

[Paul Alexander]

I think I posted in another few related questions here on the answers board...may be worth repeating here though.

The workaround I employ with my teams is to setup a dashboard in Atlassian using the Workload Pie gadget. In my instance, our subtasks contain the work estimates in hours. So, I create a filter like the below to locate all subtasks sitting in un-started sprints against Agile boards in all projects owned by A-Team. Using this pie graphic, we quickly bring in sufficient subtasks for everyone to get them up to their capacity for the sprint. I use ~50hrs per two-week sprint per resource (leaving 30 hrs per sprint for unplanned production support, morning standups, and end-of-sprint retrospectives). Once happy with the distribution, you start the sprint(s).

category = A-Team AND
issuetype in subTaskIssueTypes() AND
Sprint in futureSprints()

I should note that the business folks have already identified the Stories we will take on for the next sprint. We identify any gaps in workload by assigning additional, critical production support issues to get resources up to their capacity.

[Martin Suntinger]

Just came across this thread: We had the same problem for years, and finally decided to build an add-on that really solves this challenges and saves you from manual capacity planning work.

Here's more details: http://radiantminds.com/roadmaps-for-jira/

And a short screencast video: https://www.youtube.com/watch?v=TuhwE9V5hY4

Would be great to get your feedback on this!

Note: It's currently available for JIRA Download only, OnDemand coming soon.

[Martin Suntinger]

Thanks for the feedback, Paul! We'll do our best to get it quickly on OD!

[Paul Alexander]

Very interesting and what appears to be a well done implementation providing what looks to be a lot of high value-add. Can't wait for OnDemand! Kudos and thanks.

[Ryan Thomas Correia Ortega]

Matt Hart , could you share your spreadsheet? Thanks!

[Kristin Hreinsdottir [Tempo]]

I recommend you take a look at the Tempo Planner - http://www.tempoplugin.com/products/tempo-planner/

[Dicky Sum]

My team just finish the sprint planning first time using GH. One of the developers from another department wrote a little tool that calculate our capacity similar to TFS. Then we have a write board were the manager manually tally the hours each time when a task is assigned. Kind of a pain to do this manually. but at least we won't over commit.

[Dicky Sum]

My company is switching from TFS to JIRA GH and I also wonder why there is no resource management for setting developer's capacity. GH gives me the ability to set renmaing hours for the tasks, yet it doesn't have the feature to ensure I don't over assign too many tasks to the developers. Even if I only use story point to plan, I will need to figure out a new velocity if the team member changes.

[Paul Alexander]

Atlassian, is there a related story in the Atlassian backlog to address capacity/resource planning? Or is there anything similar in your backlog that we could review for consideration? I guess I could look for myself; just wondering...

More importantly, this thread is pretty small. What are others out there doing to compensate? I am very curious.