GREENHOPPER: Can i set certain amount of workforce capacity hours per sprint per department (component)

[ООО _ИНФОТЕХ_]

Hi,

Is it possible, during a sprint configuration (greenhopper/scrum), to set certain amount of workforce capacity hours per sprint per department (component). So, I can see remaining amount of hours per department per sprint, when I drag issues into it. (it will automatically deduct original estimation time of the issue from the total capacity of hours of the related department)

As I can see now, I can only set up start and end dates of every sprint, as well as working days, this is really not usefull, as in certain sprint, I will have issues related to different departments (components) and different departments have different amount of employees, thus different developement speed per iteration. So I need to see how fulfilled is certain department per certain sprint.

Would really love to see any solution!

Thanks,

Mike.

[Renjith Pillai · Accepted solution]

Quite frankly, that is not scrum. That is the traditional way for project management which says available - spend = remaining. Which is not true in reality and that is what scrum is trying to address.

The planning part of sprints is not really inside GreenHopper. What you enter as the estimate for each of the tasks is summed up and that becomes the total of the sprint. This is what burned down by the burndown chart in sprint. The remaining estimate which updated by the team members on a daily basis tells you the trend of the burn and this decides if the sprint will complete successfully or not. That is the one single source of truth of sprint and that is meant for the team.

Any management interference in the sprint burndown is highly discouraged which can result in the bad results from the team and last minute surprises, requires a lot of trust between the management and teams though.

[Andy Johnstone]

I have to say i think this answer is way off base. Part of agile is try to determine how much work (represented many different ways, maybe hours, maybe story points) a team is capabile of achiving in a sprint. If the team doesn't know that, it will either over- or under-commit. Yes you may be off but you're supposed to get better at estimating and determing how much work your team can do over time so that the normal is neither over- or under-committing.

[jcg]

I agree. I don't think we need to break the concept of Scrum to give visiblilty to how many points are assigned to each discipline for the purposes of sprint planning. The estimate and it's reflection on burndowns should stay as is.

However, adding a field for each discipline to add their estimates would make it so our team doesn't have to pull out calculators to figure out how many hours they've accumulated in a planning session.

tl;dr; Keep estimates and burndown as is. Add a new feature to keep track of departmental commitment to each ticket for ease of computing capacity during sprint planning.

[latifnanji]

Umm, I've seen this work extremely effectively before - think it more so depends on the culture. And yes, I stumbled across this because I'm looking for the feature as well :)

[Dan Desjardins]

Not being able to enter team member capacity is, in my opinion, blinding.   I set a capacity of 75% for each team member, that gives each flex time to cover many unknowns (agile does not eliminate the unknowns).  I also need to put vacations, time off, sick time, etc into the capacity.  And yes - even if it isn't scrum; available - spend does indeed equal remaining and it's a key element to delivering anything on time.  Software can figure this out in under a millisecond.  Don't make me use a calculator...

[Zangdaarr Mortpartout]

When we were making sprint planings two years ago, we had at every moment the knowledge of how many un-commited hours we had in our sprint. And we were able to set a capacity for each member. Meaning that we were not stucked with the 40hrs a week official worktime.

Now that I'm using JIRA as a scrum master, I cannot find this feature again and it's actually boring.