Documentation is like alcohol in that the more we distil it down, the more powerful but potentially hazardous it becomes.
I'm a strong believer in minimising documentation. I'm also well aware that as we reduce the information we capture, the importance of what's left relatively increases. Nothing supports this more than acceptance criteria that are added to user stories.
I personally believe collectively elaborating user stories to identify acceptance criteria to be the most important team activity in agile work, even more so than retrospectives. I therefore find it surprising how some people under-appreciate the importance of creating acceptance criteria. On many agile teams I've started working with writing 'ACs' has either not been done at all, or if it is done is something the Product Owner is expected to write in full well before the story is started (I challenge that approach here). In this short post I'm going to focus specifically on what good acceptance criteria look like to me.
What do good acceptance criteria look like?
With great power comes great responsibility. By their very nature user stories should not dictate how value is delivered, but an effective elaboration process should identify options that need clarification. Well written acceptance criteria will capture the points of ambiguity that come up in our user story discussions and remove this in a clear and simple manner.
They are focused on user outcomes not outputs
For me the most important characteristic of good acceptance criteria for me is that they are written with the aim of delivering an outcome for the target user, rather than an output of the development team. Most user stories will have a one line value statement (maybe in a format like 'as a... I want... so that...' If you insist on that kind of arbitrary rigidity). Instead of clarifying a solution the purpose of acceptance criteria is to expand on this to more explicitly scope the problem being addressed. The reason this is so important is that it maintains a focus on the user and the value they want to get from the change which is vital for effective critical assessment of the solution.
They allow for changes in approach
A good acid test of whether we've achieved the above is it the acceptance criteria are resilient to a change in technical solution. I've seen teams that have embarked on a development only to discover that their first attempt at a solution proves to be unworkable. A well written set of problem focused acceptance criteria will allow for a rethink on the approach to a solution without any need for a rewrite the criteria supporting it.
They provide just enough points to scope
One of the key tenets of an agile approach is to keep things lightweight and avoid excessive documentation. The last thing we therefore want to do is burden the process with a lot of documentation at the last minute. The key here is capturing a bullet list of just enough points to be confident that we're progressing with a shared understanding. I typically aim for 3 to 8 points, more than this and I'd be looking at whether it was possible to split an item down.
They consider all affected stakeholders
The headline of a user story will hopefully focus on providing value to a primary stakeholder. Even the thinnest slices of capability have impact on other roles and it is important to represent their needs. In addition to the target users, any roles that shouldn't be able to access a feature need to be identified. Also administration and support users need to be considered in terms of the events they need to respond to and the information they need to do so effectively. Identifying the other users impacted and the outcomes for them is an important consideration for a robust solution
They consider negative as well as positive scenarios
A user story title will typically only cover the positive outcome we're looking for. Acceptance criteria should go beyond this to capture what we expect to happen in negative scenarios too. What do we expect to happen if the user doesn't supply the prerequisites to complete a task? What subsequent decisions to we need to support if this happens? Who will be informed of a batch failure and what they need to be able to do with that information? Considering the potential negative cases is vital to establishing a robust solution that avoids an overwhelming workload for your support team.
What about other stuff?
Not everything needs to be baked into our acceptance criteria. Sometimes points come up out of discussions that simply don't make sense to add to the success criteria for a story. I typically look to capture two additional types of information that cover most needs and help to guide later development and testing.
Working assumptions that help to scope the problem.
I encourage teams to identify any assumptions that are needed in the absence of knowledge to provide a starting point in framing the problem. This can include vital things like clarifying when we're deferring certain responsibilities to later work in order to reduce the scope. It's also useful to present figures that can set an expectation of reasonable performance while avoiding baking these into as fixed acceptance criteria (e.g. the page must load in under 1.5s) which can lead to a lot of wasted effort pursuing arbitrary goals.
Development risks
As an ongoing process it's important to capture the risks we perceive to be inherent in our approach. This may be to guide the developer to factor in some mitigation into the solution, or the tester to ensure they focus on the risk area, or both. What we want to ensure is that if we identify risks that simply aren't naturally covered by problem focussed acceptance criteria, then these are still captured in a way that allows them to be acted on.
Is it necessary?
You might argue that capturing acceptance criteria (and risks and assumptions) is still favouring documentation over face to face communication. I disagree. Just as a shopping list helps to ensure we don't forget the things we knew we needed when we left the house once we are in the shop, the acceptance criteria are simply there as a reminder of what we decided we needed to cover through our face to face discussions. In order to do this though they need to convey the same intention outside of the context of that conversation, and will only do so if written well. Given the scope for confusion if we don't have our high level outcomes captured, I don't believe that taking a few minutes to agree, capture and share a handful of key points is a high price to pay for a clear testable definition of success.
Photo by Adam Wilson on Unsplash
Great post. Thank you!
Post a Comment