Imagine you work for a company that produces a videoconferencing system. You’ve done pretty well with it, but you’re middle of the pack of competition. Then there’s a worldwide pandemic, and the market for videoconference software explodes. There’s a silver lining in this terrible event. A rising tide lifts all boats, right?
Maybe not, if the competition has more of what the customers want. It’s critical to remain a viable choice in the eyes of customers.
A friend asked for suggestions on a metric for backlog grooming. I’ve never written down these numbers, but this is the metric I use in my head.
I frequently hear or read people suggesting using User Stories for relatively long-range planning. Sometimes they mean something as short as a release in a few months. Sometimes they’re talking about multiple releases over a year or two. In all of these cases, they’re talking about breaking down the work to be done into small slices so that they can better measure it’s perceived size for predicting the future.
What are the implications for doing this? Read More
This week, Chris Matts tweeted, “Contemplating whether GIVEN-WHEN-THEN is back to front. The system should do <outcome> WHEN <event> PROVIDED <
stimulus context>… Hmmm.” Let’s try an example. “Given I have $500 in my account, when I withdraw $50 then I have $450 in my account” becomes “The system should show $450 in my account when I withdraw $50 provided I had $500 in my account before.” It doesn’t exactly roll off the tongue, does it? Putting the result first makes the sentence both more complex and more passive. Yet I can understand the impulse that triggered this tweet. Read More
Also while in Las Vegas for the ADP/West Conference, Bob Payne and I sat in the Agile Philanthropy booth and recorded a podcast on Acceptance Test Driven Development and the 3 Amigos. This is the latest in a series of Tips and Advice podcasts that Bob and I have done.
In my previous post, Avoiding Iteration Zero, I suggested starting with “the one obvious thing that needs to be done? (Hint: it’s not ‘login.’)” As Jon Kern has recently mentioned, this same topic has come up elsewhere. I was also in that list discussion.
Jon is, of course, right in a narrow sense. You can start with login, if you want. You can also start with an Iteration Zero. (Or, an Iteration Minus One, as I’ve seen one organization do when their list of pre-planning outgrew one iteration.) I’ve observed that you can generally get better software, faster if you start somewhere else.
There are some very good reasons for this. Read More
I’ve written about User Stories before and made available a handout that includes a page on splitting stories that, in addition to listing some splitting heuristics, includes several links to several lists of techniques for splitting stories.
What it doesn’t include is an even simpler way to split stories–the simplest way I’ve found yet. Read More
Since learning about them some nine years ago, I’ve found User Stories to be much handier for expressing what the system should do than the monolithic requirements documents I dealt with in the past. User Stories have a number of advantages:
- They can easily be shuffled into a different order.
- You generally know (by the acceptance criteria) whether or not they’re done.
- They don’t contain a lot of duplicated or contradictory detail.
- The detail gets elaborated when it’s needed (rather than a long time prior, letting the details get out-of-date and/or forgotten).
I’ve created a two-page handout on writing and splitting User Stories. I’m publishing it here in case it helps others. And I would welcome any feedback on it.