It would be nice if a team had the following extensions beyond a simple edit box numeric value for capacitiy per user. As an example some of our teams state the base capacity of every team member (assuming a 2 week sprint) is 10 days * 6 hours a day. The 6 hours rather than 8 is to account for emails, minor interrupts like unplanned meetings etc. Then they reduce capacity based on company mandated holidays (we are global so ever office is different), then they reduce hours for the sprint meetings. this becomes the max anyone on a team can contribute to a sprint. The team members may additionally subtract off vacation time, or other meetings they are required to attend, trainings, etc. it would be nice if a team can define a default formula based on known factors, and team memebrs have an additional ability to have thier own formula that can further adjust thier own availabilites beyond that, or even just override it with a typed in value. The benefit would be that perhaps less time is required to populate capacity for the team prior to each sprint planning session, and they can inspect and adapt the base formulas over time.

Comments

  • This is great and I remember going through this myself. I had excel spreadsheets in the back of my sprint backlog where I could enter holiday and other data to get this value.

    What we found over time was that it became somewhat unnecessary as your velocity and team matures. We slowly transitioned to story points and relying on them to do sprint planning. We picked our stories and blew out the tasks for them only when the story was picked up (mid-sprint we swarmed on open stories and closed them every day instead of running them all in parallel). We did just in time task planning and estimation (more efficient).

    This led to us no longer needing all those calculations. Holidays and vacations were a simple head calculation (example: typically we do 20pts per 10 day sprint with 10 people = ~.2pts/person/day, we have 5 people taking 1 day of vacation = ~1pt... so plan 19 pts this sprint.)

    It's an interesting feature request, but I'm guessing every customer will have a slightly unique view on the calculation... and I'm guessing most people will outgrow this need over 6 months to 1 year.

  • I agree that this could be better - especially when trying to educate new clients and teams as to how to plan their iterations. Additionally, sometimes there is a need to look at capacity and resource planning across projects from a "agile program" perspective, so some more granular metrics on allocation and and availability would be useful.

  • The problem lies when you are trying to use Agile, but someone 'up there' is trying to drive you to a date. In that case, Capacity matters, because you have a fixed amount of work to do, and a fixed amount of time to do it, and you need to know if the people you have are enough to get it done.

    Yes, it is true to say that this means that they are not doing Agile correctly. Yep, that is our reality. Organizations that are transitioning sometimes fail to transition completely, and that is something we have to deal with, sometimes.

    V1 is a tool. We have a need. We would like the tool to fulfill our need, even if our need is caused by doing things the wrong way. All I ask is that implementing a solution to our broken process doesn't force a bad process on everybody else, too... :)

  • Kevin, the reality is that not all teams remaining together from sprint-to-sprint, so story point velocity meansures are not always very useful.

    I end up having to manually create a report each sprint to get an idea of where reality sits... so, in addition to a default formula, I'd like the ability for each team member to update their capacity via a calendar type schedule. For example, the person may normally have 60 hours (10d x 6hrs) per sprint, but might be out for three days at the end of the sprint so only has 42 hours. However, I'd like to accurately reflect that in my "ideal line" on the burndown chart so i know if we have really have capacity remaining -- rather than averaging the hours evenly over the sprint and pretending the person is working 4.2 hours per day, I'd like to know that he's really at 6hr/day for 7 days and 0hr/day for the last 3 days, and our "ideal line" should drop faster at the end of the sprint.

  • I agree that this would be a valuable feature. I have used other tools that allow me to specify a set amount of hours per day for each team member. I usually use the 6 hour per day rule, which helps me understand if the team is well balanced, over committed or under committed with their task hours for the sprint. Additionally, it's great to be able to discount vacation or holidays, which helps us to remember those dependencies and realistically plan our time. This type of view is never meant to be used to enforce a certain level of productivity or scold a team member for not taking enough work, but rather to create a valuable picture that helps teams understand their commitment and collaboration at a level of granularity appropriate for a sprint. Updating this feature to be more efficient by, say, allowing me to carry a standard amount of capacity forward to future sprints and then edit as needed would make sprint planning move more quickly.

  • This would be great. I am having to do this manually right now.

  • This IS a good idea but I suspect that you would not be able to actually do this until you fix member capacity. Capacity only works for iteration-based (read:scrum) teams at this point and there is no way to input capacity for kanban or non-iteration-based members. I'm voting it up but there is a larger issue at hand here that needs correction.

    I'd propose that there be meta-data on each member that allows true capacity per member, this would likely be needed to be further subdivided by portfolio item or planning level, or other divisions that members might work across.