How do you adapt Scrum to different contexts and domains?

Adapter Scrum à des contextes et domaines divers nécessite une approche réfléchie qui reconna?t les besoins spécifiques de chaque industrie. Que ce soit dans le domaine de la santé, des finances ou du marketing, il est primordial d'embrasser le cadre empirique de Scrum. La terminologie peut être adaptée pour correspondre au langage propre à chaque domaine, et les objectifs de sprint peuvent être ajustés pour répondre aux objectifs spécifiques de l'industrie. La nature adaptable de Scrum permet une flexibilité au niveau des r?les, des événements et des artefacts, s'adaptant ainsi aux différentes cultures organisationnelles et aux flux de travail spécifiques.

Velocity, based on the user stories completed and accepted in previous Sprints, helps estimate effort for future Sprints. It varies due to factors like team composition, availability, skills, dependencies and the complexity of PBIs.

That's not really Velocity. Velocity is an average of the amount of Effort that has been completed in previous Sprints. It can be used to predict the amount of Effort that can be completed in the coming Sprint. When using Velocity for prediction though it is best to consider it as a starting point for a discussion, a loose guideline at most. No metric can ever replace the empirical knowledge of the team. It is also unique to each team. You cannot compare the velocity between teams.

It is extremely important to convey that "Scrum Team Velocity" is by no means a static but a dynamic value. In the corporate environment, it must be seen as a cautious approach and not as a deadline commitment! This discrepancy is a common (completely unnecessary) point of conflict in organizations and communication between Scrum teams and stakeholders.

Velocity in Scrum is a measure of the amount of work a team completes in a sprint, typically expressed in story points. It's a key metric for planning and tracking progress. To calculate velocity, you add up the total story points of all completed user stories in a sprint. For instance, if your team completes stories worth 20, 25, and 30 points in three sprints, your average velocity is 25 story points per sprint.

During product backlog refinement session, assigning story points is a team activity facilitated by the Scrum Master and involving active participation from the Development Team and Product Owner. Sprint velocity in Scrum is calculated based on the amount of work that is both completed and accepted according to the team's definition of done by the end of the sprint. for e.g. if team identified 3 user stories having points as 5,10,3 for the current sprint and those are completed and accepted, then the velocity for the sprint is 5+10+3 = 18 story points.

There's a definition issue here. As noted above, Velocity is an average over several Sprints. To have a useful number for prediction purposes, you need to calculate over more than one Sprint. To work it out, yes, count the completed Effort in each Sprint, then take the average. So if your team completes 20, 10, and 30 story points in each of the last three Sprints, then the Velocity is 20 (because (20+10+30)/3=20 )

A adapta??o do Scrum a diferentes contextos é fundamental para maximizar a eficácia das equipes. No meu trabalho, encontramos que a melhor forma de calcular a velocidade era utilizando a sequência de Fibonacci de 1 a 13. Nesse modelo, atribuímos 1 a histórias de baixa complexidade, com total entendimento do que precisa ser feito, e 13 a aquelas de alta complexidade, com menos de 25% de entendimento. Essa abordagem n?o apenas evita a rigidez das estimativas em horas, mas também nos permite mensurar a capacidade da equipe de maneira mais precisa. Isso gera um entendimento mais claro do progresso e ajuda a identificar onde est?o as incertezas e os riscos, facilitando a adapta??o contínua do nosso processo

Please use a Monte Carlo simmulation! Please use a Monte Carlo simmulation! Please use a Monte Carlo simmulation! Please use a Monte Carlo simmulation!

I think Team's Capacity is vital for Iteration planning. The factors which can be considered for Capacity calculations are Team's availability excluding non development hours, leaves, holidays

Velocity is based on historical performance, so if your team has completed more than three sprints, you can calculate the team's velocity by averaging the total number of story points completed over the last three sprints. For example, if the team has completed 5, 7, and 9 story points in the last three sprints, you would use the average of these—7 story points—as the velocity for planning the next sprint. This average serves as a useful benchmark. However, it's important to also take into account factors such as team capacity, the complexity of stories, and a buffer for unplanned work.

I'm not sure how you would adjust your velocity regularly. It's a number based on a formula, you can recalculate it but that's about all. The only way to adjust the number is to increase (or decrease) the amount of Effort completed. When using Velocity for prediction be very careful. It can only be used in the context that the work was completed. Unless you have that context, the Velocity is a meaningless number. For instance, if it works out as 25 over the last 4 Sprints, but the team had 2 extra people, then the number means nothing. It's also worth noting that not all Story Points are equal. i.e. two User Stories with a 5 Effort are rarely the same size.

Using velocity for planning involves forecasting how much work the team can handle in upcoming sprints. This helps set realistic goals and manage stakeholder expectations. If your team’s average velocity is 25 points and you have a backlog of 100 points, you can estimate it will take four sprints to complete the work

... it would be to good to use Big Data an AI for this, I know, but I can dream. (And will continue to do so!) You need buffer time! Every time! Country-specific seasonal holidays, birthdays, current waves of illness, major events, vacations and so on ... All of this should be taken into account in sprint planning in order to make a reasonably realistic estimate.

Don't try and improve velocity. Chances are all you'll end up doing is pushing the team to work harder and adopt an unsustainable pace of work. Burn out, turnover, etc. may be the outcome. Instead, work on forming the team into a true team. One that performs and functions well. There are not many true teams around, most are psuedo-teams. Concentrate on how the team functions, make improvements to help them, and velocity will take care of itself.

Velocity is a completely passive, indirect value. It cannot be directly influenced in any way. Things that can be improved and thus gradually increase velocity: team collaboration, both among themselves and with each other (i.e. with all dependent departments in the company and stakeholders), clearer communication and collegial mutual support throughout the company.

Its about enhancing team efficiency and effectiveness ... and this can be achieved through regular retrospectives where the team identifies bottlenecks and areas for improvement. For exmple, if the team finds that interruptions during sprints are slowing them down, they might implement a strategy to minimize these disruptions

Velocity is measured based on story points, and creating user stories that meet the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, and Testable) help to improve velocity. Well-defined user stories lead to clearer scope and more predictable completion rates. Additionally, conducting regular retrospectives is crucial. They help the team identify and address impediments or issues that might be affecting performance. By continuously reflecting on and improving processes, the team can enhance its efficiency and, consequently, its velocity.

I couldn’t agree more about comparing team’s velocity. All teams velocity, in itself, should only be compared to it’s own velocity. Even that comparison can be skewed over time. Personnel, scope, leadership, stakeholders and project direction are just a few factors that can weigh heavily on the metrics.

You don't need to adapt velocity to different contexts/ domains. It's a number, that's all. Each team has that number, and it is unique to that team. No other team's Velocity can be considered. You don't need to adapt Velocity, simply understand it's an internal indicator for a team. It's a loose guide that lets them know how much Effort they can complete in a Sprint, given the conditions of the previous Sprints.

Velocity is observed over multiple sprints to provide a more stable benchmark for planning future sprints. It varies between teams due to differences in skill sets, experience levels and the complexity of Product Backlog Items (PBIs). This variability is why each team’s velocity is unique and not directly comparable to others.