Breaking problems down
So much of what I do as an engineer boils down to turning big problems into little problems. As a development team we will start with (not always well defined) requirements for new features or modifications to a product, and the goal is to meet those requirements quickly, correctly and maintainably.
Many engineering practices are designed towards being sure the requirements are clear and well defined.
The two approaches do have one thing in common - the work that is to be done right now is well defined. It's hard to work on a story if you don't know up front exactly what the goals of the story are and when you can say 'it's done'.
Scrum, XP, and all the others have processes and ceremonies in place for ensuring that, to let development teams to push back on requirements that are ambiguous or vague, and the tools to fix them. The different roles within the team all need to agree - yes we know what this story is asking for, we know when we've finished, and we know how to prove we really have finished.
Stories should have a statement of the work to be done, where and how the output should interact with the larger systems, the various behaviour scenarios (both good and bad) with what should happen in each case, and the acceptance criteria that must pass to say we're done.
One refinement tool I picked up from past projects is example mapping. It takes a ready-for-dev story and goes through the scenarios in BDD format in detail, as a team. For each scenario, the team break it up into a set of Given/When/Then combinations. Some scenarios may break up into a lot of smaller cases.
I like the approach for a number of reasons:
Recommended by LinkedIn
▪️ it's a highly collaborative practice - using a Miro board/whiteboard/etc. the entire team get stuck in. All team roles have useful different perspectives. With a collaborative whiteboard tool (pick your favourite) the process can go very quickly - everyone working the problem rather than one person typing and everyone else looking on.
▪️ it is very good at finding the edge cases that would otherwise slip through the cracks. Having everyone working together has frequently resulted in 'oh sh**, we didn't think of that' at a point where we can easily do something about it.
▪️ afterwards the devs know in detail what the acceptance criteria are.
▪️ the QAs also have a ready made set of integration/regression tests *right there*.
The one thing we don't do during example mapping, and generally don't expect to see in stories is *how* to solve the problem. That detail does not live in the stories, and is up to the devs (with support) to figure out when it comes time to work on a story. Obviously there are some implementation constraints required by the system which may need to be called out, but the detail of the solution shouldn't happen here. That requires a bit of discipline as us devs have a habit of jumping into solutions too early.
When teams get used to demanding and creating well defined stories, dev work becomes easier and faster. There are less problems with miscommunication or ambiguity; each story can be picked up and understood quickly, and there's less chance of disagreement about whether a story really has been completed adequately. It also becomes easier to figure out dependencies between stories and prioritisation so that the work giving the most value to a product get done first. Flow of work by the team is faster, and more fun :)
I always wonder about teams Donal, in the late 80's, early 90's; it became common for student engineers graduating from college and university; to do so having created wealth. Working as interns they'd created software that was extremely beneficial to the companies that hired them. It became a "thing". Engineers go to great depths in their work, so it was natural for them to include a minor in software programming. That minor made them wealthy, more importantly, smart wealthy. They didn't work in teams, for the most part; they either worked alone, or with a few friends who had a skill or two; that they lacked. I asked a good friend of mine how he was able to keep it altogether; he said "too many cooks spoil the broth", every encounter (meeting) with the customer is recorded (by video) so that every interpretation is matched with an outcome that's agreed on. When I walk into companies nowadays, and see rows upon rows of software engineers and other "teams"; I think back to the last paragraph and the phrase "Chinese Whispers" hits me like a cold shower. In my experience getting a team to gel, is a rare occurrence. I've witnessed it only a few times in my whole career, thus far :}