I don’t think a lot of things have changed since I learned about the tree swing analogy. Which has been a while ago, and, even by then, that analogy had been around for a lot longer😄 So it’s probably been like this forever, I’d think it would also be applicable to the pre-software-development days:
Normally, we’d present the picture above to illustrate what the lack of communication may lead to, but is it really all there is to it or is there a deeper issue with our assumptions about what can be communicated upfront in the first place?
Here is a simple experiment. When I say “computer”, what do you think of? Is it the latest gaming PC with all the flashing lights, powerful video card, lots of memory, and with the latest generation of CPU? Or is it an office laptop which is not suitable for video gaming at all, but which works fine for document processing? What color is it – is it black, white, or is it, perhaps, pink? What’s the screen size?
There are infinite variations of computers, and, if I said “I need a new computer”, it would be a good starting point, perhaps, but, otherwise, it would be as if I said nothing.
Now apply this analogy to the software development, think of all the different people that are involved there, think of possibly all the different languages those people may speak literally and figuratively – some may speak English, others may speak Spanish and only have English as their second language, some may understand how the business works, yet others may have no idea, and yet some may be UI experts, while others may be pure technologists. How do you even hope to come up with something that would have the same meaning for all those folks?
But that’s more or less what we normally are trying to do with the user stories and acceptance criteria.
Which is where I see it failing all the time, and, no matter how hard we try improving our processes, we just seem to be unable to capture all the minor details, describe them properly, and put those into the user stories.
It does not help that user stories tend not to be written in stone. Normally, as we start implementing those, we also start making assumptions or adjustments – sometimes, we’ll reflect them in the comments to the story or in the description, and, sometimes, we’ll just verbally communicate those adjustments.
I could go on about the user stories, but… I’ll just jump to some conclusions right away instead.
Basically, I don’t believe a user story can thoroughly capture “what needs to be done” because, overall, “what needs to be done” is not defined on the user story level.
One could say that they need to be able to resolve a case in the application, but… is there a preference in terms of the UI, what color should the button be, is there an email notification that needs to go out, what happens to the related activities, what are the security roles involved… and I’m just getting started with those questions. More often they not, they’ll be captured as different user stories (if they get captured at all). Those will often be combined under bigger epics, so they will still be related, but keeping track of those relationships might soon become impossible for anyone working on the individual stories.
So, then, it seems treating those user stories as approximations of requirements without trying to make them overly perfect may work better, yet it may make everyone on the project feel better because the expectations get shifted.
Instead of assuming that a user story will provide all the details on what needs to be done, the assumption becomes that a user story will be a reasonable starting point, but, as for the details, they’ll have to be communicated and discussed as we go. In reality that’s what it is anyways – that’s, partially, why we often do our estimates in points, since user stories are just not perfect and there is always some uncertainty. And, then, once the story is implemented, we often add screenshots/detailed description of what’s been implemented to hand those stories off to the QA.
This also makes it easier for the product owners, or for the BA-s, to populate the backlog, since they don’t need to get stuck on all the minor details. However, this leads to some problems on the project management side.
First of all, this interpretation of user stories assumes that there has to be ongoing communication between developers/QA/product owner/other stakeholders, since, if our user stories are not perfect, there is no avoiding those discussions whenever we need to clarify what a user story is about. You can’t just assign a story to a developer and be done with it.
Although, in reality, could and/or should everyone on the team be part of those discussions?
The problem with this is that discussions take time. They are extremely valuable, since they are the only way for all team members to get on the same page, and they are also the only way for any team member to get a good enough understanding of the project. Once there, any team member can, potentially, discuss any user story with the stakeholders to come up with the cohesive implementation / test plan / whatever it is that’s required.
An alternative is, usually, to have someone who can tell you whether what’s been suggested or what’s been implemented is inline with what’s needed (irrespective of what was written in the story). This is, usually, where a product owner comes in, or, in the absence of the product owner, where a “proxy” role gets established (which will often be taken by a BA), though it’s, usually, less efficient.
And, so, we typically have at least three options:
a) We can try making our user stories perfect in the sense that every possible requirement/criteria will be captured there to the “just do it” level of details. Personally, I think it’s impossible
b) We can try turning every team member (including developers and QA) into a project/business expert who understands everything about the business and who can make proper decisions about “what needs to be done” when some of the details are missing or when they are contradictory. I think we should definitely set out some time for knowledge sharing, since, generally, that seems to help. But I don’t think the ultimate goal is achievable here because it takes time, and, also, because it just may not be feasible. After all, developers can come and go, but a project should continue, so there should be some people that have that knowledge, but everyone else should probably be consulting with those people as needed.
c) And that brings me back to the importance of the “product owners” and the reason they absolutely have to be available, at least in my opinion. Basically, with the user stories being inherently flawed, and with no one else having the ability (aka “expertise”) to validate what’s being done and/or even to answer requirements-related questions with certainty, the importance of the product owners cannot be overstated. Those are “go to” folks for every other team member, and those are, also, the only folks who can really validate if the stories have been implemented the way they were intended to be implemented (even if it’s different from what was originally written in the story description).
PS. This blog post was inspired by what Sharon Smith posted recently: https://www.linkedin.com/pulse/why-you-should-write-requirements-user-stories-your-developers-smith/?utm_source=share&utm_medium=member_android&utm_campaign=share_via It’s not that I completely disagree. Actually, the more context the better. But, again, I guess the point of having the user stories is not to provide all the possible details and context. It’s more to provide a skeleton of the project requirements, and, ultimately, producing a live solution as a result will require communication, collaboration, and some amount of creative common sense from every team member and a lot of validation effort from the product owner(s) – it’s unlikely we’ll ever be able to write user stories to such a level of details that there will be no room (and/or no need) for interpretation.