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)
??? 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.
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.
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 :)
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot