nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Accepted answers

epohl

It can't be done.

All comments

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 can't be done.

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.

unknown

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

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 Winward

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.

C_3pp4zi

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.

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.