Abusing User Stories will stall your agile transformation. Don’t make this mistake!
One of the most common mistakes in trying to increase agility in an organisation is the misuse of User Stories. Here’s what happens...
Having realised that agility is about organisational learning, not ceremonies, we try to learn as much as we can about the success of your products in the shortest time possible. So, we set about designing a new delivery system, one that creates small deliveries of value for the user, reduces risk and allows you to learn and repeat.
Currently, it takes us 6 months to get an idea in the customer's hands, 6 months! You can only learn two things per year! It’s no wonder that you’ve been jamming the cycles full of all the work you can think of, losing track of what was important, not learning much at all.
The User Story technique helps us to learn something from each of our efforts. But we've made the work as simple as we can, and it still takes 6 months to deliver. What do we do?
Options:
- Break it down into tech tasks, and track them. Honest, but that's Old Ways of Working.
- Go back and try to make it simpler again, challenge each step in the value stream. Difficult.
- Break it down into tech tasks but write them as if they’re User Stories. Old Ways of working dressed as New.
Option 3 is often taken, but it’s the WRONG choice...
As a database admin (not a user) I need a query plan written so that I can have ...
As the global address service (not a user) I need my addresses to be ...
As a review team (not a user) I want...
As the integration bus layer (not a user) I want a service that...
As a product owner (not a user) I....
Seem familiar? These people aren’t users, we will not learn anything about our product by completing these, we won’t reduce risk or deliver value.
Worse though is that by doing this the dialogue with the actual user stops and this is the end of your quest for agility.
You might object:
“But I’m still gaining in transparency, making people accountable, every squad has something to do, and I get updates every 2 weeks...”
But for this, you have paid a heavy price, because you are no longer trying to speed up your learning for your organisation.
Don’t abuse the User Story technique.
Instead, keep the dialogue open with the user, identity what small steps allow the user to get started, put your best people and effort into the MVP negotiation.
Then, challenge the value-add of every step in your value steam. Carefully consider appropriate definitions of “quality”.
Above all, be honest about where you are at in your journey, big change takes time and is worthwhile to reach true agility in organisations.
Experienced Human Resources & Operational Excellence professional with proven business management, project delivery and consulting capability.
6 年Thanks Graeme for the article. Peter Grzybowski, you may want to have a look at this
I have overseen operational support for delivered systems and seen a significant drop of function that is required by support to easily diagnose issues. They are a different persona to the regular user set. What is your suggestion to help ensure that support needs are articulated correctly?