(or, Why Frequency belongs in Problem Stories )
Well, golly, it’s that time of year: Daylight Savings Time. I’m with the many who have proposed getting rid of “spring forward and fall back.”
Changing the clocks twice a year is inconvenient when you have only one clock—as people did when Daylight Savings Time was invented. But when you have one in every room plus every car, it’s agony. [I know, I know: first world problems.]
Why? Because every clock has different interface.
My office clock is supposed to change automatically. Sometimes it does.
My microwave and oven have clocks. Different interfaces. Microwave is press CLOCK, enter the time, press CLOCK. The oven is CLOCK, enter the time, START.
And the cars! In one car, I have to change the clock for the dashboard AND for the entertainment hub. For that, I need to check the documentation. In another car, you change the time from the entertainment hub but must remember to press SETUP and not CLOCK to get started.
All of these suffer from the problem of frequency. That is, infrequency. Your personal “muscle memory” learns to work around poor interfaces that you use daily. But since we only reset the clocks twice a year, we never get good at it. We never develop that learned behavior.
Add Frequency to your Problem Stories
[I prefer to call them Problem Stories rather than “user stories” or “epics.” It’s a reminder that product managers should be focused on problems.]
When designing a solution, take frequency into account. I only file taxes once a year; I only change my clocks twice a year; I only make waffles a few times a year at most. Every time I do these infrequent tasks, I’m a novice.
And the same is true for professional development. Reflect on a recent webinar and the number of times you said, “Oh, that’s a great idea,” only to forget it by the time the session was over. If you don’t use it this week, you lose it.
How often you do refine and prioritize your stories? Probably more often than you create a business canvas or a strategic roadmap.
Whether technical interfaces or methodologies, use it or lose it. If it’s done infrequently, make sure you mandate clear documentation in the acceptance criteria of your problem story.
