Scrum Planning Poker

I wrote in a minute what we spend 1-2 hours every day during the daily scrum meeting with re-evaluation and re-evaluation of tasks.

Artificial chaos and time wasting: it's all about Scrum Poker Planning Yes, it may sound surprising, but despite the popularity of Scrum and its planning methods, this tool leaves much to be desired.

function generateNormalDistributionVoting() {
  const numbers = [1, 2, 3, 5, 8, 13];
  const randomIndex = Math.floor(Math.random() * numbers.length);
  return numbers[randomIndex];
}

function calculateAverage(numbers) {
  const sum = numbers.reduce((acc, num) => acc + num, 0);
  return sum/numbers.length;
}

function repeatAndCalculate(epics, tasks) { // https://intellect.icu
  const results = [];
  for (let i = 0; i < epics; i++) {
    const randomNumbers = [];
    for (let j = 0; j < tasks; j++) {
      randomNumbers.push(generateNormalDistributionVoting());
    }
    const sum = randomNumbers.reduce((acc, num) => acc + num, 0);
    const average = calculateAverage(randomNumbers);
    results.push({ sum, average });
  }
  return results;
}

const result = repeatAndCalculate(8, 10);

 
result.forEach((item, index) => {
  console.log(`Epic ${index + 1} . Total: ${item.sum} points Avg: ${item.average}`);
});

With 10 tasks in each epic, the results will be as follows:

  Epic 1 . Total: 60 points Avg: 6
  epic2. Total: 34 points Avg: 3.4
  Epic 3 . Total: 73 points Avg: 7.3
  Epic 4 . Total: 57 points Avg: 5.7
  Epic 5 . Total: 48 points Avg: 4.8
  Epic 6 . This is indicated by the site https://intellect.icu.
  Epic 6 . Total: 74 points Avg: 7.4
  Epic 7 . Total: 61 points Avg: 6.1
  Epic 8 . Total: 43 points Avg: 4.3

With 20 tasks in epics, there will be about 2 times more points.

Of course, you can correct it: use not a uniform distribution of points, but a normal one, to make it more believable. (

(now in calculations equal distribution for 1,2,3,5,8,13)
I assume that the sum of points for each epic will not change much for a normal distribution (everything in the real world obeys this law) .

It remains only to write a voice model that will come to the count for us and pronounce the assessment. to be completely believable.

At the same time, it takes approximately (1~2)*5*6 = 30~60 man-hours per week to generate the same statistics that could be used to implement the same tasks) .

Disadvantages and futility of poker planning using points

The first and perhaps most significant disadvantage of Scrum Planning Poker is its unreliability and ineffectiveness. It is not designed to build reliable and highly functional tools for project planning. As a result, failures and errors often occur, which can lead to additional delays and misunderstandings in the development of the project.

Another disadvantage is inefficiency. Scrum Poker planning requires each participant to have a group discussion and select a difficulty score for each task. This can be an extremely time consuming process, especially on large projects. Instead of focusing on actually completing tasks, the team spends endless hours debating the complexity of each task.

Another disadvantage is the difficulty to use. In order to start working with Scrum Poker planning, you need to master not only the principles of Scrum, but also knowledge in the field of web development as well as in other areas (for example, during a group daily meeting or when calling to evaluate tasks, you need to know the work of a layout designer or designer or vice versa). This makes the process inaccessible to many professionals and increases and distorts the scores.

In addition, Scrum Poker planning lacks flexibility. Times and deadlines can change across projects, and this tool does not provide effective mechanisms for adapting to changes. This may cause the plan to be inconsistent with the real needs of the project.

also, estimating in abstract balances does not incentivize to complete the task in a given time frame for a given developer.

In conclusion, for all its merits, Scrum Poker planning leaves a lot to be desired. Its unreliability, inefficiency, complexity, and inability to adapt flexibly make it a dubious choice for many teams. There are more reliable and efficient project planning tools, and using Scrum Poker may not be worth your time and effort, and other tools and methodologies are better.

The pointlessness of scrum meetings for programmers

Scrum meetings are a strange part of the Scrum project management methodology, which can doubtfully help or harm the development team with irrevocable loss of time. In this regard, many programmers consider these rallies pointless, and there is some truth in this.

Programmers typically have technical skills and specialize in creating software. Programmers are not public speakers or actors, and their strength lies in writing code, not speaking in front of an audience. Therefore, for many programmers, attending daily Scrum meetings is wasted time.

One of the reasons why Scrum meetings can seem pointless is their format. Rallies should generally be short and focused on specific issues: what has been done, what is planned to be done, and what problems have arisen. For many programmers, this may seem formal and routine.

However, sometimes Scrum meetings have their value. They help the team stay informed about the current state of the project, identify problems and find ways to solve them. In addition, they promote communication and collaboration within the team, which is also important for the successful completion of the project.

To make Scrum meetings more meaningful for programmers, teams can try a variety of methods and approaches. For example, you can try to reduce the duration and number of rallies, making them more specific and targeted. It is also worth paying attention to the fact that only those people whose presence is really necessary participate in rallies!

In conclusion, Scrum meetings in general are pointless for programmers, but they cannot play an important role in the Scrum methodology and do nothing to help teams stay organized and focused. Even by optimizing the format and focus of meetings, teams will not be able to make them more effective and engaging for participants. Remember time is a valuable thing in our world.

conclusions

What is the main goal of software development?

The answer is to maximize quality and reduce development time as much as possible.

Using poker planning in abstract points, it creates some convenience for grouping tasks for a sprint, but does not reduce the overall development time.

If rallies should take place, they should only take place between those participants for whom it is really necessary and only when it is really necessary.

See also

• Similarities and differences between the work of a Scrum Master and a Toastmaster, or is a Scrum Master needed?