User Stories have become the standard way Agile teams capture requirements and were introduced almost 20 years ago as a part of XP (Extreme Programming).
👷 Building features with the goal of satisfying stakeholders is not good 👎 enough anymore.
We should be focused on satisfying the customer.
🤥 THE BIGGEST LIE IN PRODUCT DEVELOPMENT
The lie product departments and stakeholders tell themselves is that they know everything up front.
These decisions aren’t validated ❌✅ until they are implemented and deployed into production.
This is a very long and expensive 🤑 feedback loop.
Stats show that more than half of the features we build are rarely used. 🤷
Maybe we should change from thinking about “requirements” to thinking about defining “hypotheses?”
THE RELATIONSHIP BETWEEN OKR’S AND BUSINESS OBJECTIVES 🎯
We still need to have some clear goal 🎯 or target.
I think we could borrow from the OKR (Objectives and Key Results) world: defining the business “objective”!
Then brainstorm 🧠🌪️ to have hypotheses.
And then examine 🔎 the risk and impact of these assumptions to prioritize which hypothesis to prove first.
AGILE TEAMS AND HYPOTHESIS CREATION
Most of the teams are still focused mostly on how to best “deliver.”
Too often we still wait until we have a full solution before we deploy to production.
What if we could run small “experiments” to prove our hypothesis or validate our assumptions without having to build the whole solution?
CONCLUSION
I am just proposing we use the OKR format/template to describe product objectives and success criteria.
If they can tie into overall company OKRs great, but not required.
#scrum #okr
Full article👉 https://agilevelocity.com/user-story-needs-remodel-heres/
Udemy👉 https://www.udemy.com/course/professional-scrum-developer-certification-prep-200-question/?referralCode=49CBC321F20A7E381F7C