With old houses, there is always a long laundry list of things that need upkeep. I am in a situation now where I am doing some house-fixing and that list I mentioned reveals more of it’s lovely self all the time.
This past weekend, I had two things I decided last week that I was going to do. I was going to fix the front steps so nobody breaks their legs that I do not want to break their legs and I was going to redo the gutters and replace them totally on the garage.
What I did not know is that the garage roof needed to be replaced. The steps got done, but I wasted money and time as well as life and limb fixing something that was dependant on something else (if you look at it one way) and less important than something else (if you look at it a little differently).
This is why I like FFAs, and why I might just from time to time modify Scrum to incorporate an FFA. Some will argue it is adding complexity. I would counter and say it is removing ambiguity. I can pick my first sprint backlog from something all too similar to Indian Poker (that’s what we called it as kids – it is probably non-PC now?) or I can get as much information as possible about not only the time involved, but the risk and the value as well. I had to fix the steps because Mr. Knucklehead would sue if he fell, but the gutter could have been placed in a larger context that would only be revealed when looking from a 20,000 foot view.
A story point as “how *big* is this item?” is fine, but we really do not want to limit our dimensions of measurement to size.
Thanks,
J
BTW – the aforementioned never happened. I just cannot talk about the real life example due to confidentiality agreements, etc. Besides, I am not feeling well and articulating the real example seems far too tedious at the moment. I just want to go back to bed.