Contexto

Time de 4 pessoas, 250 horas brutas por mês (total do time) e sprints de duas semanas.

Premissa: as 250 horas são o total do time no mês, ou seja, cerca de 62 horas por pessoa, o que indica dedicação parcial.

Passo a passo

1. Converta as horas do mês para a sprint. Um mês tem cerca de 21 dias úteis e a sprint tem 10, então cada sprint fica com aproximadamente metade das horas mensais: 125 horas brutas. Isso dá cerca de 31 horas por pessoa por sprint, ou pouco mais de 3 horas por dia.
2. Desconte as ausências. Férias, feriados, folgas e treinamentos saem antes de tudo. Cada dia de ausência de uma pessoa tira cerca de 3 horas.
3. Desconte as cerimônias. Elas custam quase o mesmo tempo com dedicação integral ou parcial, por isso pesam muito num time como este. Num formato enxuto, somam cerca de 8 horas por pessoa por sprint.
4. Aplique um fator de foco. Parte das horas restantes vai para e-mails, reuniões externas, dúvidas de outros times e troca de contexto. Com dedicação parcial, o realista é entre 65% e 75%.
5. Divida o que sobra por tipo de trabalho. Reserve fatias fixas para produto, para bugs e débito técnico, e para imprevistos.

Distribuição do time por sprint no SCRUM

Das 125 horas brutas, cerca de 49 horas por sprint vão para novas entregas. Com fator de foco de 65%, esse número cai para cerca de 42 horas.

A mesma conta por pessoa

Essa visão ajuda no planning: cada pessoa tem só cerca de 12 horas por sprint para itens de produto. Uma tarefa de 16 horas não cabe na sprint de ninguém.

Distribuição do time por sprint no IRIS

Das 125 horas brutas, cerca de 52 horas por sprint vão para novas entregas (58h de itens de produto menos ~6h de refinamento), contra cerca de 49 horas no SCRUM. Com fator de foco de 65%, esse número cai para cerca de 45 horas.

A mesma conta por pessoa

Descontado o refinamento, cada pessoa tem cerca de 13 horas por sprint para novas entregas, uma hora a mais que no SCRUM.

Cuidados específicos para o time

Nos dois modelos

• Quebre as tarefas em blocos de 3 a 6 horas, que caibam em um ou dois dias da pessoa. Tarefas grandes num time de dedicação parcial viram itens que atravessam sprints. Com 12 a 13 horas de novas entregas por pessoa, uma tarefa de 16 horas não cabe em nenhum dos modelos.
• Confirme a dedicação no planning. Como as pessoas dividem o tempo com outras atividades, pergunte quantas horas cada uma terá naquela sprint. Essa disponibilidade costuma variar.
• Compare com o que o time já entrega. Se as cerca de 50 melhorias por trimestre forem deste time, isso dá umas 8 por sprint: cerca de 6 horas de produto cada no SCRUM e 6,5 horas no IRIS. Se a conta não bater com a realidade, as estimativas em horas podem estar infladas, ou o fator de foco real é maior que 75%.

No SCRUM SCRUM

• Enxugue as cerimônias. Elas consomem mais de um quarto das horas brutas (32 de 125). Use duração controlada e chame para o refinamento só quem conhece os itens daquela sessão.
• Reforce a reserva se houver suporte. 7 horas somem num único incidente. Se o time atende suporte com frequência, suba a reserva para 15% ou 20%, tirando horas dos itens de produto.

No IRIS IRIS

• Chegue ao planning com o backlog pronto. Com só 0,5h de planning, não sobra tempo para discutir itens. O refinamento, agora tarefa da sprint, precisa deixar prontos os itens da sprint seguinte.
• Estime e priorize o refinamento como qualquer tarefa. Se ele não entra no planejamento, acaba sendo cortado quando a sprint aperta, e o próximo planning fica sem itens prontos.
• Proteja a retrospectiva. Com review e retrospectiva juntas em 0,5h, a melhoria contínua tende a sumir. Reserve ao menos alguns minutos para uma ação concreta de melhoria por sprint.
• Separe o que é bug do que é imprevisto na fatia de 30%. As 25 horas são compartilhadas. Numa sprint com muitos incidentes, os bugs e o débito técnico ficam para depois sem que ninguém perceba. Registre os dois tipos com rótulos diferentes no Jira.

Como acompanhar

Nos dois modelos

• Pontos e horas juntos: use a velocidade em pontos para decidir quanto trabalho entra na sprint, e as horas como checagem de viabilidade.
• Não comprometa 100%: planejar entre 80% e 90% da capacidade calculada evita terminar a sprint com itens pela metade.
• Use o Jira para calibrar: registre a Estimativa Original em horas e o tempo gasto. Depois de três ou quatro sprints, você terá o fator de foco real do time e poderá trocar os 75% por um número próprio.

No SCRUM SCRUM

• Acompanhe o consumo da reserva: se as 7 horas de imprevistos estouram em várias sprints seguidas, aumente o percentual em vez de continuar comprometendo horas que não existem.
• Meça a duração real das cerimônias: se passarem das 8 horas por pessoa, a capacidade de entrega cai na mesma proporção.

No IRIS IRIS

• Meça a fatia de 30% por tipo: acompanhe quantas horas foram para bugs e débito técnico e quantas para imprevistos. Se os bugs ficarem abaixo de 14 horas (a fatia que tinham no SCRUM) por várias sprints, o débito técnico está crescendo.
• Acompanhe o refinamento como tarefa: registre o tempo gasto e confira no planning se os itens chegaram prontos. Planning que passa de 0,5h indica refinamento insuficiente.
• Compare as novas entregas com o SCRUM: o ganho esperado é de cerca de 3 horas por sprint no time. Se as entregas não aumentarem, as horas economizadas nas cerimônias estão indo para outras atividades.

Conclusão

O IRIS libera cerca de 18 horas de cerimônias por sprint, que viram 13 horas produtivas depois do fator de foco. Parte desse ganho volta para o refinamento como tarefa, e o saldo é de cerca de 3 horas a mais de novas entregas por sprint. O ganho maior está na flexibilidade: bugs, débito técnico e imprevistos dividem uma fatia de 25 horas, contra 21 horas separadas no SCRUM. Em troca, o IRIS exige mais disciplina para manter o backlog refinado, preservar a melhoria contínua e não deixar os bugs perderem espaço para os incidentes.

Context

A team of 4 people, 250 gross hours per month (team total) and two-week sprints.

Assumption: the 250 hours are the team’s total for the month, that is, about 62 hours per person, which indicates part-time dedication.

Step by step

1. Convert the monthly hours to the sprint. A month has about 21 working days and the sprint has 10, so each sprint gets roughly half of the monthly hours: 125 gross hours. That is about 31 hours per person per sprint, or just over 3 hours a day.
2. Subtract absences. Vacations, holidays, days off and training come out first. Each day one person is absent removes about 3 hours.
3. Subtract the ceremonies. They take almost the same time whether dedication is full or partial, so they weigh heavily on a team like this one. In a lean format, they add up to about 8 hours per person per sprint.
4. Apply a focus factor. Part of the remaining hours goes to emails, external meetings, questions from other teams and context switching. With part-time dedication, 65% to 75% is realistic.
5. Split what is left by type of work. Reserve fixed shares for product, for bugs and technical debt, and for the unexpected.

Team distribution per sprint in SCRUM

Of the 125 gross hours, about 49 hours per sprint go to new deliveries. With a 65% focus factor, this drops to about 42 hours.

The same calculation per person

This view helps in planning: each person has only about 12 hours per sprint for product items. A 16-hour task does not fit in anyone’s sprint.

Team distribution per sprint in IRIS

Of the 125 gross hours, about 52 hours per sprint go to new deliveries (58h of product items minus ~6h of refinement), against about 49 hours in SCRUM. With a 65% focus factor, this drops to about 45 hours.

The same calculation per person

Once refinement is subtracted, each person has about 13 hours per sprint for new deliveries, one hour more than in SCRUM.

Specific precautions for the team

In both models

• Break tasks into blocks of 3 to 6 hours that fit in one or two of the person’s days. Large tasks in a part-time team become items that span sprints. With 12 to 13 hours of new deliveries per person, a 16-hour task fits in neither model.
• Confirm dedication at planning. Since people split their time with other activities, ask how many hours each one will have in that sprint. This availability tends to vary.
• Compare with what the team already delivers. If the roughly 50 improvements per quarter belong to this team, that is about 8 per sprint: about 6 product hours each in SCRUM and 6.5 hours in IRIS. If the numbers don’t match reality, the hour estimates may be inflated, or the real focus factor is higher than 75%.

In SCRUM SCRUM

• Trim the ceremonies. They take more than a quarter of the gross hours (32 of 125). Timebox them and invite to refinement only those who know the items in that session.
• Increase the buffer if there is support work. 7 hours vanish in a single incident. If the team handles support often, raise the buffer to 15% or 20%, taking hours from product items.

In IRIS IRIS

• Come to planning with the backlog ready. With only 0.5h of planning, there is no time left to discuss items. Refinement, now a sprint task, must get the next sprint’s items ready.
• Estimate and prioritize refinement like any other task. If it isn’t planned, it ends up cut when the sprint gets tight, and the next planning has no ready items.
• Protect the retrospective. With review and retrospective together in 0.5h, continuous improvement tends to disappear. Save at least a few minutes for one concrete improvement action per sprint.
• Separate bugs from the unexpected in the 30% slice. The 25 hours are shared. In a sprint with many incidents, bugs and technical debt get pushed back without anyone noticing. Log the two types with different labels in Jira.

How to track

In both models

• Points and hours together: use velocity in points to decide how much work goes into the sprint, and hours as a feasibility check.
• Don’t commit 100%: planning between 80% and 90% of the calculated capacity avoids ending the sprint with half-done items.
• Use Jira to calibrate: log the Original Estimate in hours and the time spent. After three or four sprints, you will have the team’s real focus factor and can replace the 75% with a number of your own.

In SCRUM SCRUM

• Track buffer usage: if the 7 hours for the unexpected overflow in several sprints in a row, raise the percentage instead of continuing to commit hours that don’t exist.
• Measure the real length of the ceremonies: if they exceed 8 hours per person, delivery capacity drops by the same proportion.

In IRIS IRIS

• Measure the 30% slice by type: track how many hours went to bugs and technical debt and how many to the unexpected. If bugs stay below 14 hours (the share they had in SCRUM) for several sprints, technical debt is growing.
• Track refinement as a task: log the time spent and check at planning whether the items arrived ready. Planning that runs over 0.5h indicates insufficient refinement.
• Compare new deliveries with SCRUM: the expected gain is about 3 hours per sprint for the team. If deliveries don’t increase, the hours saved on ceremonies are going to other activities.

Conclusion

IRIS frees about 18 hours of ceremonies per sprint, which become 13 productive hours after the focus factor. Part of that gain goes back into refinement as a task, and the net result is about 3 more hours of new deliveries per sprint. The bigger gain is flexibility: bugs, technical debt and the unexpected share a 25-hour slice, against 21 separate hours in SCRUM. In exchange, IRIS demands more discipline to keep the backlog refined, preserve continuous improvement and keep bugs from losing ground to incidents.

Contesto

Team di 4 persone, 250 ore lorde al mese (totale del team) e sprint di due settimane.

Premessa: le 250 ore sono il totale del team nel mese, cioè circa 62 ore a persona, il che indica una dedizione parziale.

Passo dopo passo

1. Converti le ore del mese in ore dello sprint. Un mese ha circa 21 giorni lavorativi e lo sprint ne ha 10, quindi ogni sprint riceve circa la metà delle ore mensili: 125 ore lorde. Sono circa 31 ore a persona per sprint, ovvero poco più di 3 ore al giorno.
2. Sottrai le assenze. Ferie, festività, permessi e formazione si tolgono prima di tutto. Ogni giorno di assenza di una persona toglie circa 3 ore.
3. Sottrai le cerimonie. Costano quasi lo stesso tempo con dedizione piena o parziale, per questo pesano molto in un team come questo. In un formato snello, sommano circa 8 ore a persona per sprint.
4. Applica un fattore di focus. Parte delle ore restanti va in e-mail, riunioni esterne, domande di altri team e cambi di contesto. Con dedizione parziale, il valore realistico è tra il 65% e il 75%.
5. Dividi ciò che resta per tipo di lavoro. Riserva quote fisse per il prodotto, per bug e debito tecnico, e per gli imprevisti.

Distribuzione del team per sprint in SCRUM

Delle 125 ore lorde, circa 49 ore per sprint vanno a nuove consegne. Con un fattore di focus del 65%, questo numero scende a circa 42 ore.

Lo stesso calcolo a persona

Questa visione aiuta nel planning: ogni persona ha solo circa 12 ore per sprint per gli elementi di prodotto. Un’attività da 16 ore non entra nello sprint di nessuno.

Distribuzione del team per sprint in IRIS

Delle 125 ore lorde, circa 52 ore per sprint vanno a nuove consegne (58h di elementi di prodotto meno ~6h di refinement), contro circa 49 ore in SCRUM. Con un fattore di focus del 65%, questo numero scende a circa 45 ore.

Lo stesso calcolo a persona

Tolto il refinement, ogni persona ha circa 13 ore per sprint per nuove consegne, un’ora in più rispetto a SCRUM.

Accorgimenti specifici per il team

In entrambi i modelli

• Suddividi le attività in blocchi da 3 a 6 ore, che stiano in uno o due giorni della persona. Le attività grandi in un team a dedizione parziale diventano elementi che attraversano più sprint. Con 12–13 ore di nuove consegne a persona, un’attività da 16 ore non entra in nessuno dei due modelli.
• Conferma la dedizione nel planning. Poiché le persone dividono il tempo con altre attività, chiedi quante ore avrà ciascuna in quello sprint. Questa disponibilità tende a variare.
• Confronta con ciò che il team già consegna. Se i circa 50 miglioramenti per trimestre sono di questo team, sono circa 8 per sprint: circa 6 ore di prodotto ciascuno in SCRUM e 6,5 ore in IRIS. Se i conti non tornano con la realtà, le stime in ore potrebbero essere gonfiate, oppure il fattore di focus reale è superiore al 75%.

In SCRUM SCRUM

• Snellisci le cerimonie. Consumano più di un quarto delle ore lorde (32 su 125). Usa una durata fissa e invita al refinement solo chi conosce gli elementi di quella sessione.
• Rafforza la riserva se c’è supporto. 7 ore spariscono in un solo incidente. Se il team fa supporto spesso, porta la riserva al 15% o al 20%, togliendo ore agli elementi di prodotto.

In IRIS IRIS

• Arriva al planning con il backlog pronto. Con solo 0,5h di planning, non resta tempo per discutere gli elementi. Il refinement, ora attività dello sprint, deve preparare gli elementi dello sprint successivo.
• Stima e prioritizza il refinement come qualsiasi attività. Se non entra nella pianificazione, finisce per essere tagliato quando lo sprint si fa stretto, e il planning successivo resta senza elementi pronti.
• Proteggi la retrospettiva. Con review e retrospettiva insieme in 0,5h, il miglioramento continuo tende a sparire. Riserva almeno qualche minuto per un’azione concreta di miglioramento per sprint.
• Separa i bug dagli imprevisti nella quota del 30%. Le 25 ore sono condivise. In uno sprint con molti incidenti, bug e debito tecnico vengono rimandati senza che nessuno se ne accorga. Registra i due tipi con etichette diverse su Jira.

Come monitorare

In entrambi i modelli

• Punti e ore insieme: usa la velocity in punti per decidere quanto lavoro entra nello sprint, e le ore come verifica di fattibilità.
• Non impegnare il 100%: pianificare tra l’80% e il 90% della capacità calcolata evita di chiudere lo sprint con elementi a metà.
• Usa Jira per calibrare: registra la Stima Originale in ore e il tempo impiegato. Dopo tre o quattro sprint, avrai il fattore di focus reale del team e potrai sostituire il 75% con un numero tuo.

In SCRUM SCRUM

• Monitora il consumo della riserva: se le 7 ore per imprevisti sforano in più sprint di fila, aumenta la percentuale invece di continuare a impegnare ore che non esistono.
• Misura la durata reale delle cerimonie: se superano le 8 ore a persona, la capacità di consegna cala nella stessa proporzione.

In IRIS IRIS

• Misura la quota del 30% per tipo: monitora quante ore sono andate a bug e debito tecnico e quante agli imprevisti. Se i bug restano sotto le 14 ore (la quota che avevano in SCRUM) per più sprint, il debito tecnico sta crescendo.
• Monitora il refinement come attività: registra il tempo impiegato e verifica nel planning se gli elementi sono arrivati pronti. Un planning che supera 0,5h indica un refinement insufficiente.
• Confronta le nuove consegne con SCRUM: il guadagno atteso è di circa 3 ore per sprint nel team. Se le consegne non aumentano, le ore risparmiate sulle cerimonie stanno andando ad altre attività.

Conclusione

IRIS libera circa 18 ore di cerimonie per sprint, che diventano 13 ore produttive dopo il fattore di focus. Parte di questo guadagno torna al refinement come attività, e il saldo è di circa 3 ore in più di nuove consegne per sprint. Il guadagno maggiore sta nella flessibilità: bug, debito tecnico e imprevisti condividono una quota di 25 ore, contro 21 ore separate in SCRUM. In cambio, IRIS richiede più disciplina per mantenere il backlog raffinato, preservare il miglioramento continuo e non lasciare che i bug perdano spazio a favore degli incidenti.