The Fall of the Omniscient Business Analyst
If you have been involved in any development, you will have met the issue of not drawing back the curtains. Unless the organization is mature, a requirement is often gathered as a functional and technical description. If the person posing the requirements was an omniscient business analyst, there would be some merit in staying on the technical surface level of posing a requirement, as all accounts of the business, process, and user-experience impact would have been taken into consideration.
Even then, we are not sure that our god-like business analyst will be with us tomorrow, and with that person leaving, so would all of our contextual knowledge for the technical requirement.
The Rise of the User Story
Behold, the requirements, are saved by our mighty user story format:
As a [consultant], I want [to become better at employing user stories] so that [my client experiences more value]
Above, you have the basic structure for a user story. As a [persona], I want [something] so that [some value is achieved]
To read more about the user story format, please look at this old and dusty article I made in 2017.
In essence, the User Story takes the focus away from what we need to who, what, and why when gathering requirements for new features. The additional dimensions to the requirement help us in various ways:
- We understand the user type/persona that needs a feature so we can tailor a solution to known pain points, goals, and jobs to do.
- We understand what they are looking for, and more importantly
- We understand why they are looking for this feature, implicitly pinpointing the acceptance criteria of the new feature (e.g., when the customer is happy with the new feature)
- Knowing the who and the why in the context of what allows for the design of a solution that can create a modular, scalable, more UX-friendly, and technologically leading practice-compliant feature development.
To read more on the creation of Personas, see this ServiceNow® Quick Answer.
Not All User Stories were Born Equal
Please look at the example scenario below for the qualification of user stories.
- A design Authority Board receives a requirement in a user story format.
- "As a developer, I need a blue button that creates a notification for the on-call incident manager."
- This should be sent back because
- The developer might need to add the functionality, though the developer is not the user type/persona supported by the feature
- The user story should not specify a solution like a button and a notification; it should set a need.
- The user story should always include a value statement or the why, which has been skipped above. Why is the persona in need of notifying the on-call incident manager?
Instead, it should look something like this:
- "As a service desk agent, I need to notify my manager of critical incidents related to customer critical network gear to allow the on-call incident manager to oversee the resolution and conduct customer communication according to our standards."
Now we know the who: the service desk agent.
The need: escalation of critical incidents to management
The why: critical network infrastructure of the customer is a priority and needs to be managed outside the normal incident priorities and processes.
Even the Best User Story is Not Good Enough
Say you have matured your governance processes, ensuring that User Stories consistently follow a healthy standard that references the feature request's relevant dimensions (who, what, why).
First – good job, many struggles here.
Now better news: you can do better.
Consider a year from now, and you will have a lot of beautifully written user stories. You'll be able to refer to them when you need to understand the impact of making a change or revert to the baseline for a configuration or customization. This is helpful. Though, how do you know if you are looking at the full scope of the user stories related to a solution you are interested in making a change to, and - even more complex – how can you ensure that user stories of interfacing applications and processes are considered when evaluating if you should pursue the implementation of a feature request?
Besides knowing why something was implemented, as described in the user story, how will you understand what implemented features underpin different strategic objectives of the broader organization?
That was a set of very rhetorical questions, as you will need help determining the relationships and combined objectives.
Putting the Story into User Story
Without relationships between the User Stories and their context, you will be left with a sea of fragmented feature documentation.
Consider it a CMDB where you have all of the CIs. However, it would be best if you were aware of what business services the individual CI underpins or even how the CIs depend on each other. Would you feel good about changing a CI in that infrastructure without this knowledge?
What would a paragraph in Harry Potter be without its chronological relation to paragraphs in the chapter, and what would the chapter be without its chronological relation to other chapters?
Imagine reading a book like that, just a lot of mini-stories dependent on each other, though in complete disarray in your leatherbound book.
You would have limited ability to understand our dear wizard's character journey and development and how each of the paragraphs underpins his ambitions and desires as a confused teenager with a wand
(by the way, anything you read into that sentence is on you).
I'm making an analogy for your User Stories without a context. Though they might be written as pristine as the best Voldemort plot-and-wand-twisting paragraph, they will not tell the whole story.
User Journey – the chapter of the book
A user Journey will allow you to structure the User Stories chronologically and relatedly. You can then read and tell the story while understanding what a change or addition of a step would mean for the persona experiencing the journey.
To read more on the creation of User Journeys, see this ServiceNow® Quick Answer.
Picking the Correct User Stories to Implement
With the user journey, we are switching from a fragmented view of the solution to a holistic one.
We are going from understanding each implemented feature as its own island to understanding them as a part of a larger story.
We enable ourselves to qualify the new user story in relation to the user stories referenced in the user journey, as well as interfacing user journeys for a much more accurate insight into implementation impact.
Going a step beyond this, you could consider mapping your user journeys (or user stories if/when relevant) to the strategic objectives of the broader organization.
This would empower your demand board to discern new requirements between those underpinning strategic objectives, those meant to keep the lights on, and those originating from a less critical source.
1 Comment
