Experiment and Believe!
So many times while using Agile, we get convinced with popular notions only to find that they don’t provide much value. Perhaps the people who made those notions popular were meaning something else?
It happened to me years ago! One such notion I believed for years was, that, if it’s a small story, it’s a good story!
I broke down work and large stories (without much thought), into smaller ones so they can fit in the Sprint. My teams worked on them, finished quite a few of them as well and we cherished the burndowns, predictability and velocity
See also;
Tackling Unfinished Stories at the end of a Sprint
Then, one day I met Jeff Patton, who asked me
[JP] Amit, I see you’re doing great work finishing so many stories. But, how is your team providing value?
[Me] Value??, what do you mean? We deliver lots of points every Sprint, have high predictability and look at the nearly perfect burndown charts
[JP] Amit, but this does not prove you are delivering high value
[Me] Confused? What do you mean?
[JP] Let me show you
(JP Takes out a $1 bill, rips it into several pieces and hands me approximately 1/4th random pieces of the ripped bill)
[JP] Now, tell me. Is that Twenty Five cents (1/4th of $1)?
[Amit] Well, er…. No!
[JP] Do you see, just breaking work into smaller stories to fit a Sprint isn’t providing value
[Amit] Yeah, makes sense
[JP] What would be a better approach?
[Amit] I got it. I took out loose change. A couple of quarters, few – pennies, dimes and nickels – adding up to $1
[JP with a smile] Exactly. There’s always a way to look at work and breaking it into ways that provide value. If not each, then a few of them should be valuable
Since that time, I learnt to experiment and believe
The INVEST acronym for good user stories goes this way:
I = Independent
N = Negotiable
V = Valuable
E = Estimable
S = Small ???
T = Testable
Mike Cohn has also redefined “S” from being “small” to “succinctly small” , which means “brief and clearly expressed” and I believe “clearly expressed” has to do with “valuable”
What experiments have you done on busting Agile myths and finding out deeper meaning behind popular notions?
What have you learnt from them?
