Estimate scrum planning process. To determine which stories a team will be able to accomplish in a sprint, you need to know how much work each story will require.
Scrum uses a group tool called poker planning to estimate the amount of work.
To do this, you don’t need a poker deck, as you might think, but cards with numbers and a few extra icons. Each team member gets a full set of cards.
The topmost story is then taken from the backlog. The product owner explains the requirements, if necessary. Each team member independently estimates how much time this work might take and prepares a card with the appropriate man-days figure. When everyone is ready, each of them shows the prepared scorecard at the signal of the scrum master. From the first time, the scores are usually different. The scrum master gives the floor in turn to the one who gave the lowest score and the one who gave the highest. Each one must explain why he or she evaluated the work this way. A discussion ensues in which the entire team takes part. After all the arguments for and against the extreme scores have been made, the “vote” is repeated. The second time, the extremes usually become closer to the mean, and some participants’ scores begin to coincide. An experienced team usually needs 1-3 such iterations, so that all come to the same assessment. Only after that does the team move on to assess the next story. It is not allowed to decide if the scores do not match. If even one team member has a different opinion from the others, he or she must either convince the others that he or she is right or agree with their assessment.
The planning process stops as soon as the total score of the stories planned in the sprint reaches the speed (productivity) of the team. The performance of a team is the total number of story points it realizes in a sprint.
The product owner is present but does not take part in the direct evaluation. However, when he sees that his own or the customer’s expectations diverge greatly from the team’s estimates, he can reformulate the story, shorten it, simplify it, or suggest a different implementation approach. Estimating is labor and therefore money. He is responsible for the budget, so he knows whether the customer is willing to pay that price for the story. In certain cases, if it turns out the story costs too much, he may even reconsider prioritizing it, because in that case the business value is reduced.
A scheduling tool that allows you to make a command evaluation of backlog items.
-Everyone gives an estimate without seeing the others
-All amount of work is evaluated (including design, testing, etc.)
-Discussion, Breakdown, Refinement
Each team member holds the following set of cards:
0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 – these are the marks for scores. Zero means “nothing to do here at all,” it can be done as you go along, and write a few lines of code. 1/2 is anything that takes less than a day. For the rest of the estimates, the closest larger number is used. The first numbers represent the Fibonacci sequence, where each successive number is the sum of the previous two. As the estimates increase, the gap increases. This reflects the fact that as the difficulty of the problem increases, the accuracy of the estimate decreases, and the error increases. A 1-day task can be estimated with an accuracy of 1 day. However, for a large and complex task that is not broken down into parts, it is difficult to argue that it will take exactly 31 or 32 days.
Therefore, there are no cards with such numbers. In this case, the 40 card just comes up. And the difference between your feeling of 30 and 40 is the margin of error of what you didn’t take into account when making an “at a glance” estimate. Strictly speaking, the numbers on the cards do not reflect man-days, but so-called SP= story points. They are supposed to show the relative labor intensity of stories about each other. However, to make estimates in abstract units you need to gain some experience. This experience will tell you that such stories are 1 SP, and such stories are 5 SP. In practice, those who learn scrum are more accustomed to taking for 1 point of history 1 conditional man-day.
Infinity sign – means that there is too much work to be evaluated or even done in one sprint. In this case, the story becomes an epic and is broken down into smaller stories. Or the story can be broken down into tasks.
The question mark means “I have no idea.” This icon can be used when the story is unclear (though it’s better to find out before voting) or when one is complete “out of the loop”.
Some teams also use the coffee cup sign, which means: “My head isn’t thinking straight anymore. Let’s take a break.”
Such cards can be drawn on paper or printed on a printer in 5 minutes. If a scrum is already a permanent fixture in your life, you can order ready-made sets of these cards, which are sold in online stores. Another way is to use special mobile applications that allow you to show the team an image of the map on the screen of your gadget instead of a physical map.
It would seem that one could use the usual approach of having the most competent or even a dedicated person, for example, an analyst, evaluate all the stories. However, we should not forget that when a team makes an assessment, it is committing to its implementation. When one person does the evaluation and another person implements it, there is no such responsibility. You can always say, “I didn’t do that assessment and it’s impossible to get into it. It is wrong. Let whoever did it do it and implement it.” But if you participated in the evaluation process and agreed with it, that means you accepted responsibility.
You may rightly point out that not all team members may have sufficient competence in evaluation. They may have varying degrees of experience and may not even be experts on the topic at all. That’s true. That’s why cross-functional teams are best suited for a scrum.
However, let me tell you a story when we had a dedicated tester on our team who had no idea about programming. He certainly had a hard time giving even rough estimates. He simply had no basis for evaluations. What does a person do in a situation where he can’t have an opinion of his own? The first card he raised was with a question mark. But then, as he listened to the discussion of the others, he began to lean toward one or the other assessment. Both the authority on the issue of this or that team member and the persuasiveness of the statements played a role here. In essence, he did not vote for the evaluation, but the influence of the team members, accepting their position. In this way, he was still contributing to the team’s evaluation.
The length of time a story takes to complete often depends on who is doing the implementation.
Ideally, scrum involves highly skilled teams. But in real life, teams are made up of people with varying degrees of experience. What would take a novice 3 days, a highly skilled person can do in a day. The productivity may differ by an order of magnitude. In this situation, it helps that the distribution of stories to performers is also done during planning. When estimating, you need to consider who exactly will be doing the story. The estimate for a story to be done by an inexperienced technician can be increased. The estimate of the same story for a master is usually made more optimistic
