How can you avoid agile anti-patterns in estimation, planning, and prioritization?

1 What are agile anti-patterns?

Agile anti-patterns are behaviors or practices that go against the agile principles and values, such as collaboration, feedback, adaptation, and customer satisfaction. These often arise from misunderstanding, misapplication, or resistance to agile methods. For instance, estimating tasks or features based on hours or days instead of relative complexity or value; planning too far ahead or too rigidly without considering changes or uncertainties; prioritizing features or requirements based on opinions or assumptions instead of data or feedback; ignoring technical debt or quality issues in favor of speed or scope; and micromanaging or controlling the team instead of empowering or trusting them are all examples of agile anti-patterns.

2 How to avoid agile anti-patterns in estimation?

Agile estimation is an important part of agile development, and it involves using relative measures instead of absolute ones. This means that instead of estimating how long a task or feature will take in hours or days, you compare it to other tasks or features. This allows you to account for the variability and uncertainty of the work, as well as the learning and improvement of the team. Common techniques for relative estimation include story points, which represent the size or effort of a user story based on complexity, uncertainty, and risk; planning poker, which involves team members voting on the size of a user story with cards with different story point values; and t-shirt sizes, which is a way to categorize user stories into small, medium, large, or extra-large based on their relative size or effort.

3 How to avoid agile anti-patterns in planning?

Agile planning involves an iterative and incremental approach, rather than linear or waterfall. This means that instead of planning the entire project from the start, you plan the most valuable and feasible features or requirements for the next iteration or sprint. You then review and adjust the plan based on the feedback and learning from the previous iteration or sprint. This allows you to deliver value to the customer faster and more frequently, as well as respond to changes or uncertainties more effectively. Common techniques for iterative and incremental planning include a product backlog, a sprint backlog, sprint planning meetings, sprint reviews, and sprint retrospectives. The product backlog is a list of features or requirements that the customer or stakeholder wants from the product, ordered by priority or value. The sprint backlog is a subset of the product backlog that the team commits to deliver in a fixed time period. During sprint planning meetings, the team selects user stories from the product backlog that they can complete in the sprint, and breaks them down into tasks. Sprint reviews involve demonstrating the product increment to the customer or stakeholder and collecting feedback and suggestions for improvement. Finally, sprint retrospectives are meetings where the team reflects on their performance and processes, and identifies actions for improvement.

4 How to avoid agile anti-patterns in prioritization?

The final aspect of agile estimation, planning, and prioritization is to use data-driven and customer-centric methods instead of opinion-based or assumption-driven ones. Rather than prioritizing features or requirements based on what is assumed or believed, it is important to prioritize them based on what is known from the data or feedback. This will ensure that you are delivering the most valuable and satisfying product to the customer. Common techniques for data-driven and customer-centric prioritization include the MoSCoW framework, Kano model, user feedback, and user stories. The MoSCoW framework categorizes features or requirements into four groups: Must have, Should have, Could have, and Won't have. The Kano model classifies features or requirements into three types: Basic, Performance, and Delightful. User feedback involves collecting and analyzing feedback from users through surveys, interviews, tests, reviews, etc., while user stories express features or requirements from the perspective of the user.

5 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?