Olá Erick,
de fato existem vários fatores que dizem quantas histórias cabem dentro de uma iteração.
O primeiro deles é justamente a duração da sua iteração, se ela é de 1 semana, 2 semanas ou até 1 mês. Quanto maior o tempo, mais histórias podem ser pegas pelo time.
Um segundo fator é justamente o projeto em si. Muitas vezes, no começo projetos surgem histórias maiores por questões de acerto de ambiente, configuração, etc. Isso leva a quantidade de histórias dentro da iteração ser pequena. Conforme o projeto fica mais maduro, aparecem mais histórias de manutenção do sistema que, se você seguiu o 9° e o 10° princípio do manifesto de construir projetos com qualidade técnica e sempre buscando a arte da simplicidade, tendem a ser pequenas e caber mais dentro da iteração.
Prioridade do cliente afeta mais na ordem com a qual as histórias serão feitas. Mas se o seu cliente só prioriza as maiores tarefas, isso de fato pode afetar quantas histórias cabem dentro da iteração. Isso pode ser resolvido também na negociação das sprintes entre o cliente e os desenvolvedores. Por exemplo, se os devs já pegaram x histórias com o cliente e a x+1 é muito grande para a duração da sua sprint, talvez seja necessário quebrá-la em histórias menores ou pegar outra história menos prioritárias que a x+1 e que caiba na sua sprint.
Além disso, fatores como capacidade técnica do time, número de desenvolvedores, complexidade do fluxo das histórias/critério de pronto, entre outros fatores que foram comentados no curso também podem afetar nesta métrica.
Um bom jeito de saber se o seu time pega uma quantidade de histórias adequada para o seu contexto é usar métricas como burn down por sprint e/ou velocity das iterações do projeto.