Workshop for new agile teams


#1

Hello All,

We are conducting series of workshop for few agile teams who are new to agile adoption. One of the workshop we are conducting is on capacity planning and relative estimation.

However, during the discussion few things came up.

  1. One team member suggested that the estimation especially relative estimation looks good on theory but doesn’t fit their scenario. As per him, they do innovative work for which they have to do research and so it might not be possible for them to estimate either as they have lots of unknowns.

  2. Another suggested that his team is a team of specialist and nothing every body can estimate in the estimate for each of the story. Only folks who have knowledge and skills estimate.

  3. Another was of the view that even if they do capacity planning at the start of the quarter. However because of the volatility of the work they do, their estimate goes for a toss.

Could you please help and advise if anyone has such scenarios ? If yes, what is the best way to address this ?

Appreciate your help.

Regards,


Virtual Working / Distributed Teams: Is WFH the new Normal?
#2

Paging @troy


#3
  1. Estimates aren’t necessary all the time. If it isn’t useful for them, why ask them to do it? However, I would still encourage the team to find small experiments over big ones. Try to deliver smaller and more often.
  2. Is this group a cross functional team? Or a silo? If it is a silo then dependencies will make estimating a futile task.
  3. I would agree and say this is true for any new product development team. Do a search on “No Estimates” to get some viewpoints on this.

For me, the goal of capacity planning should be to figure out what the team focus is. Try to focus on one thing at a time. If possible, have a list in priority order. When a team is done, they can look to the list and take the next thing. If the thing is too big to deliver in a quarter, see if that thing can be broken down into something that can. If you can do this, estimating becomes redundant.


#4

Thank you @Don_Eitel. Great points which has given me some insights.