Hi,
today I want to discuss some details about the moment we are planning the next Sprint, more precisely at the stage of the Scrum known as Sprint Planning Meeting.
In this post here I've talked about planning for Sprint and tried to answer the question "How many items my team is able to develop?". In it, I talk about the use of the team velocity as a measure to assist with this selection.
In today's post I want to show that this measure is continually changing, and so it is important to be watchful and updating the team's velocity each sprint.
We can notice that by checking the amount of points did it at the end of successive Sprints. That amount is always changing and thus also the speed. The reasons for this change can be many:
- Absence of any team member
- Holidays over the Sprint
- Underestimation / Overestimation of backlog items
- Urgent and unforeseen items entering Sprint
- Others
In the project I work, we use the Planning Poker to estimate the points of backlog items (more info on how to do this here, here and here), but we also take note the amount of time (in hours) each item took to complete. Thus we can take, for example, the items we point with 3 points, check the total hours consumed, then divide by the number of items and we will finally have a relationship of how long, on average, the team leads to finish a 3 points item.
In the following table we can see that there has recently been a change in the amount of hours we took to complete items of 3, 5 and 8 points. The latter two had a subtle change, but the item of 3 points happened to be completed in 75% of the previous time. We should not understand that this reduction in the time necessarily mean that the team has become more efficient, but we must face as a natural change, since the points are based on estimates.
Still analyzing the table, we can talk about points vs hours, which was discussed in this post right here.
Looking at the data in the table we realize that hours do not form a linear function. In other words, it takes 2h to finish the 1 point item, but it does not mean that the 2 point items should takes 4h and so on. It's not quite there, after all we are dealing with uncertainty and our points of estimation are fuzzy (more about fuzzy here).
And you, dear reader, have you been measuring the speed of your team? Doing like this or any other way? Feel invited to share with us some of your experience.
Till the next post!
A velocidade da minha equipe, eu aplico de outra forma.
Quantidade de Issues / nr. Dias da Sprint = Velocidade Ideal
E, diariamente verifico a velocidade do dia anterior, sendo quantidade de issues anterior – quantidade issues resolvidas.
Exemplo:
ISSUES ESTIMADA = 34
DIAS SPRINT = 5
VELOCIDADE IDEAL = 6,8 / dia
—
DIARIAMENTE
ISSUES RESOLVIDOS = 31 (exemplo, dia 1), onde o ideal seria estar com 27
VELOCIDADE ATUAL DO TEAM = 3 / dia
OI Everaldo,
entendi que você utiliza dias úteis. Mas como você trabalha esse acompanhamento diário? Você o usa para substituir o Burndown da Sprint?