A conversation came up today in which a statement was made about having a set number (three, in this case) of acceptance criteria per user story. My gut reaction was that I didn’t agree, how can you define that? But then I got to thinking that maybe it wasn’t such a bad idea.
I turned to the internet and asked twitter, the replies were heartening.
@MikePearce in same way as teams using points can have a limit indicating story should be broken down, # of AC should also be trigger point
— Bethan Mack (@bethanmack) September 12, 2016
@MikePearce if the list gets too long, you probably need to split / descale the item
— mick maguire (@mick_maguire) September 12, 2016
I agree with these replies, however, I’m not convinced on having a fixed arbitrary limit. I think it’s a case of being vigilant and for someone to say “Hey, that’s a lot of A/C, maybe we should split this?”
It’s also relatively simple to avoid the limit by loopholes. For example, your A/C could be described as Given, When, Then. In this, you could add “and then … and then… and then…”. It’s still one A/C, but has multiple steps.
As with everything in the world of building software, it’s about balance and discipline.