What does it mean to frame a user story? This often can be a difficult process to explain. Try to use this technique when you are teaching planning poker and writing user stories.
As we work through the process of doing planning poker to create amazing estimates (based on: knowledge, uncertainty, volume, and complexity) we learn more about the quality of the user story being presented. Newly formed teams (forming, storming) often find that their stories can be difficult to describe and gain consensus (on the estimate) and shared understanding. As a coach this is when I walk to the board and draw the infamous U.A.B. (unknown amorphous blob). Watch the video for the description of the technique.YMMV, but I find it useful for describing part of the intent behind user story telling. Learn more here.
If you read it and found some value. Please share it:
Reblogged with permission from Jem D'jelal, the original author of
this content, as a contributor to blogagility.com. Originally published
on LinkedIn October 5, 2016.
“In Rugby, we have one rule to rule all rules” said Dan.
“To create a fun, fair & free flowing game”.
“If the ref kept stopping the game for every little rule broken, the game would not flow”.
God did this statement resonate with me!
How many ScrumMasters are so focused on the “rules” they do not allow people to play, to get into the flow of Scrum, to break the rules & to understand the “why” of how the game is played?
Sometimes it feels like parts of our community is no different to the ugly side of religion with people shouting “Scrumbut” at anyone who dares to to explore Scrum in a way that goes against one single, little rule.
I’m a recovering Scrum Jihadist, I can talk for myself at least. (Another blog maybe?)
This discussion was a result of an fascinating exercise in a Tobias Mayer workshop (if he’s running the #thoughtcitizen class you’ll have more light bulb moments then Oxford street at Christmas – trust me).
“We’re looking at the law of the land vs the spirit of the law…”
This perplexed me a little but after some digestion I got it.
For example, a law of the land in the UK is that if a vicious dogs bites you, it would be put down, but if you’re bitten by a puppy ….you get the idea. The law doesn’t have to be followed to the letter.
A definition of the law of the land vs the spirit of the law:
“When one obeys the letter of the law but not the spirit, one is obeying the literal interpretation of the words (the “letter”) of the law, but not necessarily the intent of those who wrote the law”
What I see here is the “doing” vs “being” problem.
It’s also a big Scrum problem.
How many of us shout “Scrumbut! Scrumbut!” & although are sticking to the law of the land – we’re missing the bigger picture. We’re missing the spirit of the law.
If we are to stop the game at every single inevitable rule broken (as will happen with new teams) – are we impeding their learning by not letting the game flow?
Maybe that is the difference between a good ScrumMaster & a great ScrumMaster?
A good ScrumMaster will help the team follow the rules of the guide.
A great ScrumMaster will know when to break the rules to keep the game flowing.
Geoff Watts eat your heart out.
Are we robotically following practices or are we trying to convey the essence of Scrum.
Letting people play the game of Scrum – even with the rules broken at time – allows people to learn.
For change to be lasting, it’s got to come from with in.
Experiencing failure for yourself is a powerful experience.
Being focused on rules dogmatically without thinking of that human or team learning -doesn’t help create lasting change.
“Changing to Scrum is successful when the Scrum teams themselves create the necessary changes and therefore are really committed and feel accountable for the changes.”
There are many things a team using Scrum could get wrong.
Should we all just police teams to focus on the rules of the Scrum guide whilst missing out on the essence?
Rule following “doing” is very different to operating through a mindset “being”.
One rule to rule all rules
It’s there in the guide, I just think we want to zoom into the practices as they tell us what to do.
It’s natural to look for “the answers”.
But something which is heavily influenced by complex adaptive systems, understands there are no black & white answers in matters of complexity – there are patterns & things to try but no one size fits all.
Which is why empiricism is what we need to remember out of all of the rules.
That one rule to rule all rules is the DNA of scrum.
Scrum is founded on empiricism.
The pillars of empiricism are transparency, inspection & adaption.
This, in short is known to us as “inspect & adapt”.
If the very thing that makes Scrum is the above, then is that not the one rule to rule all rules?
If the team, business or organisation are doing something which breaks a rule – before you stop the game & pull people up for breaking the rules….stop.
Ask yourself, are we still inspecting & adapting? Should I let the game continue, let the guys experience it for themselves?
I have broken the rules & continue to do so – my aim is to not to help the team “do” perfect Scrum but to work towards “being” Scrum.
Sporting metaphors rarely resonate with me, but Dans articulation flicked on a switch.
I’ll leave you with his words.
“The referee has the right to let the game flow or stop the game at every single little rule broken. That doesn’t let the game flow”
“We want a fair, fun, free flowing game”.
I can imagine more learning can take place when the game is played rather than stopped every single second.
If you’re interested in getting a few “light bulb” moments relevant to “agile” I’d make use of Tobias Mayer’s courses. #thoughtcitizen
If you read it and found some value. Please share it: