Can I view remaining team capacity in Greenhopper?

[epohl]

When planning a sprint, I can enter a team capacity - the number of hours the team has as a whole during the sprint to work.

I can also add original estimates to tickets.

As team members log time against tickets, the remaining estimates are adjusted accordingly, so I can see how much WORK we have left.

Is there a way that I can make the system subtract the time logged on tickets from the team capacity, so that I can also see the remaining CAPACITY available?

It would be helpful to be able to compare remaining work to remaining capacity.

[epohl · Accepted solution]

It can't be done.

[James Sandlin]

The idea of each person just pulls from the pile is great as long as your company has a bunch of equal drones. As soon as I have teams consisting of developers, dbas, artists, etc., this approch does not work. I need to see how much work the artist has on his plate vs that of the dba. I'm not going to ask any project manager to architect a databse for me.

[Matt Summers]

I completely agree with this! I ran a development team at a previous company where we used TFS, and the capacity tracking was invaluable. Even if you only have devs to plan for, you end up with devs who are the "go to" for certain things, and so you can still end up with one person being overloaded, because they're the only person who can pick up certain tasks. In an ideal world, anyone would be able to pick up anything, but it doesn't work in reality.

[motherg]

I'd say if you're in situations like this then you're not planning the sprint as well as you could (i'm not saying we're not guilty of this either btw, it's the thing we're working hardest on resolving).

A way to skill up the team so they can be more "full stack" would be to encourage pair programming on a few of the stories where there is only one "go to guy". Any argument that this isn't possible isn't valid in my opinion (which is precisely that, just an opinion) - it just requires a good scrum master and some understanding from product.

[motherg]

To me this sounds like you're trying to get the tool to resolve something that the team should be able to tell you themselves?That sounds argumentative but it isn't supposed to be, a bit more of an explanation is needed I think.

At the end of a sprint planning session I assume you ask the team if they think they have enough work for the sprint? Let's assume they say yes.

So as far as they are aware, the forecasted work for the next two weeks (assuming you are in two week sprints) is enough to keep them busy and there are no dependencies on other features. But this might not prove to be the case - one person might finish their stuff really quickly and another might find that one of the things they are working on is way more complicated than originally thought.

In a scenario like that it is up to that person to be confident enough to tell the team that they are struggling, which means it is up to the scrum master to nuture an environment where people are comfortable to admit these sorts of things with no risk of being blamed.

You may find that introducing WIP limits to your columns is a practice that will help you as it forces the team to focus on finishing as opposed to starting - meaning that if there is nothing in the backlog for someone else to start, or the current number of features in play is already at the maximum (based on to your WIP limit) so the dev that is free can then help the one that is struggling by pairing with them. Have a watch of this video where Henrik Kniberg explains the awesomeness of WIP limits.

Remember, Scrum often shines a light on the problems that need to be solved. It - and the tools you use to implement it - are not the solution.

[C]

I find it dismaying as well that JIRA Agile has no easy way to view the loading of individual team members during the planning phase. That's a pretty serious omission in my opinion.

[Deleted user]

I would also like to have this feature as it allows me to track the remaining capacity viz the remaining work.

[James Sandlin]

Renjith: If it is not designed for that, why was the capability always available in the Classic Planning Board?

Rule #1 of software rearchitecture: Don't remove features a large number of users depend upon. The Sprint Leads at our company are asking us to move to Rally due to this feature being removed with the new Sprint boards.

[Renjith Pillai]

Doesn't the Sprint Report show it, last column?

EDIT: Not Sprint Report, the table below the graph in Burn Down Chart

[epohl]

No, that table shows the remaining work - that is, original estimates minus logged work.

I'm looking for remaining capacity, so that I can look at the info in the right column and say, "Crap! We have three weeks of remaining work, but only 17 days of remaining capacity."

[Renjith Pillai]

Greenhopper does not have a place you do team capacity planning. It is always, remaining estimate.

[epohl]

Which gets me back to my original problem. Does anyone have a workaround for this? Some custom field they use or another plugin?

[epohl]

It's interesting, because on the Classic Planning Board, you can see the capacity in the version and the time remaining. What would be perfect is if instead of original capacity, it showed remaining capacity.

[Renjith Pillai]

I would correct the wording a 'Remaining Estimate' not remaining capacity. Isn't it?

[epohl]

No. I can see the remaining estimates. What I can't see is how much time my team has to do the work. Work days X team members - vacation days and so on.

I can't start a sprint and say in this sprint, my team has a total of 100 days and then see a line on the burndown that shows me how many of those 100 are left as we go.

[Renjith Pillai]

That exactly is what I said, GreenHopper can tell you how much work is remaining, not how much work is possible to do (Capacity) by the team members. It is not designed for that.

[motherg]

Which isn't particularly helpful - I know you can look at the burndown but it's useful for metrics to see how much is left.

Pivotal Tracker has this feature and it's quite handy.

[Matt Summers]

TFS has this feature and it's hugely useful when planning a sprint. It shows you how realistic your sprint plans are, which developers and which teams are over-allocated etc. Sadly it doesn't seem to be part of JIRA.

[Paul Alexander]

My comments and several others are on this older post...thought it would help to link it: https://answers.atlassian.com/questions/108279/resource-capacity-planning-in-jira-possible

Regardless of how you slice it, this missing capability is a major headache on the Rapid Boards.

[motherg]

Yeah - no burn up chart is a real pain in the ass as well, it's way more useful than the burn down chart (they have it for the epics as well which means it must be able to be done).

One thing with JIRA AGILE is that does it a certain way, a way that is designed to force you to do "better agile" which isn't a bad approach, it just means it doesn't do things some people want.

For example, devs that are over allocated is a concept it doesn't support because you're (idealistically) supposed to look at the team capacity - put a column limit based on the number of devs in the team and work on the ethos that only one feature should be worked on at a time and everyone works together to sort it if one person is struggling (pair programming and the like). This approach really does rely on CI/CD and feature releases to be efficient though.