Product Owner essentials: Writing a compelling product backlog item (with ChatGPT aid)
Last night, I was thinking about user stories, user personas, and AI (Machine Learning). When I awoke the next morning, I called up ChatGPT and tried out a few things. This Large Language Model is trained on writing the standardized User Story… along with detailed Acceptance Criteria. I even got a ticket title! 😰
ChatGPT also wrote a decent User Persona:
A story is critical to describe The What to a developer who isn’t acquainted with a problem, a concept, a focus. I’ve been writing User Stories long before ChatGPT and LLMs existed — As a Scrum Product Owner, it’s enjoyable to channel a user’s problem into a story. I don’t need ChatGPT, but it’s there on my utility belt if I want it. I could see a junior PO getting over writer’s block by using this tool (or other tools) for inspiration.
As a…
I want to…
so that…
Just one sentence in active voice, and to-the-point. The three pieces to the formula are essential. The “so that” is the hardest to write, but it’s the most important piece as it describes the Why.
My PBIs also include a paragraph of Reasoning. It gives the reader additional context on the business value. Plus, I provide the reader more info on “how did we get here?” when dealing with legacy idiosyncrasy or bad UX. This can be done so much easier by a human armed with rationale.
But, does a Dev actually read my user story?
During a weekly backlog refinement, PBIs are introduced to a Scrum team. Without someone reciting the PBI for them, I assess that a typical software developer reads in this order of importance:
To a developer, Designs and Dev Notes are the pathway to getting work done. My assumption here is that they don’t need a User Story, especially if they know the PBI’s purpose from refinement meeting.
And I’ve always felt odd reciting my story aloud. It seems too formal. The refinement session typically skips the story recitation for a more casual overview of the PBI problem/purpose.
So, why am I writing a user story?
I’m writing user stories for the wrong audience.
Jeff Gothelf wrote in 2019 about user stories:
“[User stories] must be compelling. They need to take the reader on a journey in a way that is meaningful to them. It has to make them want to care about your idea.”
So, user stories are for more than just developers. A story should be able to used throughout an organization, with anyone including an executive to a QA Engineer.
In Jeff G’s book, Lean UX, a User Story is combined with reasoning in a “storytelling framework”:
“We believe that [building this feature] [for these people]
will achieve [this outcome].
We will know we’re successful when we see [this signal from users].”
Cool, that seems to be compatible with ChatGPT:
Jeff’s blog gives an example of “specific storytelling” for a login opportunity:
“Authentication failures have increased by 73% in the last 6 months. This has reduced active users in the product by 52% on a daily basis which costs the company close to $1MM per day.
“From customer interviews and analytics reports we know that 90% of authentication dropoff happens at the password field. If we can reduce this to 10% we get close to $800k of that daily revenue back.
“We are considering solving this by removing the password field completely and texting/emailing users one time passwords each time they sign in. Our early low-fidelity prototyping of this idea returned nearly 100% success rates.”
Any reader would be coerced to prioritize that issue. It rationalizes value in a way one sentence can’t. And, it’s a script that can be used with stakeholders, clients, execs, etc.
The drawback with is that there is prep work. “You cannot wing this”. There are lots of numbers that have to be gathered and analyzed. This is a big story. My PBIs (and User Stories) are usually very small by design — they provide incremental value to the user.
How do I incorporate this “specific storytelling” style into my repertoire?
ChatGPT simply can’t perform this function without knowing business secrets. Letting AI analyze proprietary data is a solution, but that could take your organization years to prioritize. Perhaps you need a story about that!
How about letting a Dev help write the story?
Get some help. Devs are usually experts at querying data. Let them know you’re wanting to address a problem, but you don’t know if there’s a compelling reason to do so. Usually a Dev will jump at the chance at this — you’ll have the raw materials to plug in to your template. Of course, get permission from Engineering Management and the Product team. Transparency is good.
I’d still suggest a one-sentence overview of the PBI. I’ve found that this conversational form of story happens organically when a Product Manager is talking to an audience about a roadmap. Having both a standard story and a detailed story (or reasoning) in your PBI won’t harm anyone!
