Scrum evaluation network for planning
Scrum is a fairly simple methodology. It’s not easy to work on a scram. Similarly with many tools, such as poker for planning. The practice itself is quite understandable, but it is difficult to use it productively for a long time.
In this article I will talk about the technique, which simplifies the process of assessments in the work of team scams.
So what is the difficulty?
As you know, story points are relative estimates of the amount of work in a story. There is no way to rate a single story in story points, you always compare the story with other stories through story points. Poker can work well at the beginning of the project, when teams evaluate a lot of stories in a short period of time.
But later, during the regular reassessment of existing stories and assessments of new stories, it becomes much more difficult, because the calibration of one story point is forgotten: “what is one story point”, “something I’m not sure that this story is really 3 times bigger than ours gold standard "," these two stories of size 5 do not look the same in size, from my point of view. " Familiar problems?
The solution I call the “appraisal grid” is a visual table, one row for each story size you use. If you use the Fibonacci series for ratings, you will have lines for “0.5”, “1”, “2”, “3”, “5” and “8”. Then for each size (on each line) you place several cards with stories, examples in this size. Here is an illustration of how it should look like:
Such a grid in front of your team makes the assessment process much easier, because you have several examples of stories in each size, and you can compare your new story with these examples.
How to fill this grid at the very beginning ..? The general rule is this: add only “typical stories” if there is a chance that you will do something similar in the future.
It is advisable to put stories in the grid after we finish working with them, so that we would have real experience.
The Grade Grid tool aims to help with future grades. Therefore, if a particular story was unique, and it is unlikely that you will do something similar in the future - for such a story there is no place in the grid.
Another trick that removes the difficulties that many team members may have: it’s important to remember what the specific meaning of the assessment means. For example, "5" is how much? Let's remember how we conduct evaluations. If the team believes that the size of the story is greater than "3" and less than "5" - it becomes "5". So “5” means all stories in the range from 3 to 5. If you remember this, it becomes much easier to put two stories that are quite different in size (for example, one is slightly larger than 3 and the other is slightly smaller than 5) in one row as the same. I even show these intervals next to the size in the first column (as you can see in the picture) to visually remind about it. And you revise and improve this network over time. During retrospectives, each iteration, or once in several iterations, you go through the grid to check if all the stories present there are still relevant, and it may be worth adding new stories with which you worked.
It is best if you have 2-5 sample cards in each size. You need some kind of minimum as a basis for evaluations, and you should not have too many examples, because this will only make it difficult and slow down the comparison.
A couple of examples of what this might look like in real life:
')
It makes no sense to put in your grid all possible sizes of stories (like 20, 40 or 100). You need to focus only on the sizes that are relevant for stories that are small enough to enter the iteration. It depends on your choice of size. My recommendation is all up to 8.
This tool is very easy to implement and use. From my experience, he has a very low level of resistance from the teams, that is, he is well received. This is an example of a simple process experiment that you can discuss with your team at the next retrospective and try it without much risk.
If you have questions, ask in the comments - I will be happy to help.
In this article I will talk about the technique, which simplifies the process of assessments in the work of team scams.
So what is the difficulty?
As you know, story points are relative estimates of the amount of work in a story. There is no way to rate a single story in story points, you always compare the story with other stories through story points. Poker can work well at the beginning of the project, when teams evaluate a lot of stories in a short period of time.
But later, during the regular reassessment of existing stories and assessments of new stories, it becomes much more difficult, because the calibration of one story point is forgotten: “what is one story point”, “something I’m not sure that this story is really 3 times bigger than ours gold standard "," these two stories of size 5 do not look the same in size, from my point of view. " Familiar problems?
Proposed Solution
The solution I call the “appraisal grid” is a visual table, one row for each story size you use. If you use the Fibonacci series for ratings, you will have lines for “0.5”, “1”, “2”, “3”, “5” and “8”. Then for each size (on each line) you place several cards with stories, examples in this size. Here is an illustration of how it should look like:
Such a grid in front of your team makes the assessment process much easier, because you have several examples of stories in each size, and you can compare your new story with these examples.
How to fill this grid at the very beginning ..? The general rule is this: add only “typical stories” if there is a chance that you will do something similar in the future.
It is advisable to put stories in the grid after we finish working with them, so that we would have real experience.
The Grade Grid tool aims to help with future grades. Therefore, if a particular story was unique, and it is unlikely that you will do something similar in the future - for such a story there is no place in the grid.
A couple more tips on how to build a network
Another trick that removes the difficulties that many team members may have: it’s important to remember what the specific meaning of the assessment means. For example, "5" is how much? Let's remember how we conduct evaluations. If the team believes that the size of the story is greater than "3" and less than "5" - it becomes "5". So “5” means all stories in the range from 3 to 5. If you remember this, it becomes much easier to put two stories that are quite different in size (for example, one is slightly larger than 3 and the other is slightly smaller than 5) in one row as the same. I even show these intervals next to the size in the first column (as you can see in the picture) to visually remind about it. And you revise and improve this network over time. During retrospectives, each iteration, or once in several iterations, you go through the grid to check if all the stories present there are still relevant, and it may be worth adding new stories with which you worked.
It is best if you have 2-5 sample cards in each size. You need some kind of minimum as a basis for evaluations, and you should not have too many examples, because this will only make it difficult and slow down the comparison.
A couple of examples of what this might look like in real life:
')
It makes no sense to put in your grid all possible sizes of stories (like 20, 40 or 100). You need to focus only on the sizes that are relevant for stories that are small enough to enter the iteration. It depends on your choice of size. My recommendation is all up to 8.
This tool is very easy to implement and use. From my experience, he has a very low level of resistance from the teams, that is, he is well received. This is an example of a simple process experiment that you can discuss with your team at the next retrospective and try it without much risk.
If you have questions, ask in the comments - I will be happy to help.
Source: https://habr.com/ru/post/167983/
All Articles