Planning poker: notes about the first developer experience
I, like some other programmers, am not a big fan of rallies. Sometimes, all these sprint refinement, sprint review, retrospective sessions get bored.
In the teams where I worked, there was never planning poker rallies, but recently participated in this, though someone else's team. I know everyone from this team (with the exception of the new architect), but I never personally saw the full team in action, so I watched with interest their teamwork approaches. Besides the fact that it was quite fun, I was able to learn something new and useful for myself. In this article I want to share my impressions of participating in a planning poker rally.
I didn’t even know that some of our teams are practicing Planning Poker. The fact is that in our projects there are team members from two offices: the Dutch front office and the Russian back office. Using Planning Poker for sprint content in our environment is simply unrealistic. For such sessions, you need to assemble the whole team in one place and it is difficult to organize it on a regular basis. Therefore, the team holds such sessions only for back-up tasks for several years, some of which seem insane and unrealistic to implement, and tasks that require more time than managers are ready to give at the current time. For these purposes, Planning poker is just perfect, in my opinion. If you have experience using Planning poker for distributed teams without collecting the whole team in one room, it will be interesting to read, write in the comments.
In the team in question, software is being developed for software for medical equipment, as well as software for the corresponding hardware — firmware. Therefore, such sessions will be informative for most of the team members, since someone works with only one part and does not know the details and difficulties encountered in other parts of the software. During the rally, many discussions between people with the lowest and highest scores began: “It's easy to do.” Yes, sometimes a low grade is made by experienced programmers, and in some cases a low score is given by inexperience, because this is a <sarcasm> firmware for a regular piece of hardware, and why it takes so long </ sarcasm> there .
')
Most of the tasks contained at least 3 parts, based on the specifics of the project: software, firmware, and the tests themselves. For complex systems from the group of constituent elements, an assessment was made for one element.
In assessing the complexity of the task, additional questions from beginners are very helpful. As you understood, for this sacred mission they invited me. The fact is that an unknowing person can ask questions that will also be useful in taking into account the ratings of team members. I myself noticed a couple of times how after my question, some people immediately began to look for another card, although they had already decided on the assessment.
Such sessions require large time costs. The time for discussion of each question depends on the completeness of the requirements and understanding of the solution to the problem. Time to discuss the issue can vary from 5 to 30 minutes. So I took part to discuss the last third of the backlog of tasks. It took an hour and a half.
So let's summarize.
Everything is good in moderation. Planning poker sessions are a useful activity, but they take a lot of time, so I don’t find it wise to spend them very often, unless you have free time. By gathering such meetings from time to time, you will maintain general awareness in the team for different parts of the project, which will help improve the process of solving problems. And for some, it may be a good opportunity to get to know other parts of the project in case you get bored with working with your own.
In the teams where I worked, there was never planning poker rallies, but recently participated in this, though someone else's team. I know everyone from this team (with the exception of the new architect), but I never personally saw the full team in action, so I watched with interest their teamwork approaches. Besides the fact that it was quite fun, I was able to learn something new and useful for myself. In this article I want to share my impressions of participating in a planning poker rally.
Frequency of Planning Poker rallies
I didn’t even know that some of our teams are practicing Planning Poker. The fact is that in our projects there are team members from two offices: the Dutch front office and the Russian back office. Using Planning Poker for sprint content in our environment is simply unrealistic. For such sessions, you need to assemble the whole team in one place and it is difficult to organize it on a regular basis. Therefore, the team holds such sessions only for back-up tasks for several years, some of which seem insane and unrealistic to implement, and tasks that require more time than managers are ready to give at the current time. For these purposes, Planning poker is just perfect, in my opinion. If you have experience using Planning poker for distributed teams without collecting the whole team in one room, it will be interesting to read, write in the comments.
For which teams would it be useful to use Planning Poker
In the team in question, software is being developed for software for medical equipment, as well as software for the corresponding hardware — firmware. Therefore, such sessions will be informative for most of the team members, since someone works with only one part and does not know the details and difficulties encountered in other parts of the software. During the rally, many discussions between people with the lowest and highest scores began: “It's easy to do.” Yes, sometimes a low grade is made by experienced programmers, and in some cases a low score is given by inexperience, because this is a <sarcasm> firmware for a regular piece of hardware, and why it takes so long </ sarcasm> there .
')
Large tasks are split and evaluated separately.
Most of the tasks contained at least 3 parts, based on the specifics of the project: software, firmware, and the tests themselves. For complex systems from the group of constituent elements, an assessment was made for one element.
You can invite someone from another project to participate.
In assessing the complexity of the task, additional questions from beginners are very helpful. As you understood, for this sacred mission they invited me. The fact is that an unknowing person can ask questions that will also be useful in taking into account the ratings of team members. I myself noticed a couple of times how after my question, some people immediately began to look for another card, although they had already decided on the assessment.
Required time for planning poker sessions
Such sessions require large time costs. The time for discussion of each question depends on the completeness of the requirements and understanding of the solution to the problem. Time to discuss the issue can vary from 5 to 30 minutes. So I took part to discuss the last third of the backlog of tasks. It took an hour and a half.
So let's summarize.
Everything is good in moderation. Planning poker sessions are a useful activity, but they take a lot of time, so I don’t find it wise to spend them very often, unless you have free time. By gathering such meetings from time to time, you will maintain general awareness in the team for different parts of the project, which will help improve the process of solving problems. And for some, it may be a good opportunity to get to know other parts of the project in case you get bored with working with your own.
Source: https://habr.com/ru/post/442336/
All Articles