People have struggled with requirements for so long and so ubiquitously, many people have just accepted that it’s natural:
- to misunderstand requirements
- to have poor acceptance criteria
- to create rework when requirements change
The reaity is otherwise. Some people are learning the value of the Jobs to be Done approach – and it is an integral part of my Sonesis System. As part of it I use ‘objective stories’ which are easy to adopt as a starting point.
Converting from User Stories to Objective Stories is useful because it shifts our attention from what someone has asked us to build to what they are actually trying to accomplish. User Stories were an important advance because they brought the user and their intended benefit into the conversation, but they can still allow teams to gravitate toward requested features and actions. Objective Stories make several critical distinctions explicit: the relevant stakeholders, the situation they are in, the objective being pursued, the capability needed at the least implementation-specific level we currently know, what subsequent outcomes it enables, how we will know it succeeded, and what constraints must be respected. The goal isn’t to capture more requirements; it’s to make the distinctions needed to design the right capability visible earlier and more consistently. That can reveal alternatives, missing stakeholders, unnecessary work, and connections across the workflow that a feature-oriented conversation can easily miss.
Learn more in this post From User Stories to Objective Stories.
Go here to register and get the zoom link to attend (free).