In an interesting Twitter thread, Ron Jeffries (signer of the original Agile Manifesto) is suggesting that all user stories should be broken down so that they have one, and only one, acceptance test.

The aim is to remove the need for estimation on user stories: the idea is that such user stories will all have the same "weight" regardless of how you estimate them... so that estimation is then just down to counting them.

So my question is: How do you get to a point where user stories are small enough that just one acceptance test is OK?

Any information appreciated, especially if you've actually tried this!

  • Downvoter: any suggestions on how to improve the question?
    – Peter K.
    Jul 25, 2018 at 16:49

3 Answers 3


There is clearly a dilemma between 'user stories as expressed by the customer' and 'tests small enough to tell you what is broken'

A user story is meant to be just that, not a break down of all the edge cases. If you try and make them that small then you are going to miss some and the customer will lose connection and say 'but that's not what I asked for!'

A big test, 'can the user log in' might be good for acceptance checking and pass/fail on the story. But it wont cover important edge cases that you should be testing.

I don't think you should try and resolve this. Just keep the story big and write more tests.

This guy is clearly chasing the latest hype rather than worrying about practicalities.


BDD presents an approach that might be useful: A user story is fleshed out with scenarios/examples. These scenarios are both human-readable specification and executable tests of behaviour. Each scenario is then small enough that it can be counted.

There will still be considerable variability for the effort between scenarios, but by packaging them into small unambiguous scenarios the risk of unexpected variability is reduced.

TBH I think the variability between scenarios will still be so large that it's not practical to simply count them. In particular, the first few scenarios of a story will see more effort for infrastructure from which later scenarios benefit.

It should also be noted that by breaking a user story into small testable scenarios, we are front-loading a lot of the risk. This is arguably good, in the sense of failing fast. But breaking stories down is also a lot of the effort of implementing a story. This gives rise to the meta-question: which story is worth breaking down next? How much effort would breaking down this story or that story be? Estimating that preparation is of course simpler than estimating the whole implementation of a complete story, but in a sense we are merely trading one approach to estimation for a simpler approach with less fidelity.


This is my speculation what this might mean:

If you have several unittest that cover the different scenarios (In login example: user has account, is not blocked, password is correct, ...) then it might be ok to have only one acceptance test (as a kind of integrationtest).

Without context this statement is quite useless

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.