The things Agile teams struggle with — a common denominator
It’s all about how you think
I have often heard and seen agile teams having difficulties with user stories, estimation, acceptance criteria, and testing.
There is, I have found, often a common denominator to these problems and the teams that struggle with them — a root cause, if you like.
If you or your team are struggling to estimate, if you are struggling to come up with acceptance criteria for your use stories, or even to write the stories in the first place, there is something you might like to consider — are your stories describing the thinks that someone else needs or wants, or something that you or your team need to do?
I find it is often the latter. And this is the root of the problem — we are thinking about the work we need to do (our output) more than the outcome that we are expected to achieve. And we are planning based on the work we need to do before we sufficiently decompose those expected outcomes. In essense we are putting solutions before problems.
It is quite natural, actually. Whenever we are given an objective, it is natural for us to think about the steps we need to take to get there, in other words: what work do we need to do to achieve that Epic, that Feature, that Capability?
But that thinking is precisely what’s causing the problems teams are struggling with. The practices of writing user stories, acceptance criteria and of relative estimation in story points are all predicated on the assumption that we are planning based on a prioritised set of user stories — individual items that describe user or customer needs (their requirements if you will) at a fine-grained level. If those user stories describe the work the team needs to carry out, defining acceptance criteria becomes not only difficult but irrelevant. Estimation in story points also becomes much more challenging because the work so described is usually the preserve of one person, or one function, and others find they cannot estimate it because they don’t understand it. This, by the way, is a key indicator that the story isn’t a user story.
Decomposing large requirements into a long list of tasks — things to do — misses the whole point of agile planning. Things get much easier when you decompose large requirements into smaller requirements instead.
The key is the way we think about planning. As a rule of thumb, plan the work you need to do at the same level of granularity as the requirement you are given. The bigger the requirement (the longer it will take to deliver), the more general and high-level the thinking about solution. The smaller and fine-grained the requirement, the more detail we factor into our thinking about the solution.
This usually means that Epics, with their acceptance criteria, contain only solution assumptions or options, if that. The actual work to be done is deliberately not captured at this level. Only once the Epic is decomposed into a number of user stories, each with its own acceptance criteria, can the team consider the tasks that need to be completed in order to meet the acceptance criteria for the story to be considered ‘Done’.
Delaying until the last responsible moment the time when you define the work to be done, really helps the team focus on outcomes.
