Estimation. The year starts with a conversation on why two people asked to estimate the same thing of testing come up with two entirely different estimates.
I was working with #NoEstimates so long that this "know how much you plan on invoicing us" is sometimes exhausting, especially when my personal metrics show that that portion of work I do before I am allowed to do the work is 32 to 39.
This article illustrates a classic problem with the common use of #velocity as a metric.
https://betterteams.fm/articles/2019/06/Velocity-Escape-this-Pitfall/
@storchp @scrumschau #NoEstimates - Velocity ist IMMER kontraproduktiv
📊 "AI makes estimation more accurate!"
Wrong problem. Estimation is flawed because it ignores variability & creates false precision.
AI can't consider code quality, hidden dependencies, or team dynamics.
Real value of estimation? Team conversations that build shared understanding.
#NoEstimates #Scrum
https://agilepainrelief.com/blog/gen-ai-and-the-feature-factory-automating-away-collaboration/
@tottinge Estimation of software tasks is not difficult, it is mathematically impossible (J.P.Lewis, ACM 2001).
It is not that humans are bad at estimating (though they are), it is not that they need a better system of task estimation, it is that estimation is completely useless and a waste of time and effort.
Instead apply predictive forecasting and Monte Carlo analysis q.v. Vasco Duarte #NoEstimates
Putting Folks’ Needs First – Skip the User Stories vs Use Cases Debate
Putting Folks’ Needs First – Skip the User Stories vs Use Cases Debate
The software industry spends an enormous amount of energy debating practices—user stories versus use cases, agile versus waterfall, documentation versus conversation. Meanwhile, the people who actually matter—the ones who will use, buy, build, maintain, and profit from our software—are often afterthoughts in these discussions.
It’s time to flip the script. Instead of starting with methodology and hoping it serves people’s needs, let’s start with the Folks That Matter™ and choose our approaches accordingly. This is what the Antimatter principle calls “attending to folks’ needs”—recognising that the value of any practice lies entirely in how well it serves real folks’ actual needs. Let’s can the endless debating by attending to folks’ needs.
Who Are Your Folks That Matter™?
Before you write your first user story or draft your first use case, pause and identify who actually needs to understand and act on your work. These aren’t abstract roles—they’re real people with specific needs, constraints, and ways of thinking.
Sarah, the product manager, thinks in user journeys and business outcomes. She needs to understand how features connect to customer value, competition, and revenue impact. Dense technical specifications make her eyes glaze over, but she can instantly spot when a user story misses a crucial business rule.
Marcus, the lead developer, needs enough detail to identify technical risks and understand how new features interact with existing systems. He’s been burnt by vague requirements that seemed clear in meetings but fell apart during implementation. Interestingly, Marcus has embraced the #NoEstimates movement—he’s found that detailed story point estimation often becomes an end in itself, consuming time that could better be spent actually building software. He prefers breaking work into small, similar-sized pieces that flow predictably.
Katarzyna, the compliance officer, must ensure the product meets regulatory requirements. She needs traceable documentation that auditors can review. Conversational approaches that leave decisions undocumented create legal risks she can’t accept.
Jennifer, the customer success manager, deals with confused users when needs miss real-world scenarios. She has to understand not just what the software should do, but what users might expect it to do based on their mental models.
Each of these people has legitimate needs. The question isn’t which methodology is ‘right’—it’s how to serve all the Folks That Matter™ effectively. As the Antimatter principle reminds us, any practice that doesn’t attend to folks’ needs is waste, regardless of how theoretically sound it might seem.
When teams, and indeed organisations, focus on attending to folks’ needs rather than defending methodological positions, the endless debates about user stories versus use cases simply evaporate. The answer becomes obvious: use whatever works for the specific people and their specific needs, in your specific context.
Matching Methods to People’s Needs
When your Folks That Matter™ need exploration and alignment, user stories excel. The product manager who’s still figuring out what customers really want benefits from the conversation-starting nature of story cards. The development team discovering technical constraints needs the flexibility to evolve requirements as they learn.
Sarah’s team was building a new invoicing feature. They started with a simple story: ‘As a small business owner, I want to send professional invoices so that I get paid faster.’ This sparked conversations about payment terms, tax calculations, and branding options that no one had considered upfront. The story evolved through dialogue, and the final feature was far richer than anything they could have specified initially.
Marcus particularly appreciated this approach because it aligned with his #NoEstimates philosophy. Rather than spending hours estimating a vague story, the team broke it into small, discoverable pieces that they could complete in a day or two. The predictable flow of small stories gave Sarah the planning visibility she needed without the overhead of detailed estimation ceremonies.
When your Folks That Matter™ need precision and accountability, use cases provide the structure they require. The compliance officer who must demonstrate regulatory adherence needs documented workflows with clear preconditions and outcomes. The offshore development team working across time zones needs detailed scenarios they can implement without constant clarification calls.
Katarzyna’s team was building patient data access controls. A user story like ‘As a doctor, I want to access patient records so that I can provide care’ was legally meaningless. They needed use cases that specified exactly which roles could access what data under which circumstances, with full audit trails. The systematic format of use cases made regulatory review straightforward.
When your Folks That Matter™ have different thinking styles, provide multiple views of the same requirements. Don’t force the visual thinker to work with text-heavy use cases or make the detail-oriented analyst guess at implementation specifics from high-level stories.
Marcus and Sarah worked together by starting with story mapping to visualise the user journey, then drilling down into detailed use cases for complex workflows. Sarah could see the big picture and business logic, whilst Marcus got the implementation details he needed. Same requirements, different representations.
Notice how none of these decisions required theological arguments about methodology. Each choice served specific people’s specific needs. Attending to folks’ needs cuts through the debate noise.
The #NoEstimates Reality Check
The #NoEstimates movement highlights a crucial insight: detailed requirements often become proxies for prediction rather than tools for understanding. Teams can spend enormous effort estimating user stories with story points, planning poker, and velocity calculations, but these estimates rarely improve delivery predictability and often distract from actually building software.
Marcus’s team discovered that when they focused on making stories consistently small rather than accurately estimated, their delivery became more predictable. Instead of debating whether a feature was 5 or 8 story points, they asked whether it could be broken into e.g. artefacts that could each be completed in a day or two. This shift changed how they captured folks’ needs —less focus on comprehensive upfront specification, more focus on just-enough detail to start work confidently. See also: the Needsscape.
This doesn’t mean abandoning planning entirely. Sarah still needed roadmap commitments and budget forecasts. But the team found they could provide better predictions by counting delivered stories over time rather than summing estimated story points. Their artefacts became lighter and more focused on enabling flow rather than feeding estimation ceremonies.
The endless debates about estimation versus #NoEstimates dissolve when you ask: what do our Folks That Matter™ actually need for planning and coordination? Often, it’s predictable delivery more than precise estimates.
The Misuse Case Reality Check
Here’s where focusing on Folks That Matter™ becomes crucial: the people who deal with software problems aren’t usually the ones writing requirements. Jennifer in customer success fields calls when users accidentally delete important data. The security team deals with the aftermath when features are misused maliciously.
These voices often aren’t heard during needs capture and evolution, but they represent critical Folks That Matter™. Building ‘misuse cases’ into your process—whether you’re using stories or formal use cases—ensures you’re serving the people who have to deal with problems, not just the ones who use features successfully.
Jennifer pushed her team to consider stories like ‘As a malicious user, I want to exploit the file upload feature so that I can access other users’ data’ and ‘As a confused user, I want to understand why my action failed so that I can correct my mistake.’ These weren’t happy path features, but they prevented real problems for real people.
The Antimatter principle particularly applies here: security reviews and error handling often feel like bureaucratic overhead, but they directly serve the needs of people who deal with the consequences of product failures.
Documentation vs Conversation: Serving Different Needs
The agile manifesto’s preference for ‘individuals and interactions over processes and tools’ doesn’t mean documentation is evil—it means putting people first. Sometimes the Folks That Matter™ need rich conversation to discover what they really need. Sometimes they need comprehensive documentation to do their jobs effectively.
Conversation serves discovery. When your product manager is exploring new market opportunities or your development team is prototyping technical approaches, dialogue-heavy user stories facilitate learning and adaptation.
Documentation serves execution and accountability. When your distributed team needs to implement complex business rules or your compliance officer needs to demonstrate regulatory adherence, written specifications provide the clarity and traceability required.
The most effective teams recognise that these aren’t competing approaches—they’re different tools for serving different people at different times. The Antimatter principle’s “attend to folks’ needs” helps teams avoid dogmatic adherence to either extreme.
The endless documentation versus conversation debates end when you focus on what your specific people need to do their jobs effectively.
Timing That Actually Works for People
The ‘up front versus evolutionary’ debate often ignores the reality of how different Folks That Matter™ actually work. Product managers need enough certainty to make roadmap commitments. Developers need enough detail to minimise rework. Operations teams need enough notice to prepare infrastructure.
Instead of choosing between comprehensive upfront planning and just-in-time discovery, map your requirements approach to the actual decision-making needs of your stakeholders.
Identify architectural decisions early because they affect everyone downstream. The integration approach that seems like an implementation detail to the product manager might require months of infrastructure work from the operations team.
Keep UI and workflow details evolutionary because these benefit from user feedback and technical learning. The exact button placement that seems critical upfront often changes once users actually interact with early versions.
Document agreements when they affect multiple teams because people need to coordinate their work. The API contract between frontend and backend teams needs to be explicit, even if the user story that drives it remains flexible.
This timing approach aligns well with #NoEstimates thinking: instead of trying to estimate everything upfront, identify what decisions must be made early and defer the rest until you have better information.
When you attend to folks’ needs, the timing becomes obvious. No more theoretical arguments about waterfall versus agile—just practical decisions about when different people need different information.
Making It Work: Practical Steps
Start with your Folks That Matter™ inventory. List the real people who need to understand, implement, test, support, and approve your software. Understand their constraints, preferences, and success criteria.
Match your methods to their needs. Use stories when stakeholders need to explore and align. Use cases when they need to implement and verify. Use both when you have both types of needs.
Question estimation ceremonies. Ask whether detailed story point estimation actually serves your Folks That Matter™ or just creates busy work. Consider focusing on consistent story size rather than accurate estimation.
Create feedback loops with the people who live with the consequences. Regular check-ins with customer support, security teams, and operations prevent requirements that look good on paper but fail in practice.
Evolve your approach as your team learns. The startup exploring product-market fit needs different requirements approaches than the enterprise team maintaining critical systems. Let your methods serve your current reality, not your methodology preferences.
Stop the methodological debates. When teams start arguing about the “right” way to write requirements, refocus on the Folks That Matter™. Ask: “Who needs this information, and how do they prefer to receive it?”
The Real Test
The ultimate test of your approach isn’t methodological purity—it’s whether the Folks That Matter™ can successfully do their jobs. Can the product manager make informed decisions? Can the developer implement features correctly? Can the support team help confused users? Can the compliance officer satisfy auditors?
The Antimatter principle provides a simple filter: does this practice attend to folks’ needs? If your user stories help stakeholders align and discover needs, they’re valuable. If they become exercises in elaborate estimation that don’t improve delivery, they’re waste. If your use cases provide necessary precision for implementation and compliance, they’re essential. If they become bureaucratic documentation that nobody reads, they’re overhead.
When you put people first, the user stories versus use cases debate becomes much simpler. You use whatever approaches help your specific stakeholders succeed in their specific contexts. Sometimes that’s collaborative story discovery. Sometimes it’s systematic use case documentation. Most often, it’s a thoughtful combination that serves different people’s different needs.
The approach matters far less than the people. Make sure your approach serves the Folks That Matter™, and the rest will follow. Can the endless debating by attending to folks’ needs—because when you focus on serving real people’s real needs, the “right” answer becomes obvious for your context.
Based on my verification, I found several issues with the citations I originally provided. Let me create a corrected Further Reading section with properly verified citations:
Further Reading
User Stories and Agile Requirements
Cao, L., & Ramesh, B. (2008). Agile requirements engineering practices: An empirical study. IEEE Software, 25(1), 60-67. https://doi.org/10.1109/MS.2008.9
Cohn, M. (2004). User stories applied: For agile software development. Addison-Wesley Professional.
Lucassen, G., Dalpiaz, F., van der Werf, J. M. E. M., & Brinkkemper, S. (2015). Forging high-quality user stories: Towards a discipline for agile requirements. In 2015 IEEE 23rd International Requirements Engineering Conference (RE) (pp. 126-135). IEEE.
Use Cases and Requirements Engineering
Cockburn, A. (2001). Writing effective use cases. Addison-Wesley Professional.
Jacobson, I. (1992). Object-oriented software engineering: A use case driven approach. Addison-Wesley Professional.
Pohl, K. (2010). Requirements engineering: Fundamentals, principles, and techniques. Springer.
#NoEstimates Movement
Duarte, V. (2015). NoEstimates: How to measure project progress without estimating. Oikosofy.
Killick, N., Duarte, V., & Zuill, W. (2015). No estimates – How to deliver software without guesswork. Leanpub.
The Antimatter Principle
Marshall, B. (2014, May 22). Q&A with Bob Marshall about the Antimatter Principle. InfoQ. https://www.infoq.com/news/2014/05/antimatter-principle/
Empirical Studies and Academic Research
Inayat, I., Salim, S. S., Marczak, S., Daneva, M., & Shamshirband, S. (2015). A systematic literature review on agile requirements engineering practices and challenges. Computers in Human Behavior, 51, 915-929. https://doi.org/10.1016/j.chb.2014.10.046
#NoEstimates — was my take 10 years ago.
In a nutshell, estimates is a tool to negotiate price, and to stress workers.
As a species, we should move away from it. However, it will be only done on legal basis.
Like prohibition of slavery.
https://www.slideshare.net/slideshow/noestimates-33444583/33444583
An die Engeneering-Bubble: Was haltet ihr von #NoEstimates?
@mlevison Estimates are waste.
#NoEstimates
@gbip @ttuegel it is very creatively called #NoEstimates :D
Story Points не работают? И другие мифы про оценку задач, в которые мы почему-то верим
Про Story Points можно услышать что угодно. На одной конференции спикер всерьёз говорил: «Story Points — это плохо. Не используйте их вообще. Плохая практика». Но почему столько хейта? Неужели всё действительно так плохо? Или дело не в Story Points, а в том, как именно их используют? Меня зовут Семён, я тимлид в МТС Аналитике, бывший Java-разработчик, сертифицированный Scrum Master и преподаватель курса по Java в МФТИ. Веду блог. За годы работы много раз видел, как команды мучаются с оценками задач. В этой статье расскажу, за что критикуют оценки, чем отличаются человеко-часы от футболок и Story Points, когда их стоит применять — а когда лучше не мучиться и попробовать NoEstimates. И почему отношение к Story Points столь неоднозначно. Будет и про типовые ошибки, и про работающие подходы — чтобы планировать задачи без лишней боли. Спойлер: идеального способа оценки задач не существует. Зато есть вполне рабочие способы не сойти с ума и при этом нормально планировать работу.
https://habr.com/ru/companies/oleg-bunin/articles/908522/
#story_points #noestimates #черный_лебедь #критерии_оценки #антипаттерны #scrum
My new #DesignAccelerator longform tutorial:
"Estimates vs. #NoEstimates"
Please Like! ❤️ and Subscribe! 🔔
How in the green, green earth do you DON'T estimate?
Or, what you always wanted to know about not estimating software delivery times but were afraid to ask.
@dectentoo in my own experience I see only a weak correlation between story points and effort; that plus the fact that teams often cargo-cult story pointing as the point of story refinement makes the whole process a misleading waste of time. #NoEstimates and flow/throughput tracking is the way to go in my opinion.
I spend most of my work hours trying to convince people that estimating software is impossible.
And then I spend most weekends trying to convince family members that estimating our arrival time with two toddlers is impossible.
This article illustrates a classic problem with the common use of #velocity as a metric.
https://betterteams.fm/articles/2019/06/Velocity-Escape-this-Pitfall/
Roman Estimation looks like an alternative approach to estimating story points, when #NoEstimates is off the table.
Intro to Beyond Estimates with Woody Zuill
The Budget-First Revolution: What Most Product Development Teams Don’t Know
The Budget-First Revolution: What Most Product Development Teams Don’t Know
In the world of product development, there are two fundamental approaches to budgeting: the cost-first approach (“How much will it cost?”) and the budget-first approach (“What can we get for our notional budget limit?”). Despite these being equally valid options, most organisations default to cost-first estimation simply because they’re unaware that budget-first is a legitimate alternative. This unconscious limitation of choice often leads teams down a path of unnecessary estimation complexity when a simpler approach might better serve their needs.
The Cost-First Approach: The Traditional Path and Its Pitfalls
The cost-first approach begins with a vision of what needs to be built and works backwards to determine the necessary budget. Whilst familiar to many organisations, this traditional estimation-based method comes with significant challenges and drawbacks:
The Estimation Fallacy
Studies consistently show that development estimates are notoriously inaccurate. The Cone of Uncertainty suggests that initial estimates can be off by a factor of 4x – or more – in either direction. Even with experienced teams, complex projects routinely exceed their estimated budgets by 50% or more.
Hidden Costs of Estimation
The process of creating detailed estimates consumes significant time and resources. Teams often spend weeks in estimation meetings, agreeing requirements, preparing documentation, and defending their numbers – time that could be spent actually building and delivering value.
The Planning Fallacy
Humans consistently display optimism bias in planning, underestimating the time and effort required for complex tasks. This psychological tendency, combined with pressure to provide “acceptable” estimates, leads to systematic underestimation.
Requirements Instability
The cost-first approach assumes requirements can be accurately defined upfront. In reality, requirements often change significantly during development as understanding evolves and market conditions shift. This makes initial estimates increasingly irrelevant as the project progresses.
Perverse Incentives
When estimates become commitments, teams face pressure to cut corners to meet arbitrary deadlines. This can lead to technical debt, reduced quality, and increased long-term costs. Additionally, teams may pad estimates defensively, reducing trust and transparency.
The #NoEstimates Movement
In response to these challenges, the #NoEstimates movement has emerged as a critique of traditional estimation practices. Pioneered by practitioners like Woody Zuill and Neil Killick, the movement questions the value of detailed upfront estimation in product development.
Core Principles of #NoEstimates:
Alternative Metrics
Instead of detailed estimates, #NoEstimates advocates suggest focusing on:
The Budget-First Approach: Starting with Notional Limits
The budget-first approach flips the traditional model by starting with a notional budget limit and determining what can be delivered within those constraints. Whilst this approach has gained popularity with the rise of agile development and lean startup principles, it remains surprisingly underutilised. Many teams continue with tortuous estimation processes simply because they don’t realise they have a choice.
Understanding Notional Budget Limits
The term “notional budget limit” is crucial here – it represents the realistic financial boundaries within which the team must operate. This isn’t about arbitrary restrictions, but rather about acknowledging the actual financial constraints that exist in most organisations. These limits might come from:
Working Within Known Constraints
Rather than spending time estimating costs that may or may not fit within available budgets, teams start with the known financial constraints and work backwards. This creates a more focused conversation about:
Prioritisation is Key
Rather than exhaustively documenting all possible features, teams focus on identifying and prioritising the most crucial functionality. This often leads to better-focused products that deliver core value more efficiently.
MVP Definition
Teams work backwards from the notional budget limit to define a Minimum Viable Product (MVP) that fits within financial constraints whilst delivering essential functionality. This forces tough but valuable conversations about what features are truly necessary versus nice-to-have.
Innovation Through Clear Constraints
Understanding the notional budget limit upfront often drives more creative solutions. Teams focus their innovation efforts within known parameters rather than generating ideas that may prove financially unfeasible.
Why Teams Don’t Choose Budget-First
Understanding why budget-first remains underutilised can help organisations make more conscious choices about their approach:
Cultural Inertia
Many organisations have deeply ingrained practices around estimation and budgeting that are rarely questioned. The very idea that there might be an alternative to detailed estimation often comes as a surprise.
Misunderstanding of Control
There’s a common misconception that detailed estimates provide more control over development outcomes. In reality, budget-first approaches often provide better control by forcing early decisions about priorities and trade-offs.
Fear of Commitment (Lack of Trust)
Some organisations avoid stating budgets upfront, believing it will lead to teams consuming the entire budget regardless of need. This fear often leads to the more wasteful practice of extensive estimation exercises.
Procurement and Governance Requirements
Many organisations believe their governance processes require detailed estimates. In reality, most governance requirements can be satisfied through budget-first approaches with appropriate documentation of assumptions and priorities.
Choosing the Right Approach
The choice between cost-first and budget-first approaches often depends on several factors:
When to Use Cost-First
When to Use Budget-First
Making the Choice Conscious
To move towards more effective budgeting approaches, organisations might choose to:
Question Default Practices
Before automatically responding to the question “How much will it cost?”, teams might choose to explicitly consider whether a budget-first approach might be more appropriate.
Educate Stakeholders
Help decision-makers understand that budget-first is a valid and often more effective approach. This includes explaining how it can lead to better outcomes and more efficient use of resources (i.e. lower costs, quicker time to market).
Start Small
Consider piloting budget-first approaches on smaller projects where the stakes are lower and resistance to change may be less intense.
Success Factors for All Approaches
Regardless of the chosen methodology, certain factors are crucial for success:
Clear Communication
All approaches require transparent communication about constraints, whether they’re financial or functional. All stakeholders may choose to understand and agree to the chosen approach and its implications.
Realistic Expectations
Teams may choose to be honest about what can be achieved, whether working within a fixed budget or estimating costs. Over-optimism in either approach leads to disappointed stakeholders and stressed teams.
Regular Review and Adjustment
All approaches benefit from regular checkpoints to assess progress, adjust plans, and ensure alignment with business objectives Cf. Tom Gilb’s Mountain Goat principle). This includes being willing to make tough decisions about scope, quality, or additional funding when necessary.
Conclusion
Whilst the cost-first approach remains common in many organisations, this is often due to habit rather than conscious choice. The emergence of budget-first thinking, which starts with notional budget limits, reflects a broader shift toward more adaptive, value-focused approaches to development.
The key is not just to choose between approaches, but to make that choice consciously rather than defaulting to traditional estimation methods out of habit. By acknowledging that working within notional budget limits is a valid starting point, organisations can make better choices about how they approach budgeting and delivery.
Success in modern development invites questioning of traditional practices and being willing to adopt approaches that might initially feel uncomfortable. Whether through budget-first methods, #NoEstimates practices, or hybrid approaches, organisations have more options than they often realise for moving beyond the limitations of traditional cost-first estimation.
