DEV Community: Stuart Dobson

Story Points are Utter Nonsense

Stuart Dobson — Fri, 27 Feb 2026 02:55:05 +0000

For over a decade, I've lived a lie.

I made myself believe that Agile Story points made sense.

I rationalised it like we all did.

"They map to complexity, not time".

Yet we spend hours on Sprint Planning meetings deciding how many jobs we can fit into a Sprint - a unit of time. Also - doesn't complexity relate to time?

"They're a rough guide, they're not supposed to be accurate."

How on Earth did we end up with a unit of measure that is "not supposed to be accurate"?

"It depends on experience of the person doing the job."

This is like saying the length of a centimeter depends on the tape measure you're using.

"They're a measure of relative complexity."

Relative to what? Another story you did which didn't have an accurate estimate?

"We use shirt sizes/Fibonacci/animals/fruit."

Is this supposed to make it easier to understand? Why can't I give a task 4 points?

"We have to agree on size before we can move on."

Yes, let's ensure the contractor watering the plants gets a say on this.

"Planning poker helps us find a consensus."

I guess it does, once everyone is worn down enough to just agree.

A recent discussion highlighted the absurdity. I asked people to define what story points were, and just like the multiple meetings I've had over many years, it was clear that nobody could agree.

I got the usual selection of contradictions and confusion.

Story points have no unit of value
Story points are a non standard unit of value(?)
They're team specific, so they don't map to anything
They don't map to time, but they do map to a sprint, which is time
They map to complexity, but how much depends on the experience of who is doing the job, and the maturity of the team, which changes over time.
They're only supposed to be used for Epics, and Stories are estimated in time
A Story point is like a chicken

Yes, that was a legitimate answer from someone attempting to explain what a story point was.

It's like a chicken.

This is a real thing a human said:

"I once had a Scrum consultant working with our team who said a story point can be a chicken if you wanted. Find a story that the team can say is a very simple piece of work and call that your chicken. This chicken is then 1 story point. A story that would be twice as difficult or complex would be a two-chicken story (or 2 story points). It's over-simplified, but perhaps you get the point."

Not sure I do..

Agile is a cult. This is evident in the explanations which pervade this space that are often repeated ad nauseam. One of these explanations becomes our rationalistion: "It's Agile. It's flexible - you can do it how you want."

It's time we admit that it doesn't work and it's really just a cocktail of nonsense, designed to put a framework around what is, in the end, an impossibly hard thing to plan.

I'm going to invent a new system of organising workloads. You have planning meetings once every 13 days unless there's a full moon. In those meetings you can play Snakes and Ladders to determine the "relative complexity" of a ticket. Then you throw that number out, and just do the job anyway. Every 15 minutes someone has to stand up and shout "Bingo". Then someone else picks up the ball.

Actually, this makes as much sense as our Agile rituals, so it'll probably take off.

I apologise to the workers of 2040.

Why should I care about Quality? I'm a developer!

Stuart Dobson — Sun, 15 Dec 2024 06:47:21 +0000

Quality is something QA do, right?

OK, so no developer wants to create bad quality code. But for most developers, quality is seen as something separate from development, something that is checked after the work has been done. It is something that QA do, after you throw your code over the fence. Thinking about quality at during development is a burden, slowing down the creation of functionality, holding up new features. Thinking about quality before development? That's just crazy talk.

Old Habits Die Hard

In the Agile world, Quality should be baked into the development process and there is more interaction between development and QA during the development phase. At least, that's the theory. In practice, we often slip back into bad habits of throwing code over the fence.

The reason we keep falling back into bad habits is because the attitude around quality is the same as it always was. It is still seen as something separate from development, separate from design, separate from planning. This causes it to be seen as a burden - extra work that just has to be done.

Quality as the Glue

If instead, we change our perspective, and try to see Quality as an integral part of the entire development process, it can change the way we all work, from developers to product owners. Instead of a burden, quality should be a thread that runs throughout the process, and actually defines how all work is done from the ground up. If this is done, it can actually simplify and speed up development.

Baking quality into your process shifts the responsibility to everyone, rather than just QA. Having the whole team (including product owners) take responsibility for quality sets the focus around Acceptance Criteria. This "requirements-centric" approach gets everyone thinking about quality right from the refinement meeting. When the entire team comes together and builds good Acceptance Criteria, quality becomes a natural, and welcome, part of the development process.

Several things then happen. First, the whole team are forced to agree on the details of the requirements before development starts. Before any technical decisions or implementation planning, the exact requirements are clarified. Only by making this an imperative part of the process (usually the refinement meeting) can this happen effectively.

Good Acceptance Criteria Drives Good Development

With clear Acceptance Criteria, development is simplified. Development knows exactly what they need to implement, and when they know this, the process of writing automated tests is no longer abstract and difficult. Test Driven Development is a tricky thing to do, in practice. However, with clear goals, a developer can start with "pseudo tests" - tests which are just code comments - but which outline the business logic before coding begins. These will be a granular list of Prerequisite/Action/Assertions - Unit tests, essentially - outlining the required logic. Then, development becomes a process of implementing that logic.

Breaking the logic down before development begins is a very effective way of ensuring that clean code practices, especially the Single Responsibility Principle, are followed. It becomes natural to keep the logic simple, concise, and separated from other concerns, such as infrastructure. It encourages clean Object Orientated design.

Good Acceptance Criteria Drives Good QA

Also QA know exactly what they will be getting. They know what parts of the job will be automated, so they can design better integration, acceptance, and End to End tests, as well as an effective exploratory strategy.

Without this clarity, QA are left with waiting until a job is done and not knowing what they're going to get - which is a recipe for annoying manual regression testing, and no doubt, bugs.

Agile Demands Quality, Quality Brings Clarity

Agile is about iterating fast. You cannot do this when QA are held back by a requirement to constantly manually regression test, or worse still, you avoid regression testing and hope new development doesn't break anything.

With good Acceptance Criteria baked into the process, everyone has clarity. As a developer, this makes your life so much easier. You know what needs to be developed before you start, which allows you to concentrate on technical implementation details. With clear requirements, the code is cleaner, so development and maintenance is easier. This allows the team to iterate fast, able to add new features quickly.

Early automated testing becomes a something that fits into the process, and with this automation in place, QA can focus on exploration. With automation, we are able to develop with confidence, and innovate freely.

Quality no longer slows down the development process, but guides it.

That's why developers should care about quality.

How to name Unit Tests

Stuart Dobson — Mon, 02 Dec 2024 23:59:11 +0000

How should you name your Unit Tests? What standards should you have in place for their names?

Who cares.

I'm not going to tell you the exact structure and format you need to use. That's up to you, your company, your Technical Lead, or whoever thinks this is important.

What I'm here to tell you is there are certain things you should always do when naming Unit tests and that it is quite important that these things are done.

So what are these important things that you need to do when naming Unit tests?

They need to be named in a way that tells you what scenario they are testing and what the outcome should be. Seems obvious but there's a bit of an art to this, and it's very easy to do wrong.

Why is it important for unit tests to tell you what they do? It's because coding is a team sport. Code needs to be read and maintained. Unit Tests are code and they also serve as documentation of your functionality. More so sometimes, than the code itself.

Other people (including future you) need to be able to look at the names of the test and know what specifically is being tested. Not just the what, but the when. When does the thing that you're testing happen? What is specific to this particular scenario that makes it special?

An example of naming being done badly would be Verify_Process. What does verify actually mean, and what is the Process?

Oh, the method you're testing is called "SomethingProcess()"? Well that's a problem right there. Rename it to explain what exactly the "process" is doing!

Also, verify doesn't tell me anything. What are you verifying? What makes the thing you're testing “verified”? How is someone who looks at this code in 18 months going to know that by looking at this name? If they can't determine its purpose from the name they'll end up having to look through the code of the test, which is a considerably slower process.

Telling us just what the test does is also not enough. AddNewCustomerTest is not enough. What scenario are you testing? That a new customer can be added is not a scenario but an action. What about testing when a customer is not added successfully, for some reason, or when they are added but already exist?

Also, when are they being added? For example, you might name the test: WhenCustomerHasFullName_CustomerAddedSuccessfully. Here is a test which tests the scenario of when the customer's full name is included in the post. The name includes the scenario "When the Customer's full name is entered" and the expectation: "Customer Added Successfully".

Including the scenario is the critical part of your test name. It explains the conditions of the action you’re performing. "When I do this". "When this data is included". "When I try to access this as an administrator".

The expectation is your expected result. The outcome of the test. This is as critically important as the scenario. Together they form a combination explaining the reason the test exists. "When this happens, this should happen".

Some of you may be aware of the pattern "SystemUnderTest_When_Then" for naming tests. This is fine, and I would recommend this structure, but only because it includes the scenario and the expectation. System under test, or the thing that you're testing, is descriptive and useful of course, but it can be easily inferred by looking at the code (unlike the scenario; and expectations can usually be easily gleaned from the Assertions), and also, you could include this in the class name, tags, or some other descriptor.

It's the scenario and expectation that anyone looking at the tests wants to know. These are the critical parts of a test's name.

Getting this right not only means that your tests are easy to follow and understand, but it encourages you to think up more combinations. You can write these combinations of scenario/expectation out before you even complete the bodies of the tests. If you were to name a test "GetTimeZoneTest", or "FileProcessorTest" how would you do this?

It's worth noting too, that you can include everything I talk about here in Description Attributes, or Tests Cases, if that's preferred, over the Test name. The point is that it's clear what the tests are doing.

By including the scenario and the expectation in your test names/descriptions, it will encourage you to think like a tester. You will become concerned with why you are writing the tests, and learn to link scenarios with expectations.

It will also make your tests easy to read and forms helpful documentation for future maintainers.

Don't Chase Unit Test Coverage

Stuart Dobson — Sun, 13 Nov 2022 09:57:18 +0000

In the long running battle between management chasing metrics and developers just trying to get the job done, (hi boss!) I wanted to provide some less obvious examples of why chasing code coverage is a damaging process.

Why Unit Test Code Coverage targets are bad

Code Coverage can be gamed, incentivising low quality tests

If the coverage percentage is all that matters, there are many ways to increase that number without actually improving the quality and reliability of the code. Having a test doesn’t mean no bugs - it just means the code is being run by a test, that the pathways through the code are exercised by another piece of code.

There’s not really any link in these tests to importance of functionality, or even any consideration of code doing the right thing, just that it’s being exercised.

Tests add a maintenance burden

In the writing of low value tests written only to satisfy KPIs, developers are actually making more work for themselves in the future.

All code adds a maintenance burden. Tests are code so adding tests adds to this burden. If they’re not valuable, they’re detrimental.

Chasing coverage leads to more brittle tests

The more coverage you have, the more brittle your tests actually become. By covering every internal path of a method, you are tightly coupling the tests with the implementation details.

This goes against the spirit of testing. You should be testing the functionality of the code - the inputs, outputs, and decisions it makes, and the edge cases.You don’t need to be too concerned with how it makes those decisions.

This in turn makes you write tests the right way - thinking about the desired functionality instead of the coverage.

Give a false impression of robust code

It should be obvious but it’s often overlooked. High coverage, which as discussed leads to low quality tests which often don’t test the right things, gives a false sense of security. You may have 80% coverage but if the last 20% is all the business critical functionality, or vital areas of the code, this could be hiding big problems.

Chasing metrics hides opportunities to improve the code quality

Let’s remember why we write tests in the first place. It’s to have confidence that our code is meeting the requirements, can handle edge cases, and is free of bugs. By focusing on coverage, you are missing the opportunity to write tests which do this - tests which actually lead to better quality code.

Thinking about what scenarios you need to cover when writing code, encourages you to write the code in a testable way. If you write it in a testable way, you’ll be more likely to write tests - valuable tests. Better still, you’ll be more inclined to write the tests, or at least stubs of them, first (Test Driven Development).

If you write code and then add tests as an afterthought, you’ll probably focus on coverage instead of functionality, because you’ll be thinking about “adding tests” and increasing coverage - rather than thinking about the original intentions of the code.

Why Code Coverage is good

Despite all these issues, Code coverage has a place in software development and there are some benefits to monitoring it, as opposed to incentivising it.

Identifies areas of low coverage

In combination with your knowledge of where important functionality lies, you can see where tests are needed. Without code coverage metrics, it’s pretty hard to do this.

Instills a culture of continually adding tests as you go

Let’s not forget that we want to be writing tests. We’ll get good coverage just by doing it as a habit, and by monitoring the coverage, we’ll see it go down if we write code that’s untested. So this encourages us to keep up with writing tests as we add features, and helps us see when we’re not adding them.

This keeps test writing on everyone’s minds, and influences the culture to make people value tests.

If you’re not measuring, you don’t know if you’re improving!

Conclusion

This article is very much a developer’s perspective, but at the end of the day, code coverage is a Return on Investment decision. Care should be taken on where the coverage is increased. Writing tests for existing code should be done in a way that prioritises high value, low effort new tests.

Code coverage is a good thing in that it gives a picture of where you are, and helps you monitor your testing journey. It’s always problematic to incentivise metrics, or even push to maintain a level. But we should be mindful of the level of coverage.

Focus on code coverage detracts from why you should be writing tests in the first place. The important thing is that we build tests around requirements and edge cases - tests which exercise and document real life scenarios. Tests are not about lines of code covered. This is an indicator - not an incentive.

Writing tests is a very important part of software development. Do it for the right reasons, and it will be done well.

The Importance of Good Acceptance Criteria

Stuart Dobson — Thu, 23 Sep 2021 07:49:50 +0000

Acceptance Criteria can be seen as a chore, a convoluted, verbose set of prose with the sole purpose of satisfying "the business". At best, its value is underestimated and it is often written as a vague list of requirements.

Given the right attention, Acceptance Criteria can be extremely valuable to all members of a Scrum team. Before it can be done correctly, we have to understand its value.

So what exactly is the point of Acceptance Criteria?

Purpose of Acceptance Criteria

To define boundaries

Acceptance criteria help development teams define the boundaries of a user story. In other words, acceptance criteria help you confirm when the application functions as desired.

To reach consensus

Having acceptance criteria synchronises the development team with the client. The team knows exactly what conditions should be met, just as the client knows exactly what to expect from the developed functionality.

To allow for accurate planning and estimation

Acceptance criteria scenarios allow for the correct division of user stories into tasks so user stories are correctly estimated and planned.

To serve as a basis for tests

Acceptance criteria provide a good baseline for writing tests. Test cases can break down Acceptance Criteria to go into more functional detail, and to cover edge cases.

Acceptance Criteria helps the team deliver quality

Acceptance Criteria is vital for delivering quality. If done correctly, it can simplify development and guide a comprehensive testing strategy. It is the glue that holds requirements together.

Acceptance Criteria is valuable to all stakeholders; Developers, QA, Product Owners, and the team as a whole. How it helps each stakeholder, however, varies according to their role.

Good Acceptance Criteria

How it benefits Developers

Good Acceptance Criteria gives developers clarity and allows them to break down their tasks into manageable pieces of functionality. With visibility of all possible scenarios, good Acceptance Criteria actually allows optimum design of the code. It enables developers to structure their code in a way that best meets the requirements. The code can be written around each scenario, ensuring each criteria is met in the simplest way possible.

The clarity given by good Acceptance Criteria keeps the business requirements at the forefront of the developer's mind, helping them to avoid getting bogged down in technical details which may not be conducive to the task.

How it benefits QA

Good Acceptance Criteria can guide QA in generating test cases and any required test data. With clear, simple scenarios, QA will have a solid base for test cases, and can then focus on expanding the Acceptance Criteria to cover edge cases.

Without clear, broken down Acceptance Criteria, it can be hard to work out test cases. If this happens, certain scenarios might be missed, and the important expectations of the job might be overlooked.

How it benefits the team

Good Acceptance Criteria helps get all the team on the same page. It aligns everyone with common goals, and helps them work together to build out the requirements. This collaboration is important and often overlooked.

Development and QA can come together at the start of a task in order to work out what needs to be tested. This allows Development to perform some degree of Test Driven Development. Even if it isn't possible to write automated tests before the code, the developer will at least have a good idea of what those tests are going to be before writing any code.

QA can guide this process, elaborating on what they will be testing, helping to set up test data, and informing the developer of possible edge cases to watch out for.

If the Acceptance Criteria is missing anything, the Product Owner can be questioned for more details before the work commences. Without clear Acceptance Criteria, there is no way of knowing if there are any missing details.

Good Acceptance Criteria can make a difference

With good Acceptance Criteria, the team is able to see, at a glance, what is required from a task. It provides a consensus for the whole team which aids both planning and delivery.

Good Acceptance Criteria helps developers come up with cleaner code. It makes testers' lives much easier. It helps the team come up with the best Automated Testing solutions, which is vital for Agile projects. It helps the team plan the best possible approach, and avoids stumbling into questions mid-development.

Don't underestimate the value of good Acceptance Criteria. It can increase productivity, collaboration, and quality.