Team Capacity Estimation

Goal: show and explore how capacity is being estimated in teams

Facilitators: gaba, pili Audience: Development teams at Tor Duration: 1h


Rough Agenda:

  • Go through existing practices, if any, at a team level
    • What works well
    • What could be improved
  • Share individual practices, how do people generally estimate their capacity
  • If not currently estimating capacity, explore how teams can start making estimations
    • Share strategies
  • Capacity planning as part of a wider process, e.g kanban, agile
  • Velocity

Desired Outcome: have a better idea of how to better estimate capacity.


Meeting Notes

It was mainly PMs attending this session so we mainly discussed ideas and strategies.

Capacity Estimation Discussion

  • Network team time
    • How much time on roadmap - 3 days on roadmap
    • rest of the time on other things
  • Metrics did a similar process
  • Capacity:
    • Each day is a point
      • 3 days a week, 12 points a month
      • member points
      • team points
  • Estimation of tasks
    • tasks have a number of points assigned
      • using fibonacci sequence
      • round up or double estimation to think of worst case scenario
      • when task is done they compare estimation with actual
    • Next step is task breakdown and sprint planning instead of 6 months
  • What are we trying to solve?
    • When people can finish things
    • Understand when things are going to be done
  • How do you do it?
    • We need to find the right tooling to do this?
    • How do you deal with the added complexity of calculating points?
  • Could ask people to use clocking software
    • for themselves, not to be shared with the team/org
  • In gitlab you can add a comment /spending - at different granularities

Broader Project Management Discussion

  • What was the experience with Redmine like?
    • Discussions on tickets are hard to follow
    • Integrates with git repos
    • User interface is hard on eyes...
    • Spam
    • What's the value added with redmine over gitlab? Why have both?
      • can relate tickets so you have dependencies between them
  • How do we deal with burnout?
    • Network team got rid of rotating roles
    • people that really want to do something take that on and do it
    • Burnout meeting
      • people can openly talk about it with each other
      • people not concerned with this don't have to attend
      • how does it affect people?
      • how do people cope with it?
  • Triaging needs to be more frequent in some teams
    • automatically marking tickets as stalled and pinging
    • "needs information" vs. "new"
  • Tooling
    • ?
Last modified 15 months ago Last modified on Jul 16, 2019, 10:18:42 AM