Is Cherry-Picking Bad?

The long Memorial Day weekend was nice, and the weather is finally decent in Wisconsin. The grass is growing faster than I can mow it, and the birds are thick. Last week, the woodcocks were peenting most of the night, and the owl calls have begun. The oaks are finally leafed out, and the wild geraniums are blooming everywhere. All this means that I am distracted, as you can probably tell by the lack of posts this past week! It’s not that I’m not working – it’s just that I haven’t had a really high concentration level. This week, it’s back to business – the birds are tuned out and I am catching up on my reading.

Last week, I found myself cherry-picking from my to do list. I finished quite a few things…light-weight items that didn’t require a lot of concentration. I travel a lot, and find it most beneficial to do these low-concentration tasks for my first few days back in the office. My mind needs to rest and re-acclimate before I can focus.

I can organize my workload appropriately, so that I can cherry-pick the easier stuff when my mind isn’t prepared to focus. I can get away with that for a week or so, max. After that, I have to go back to high-concentration items, because the light-weight tasks are done for now and the meatier items need to be addressed.

One of the best parts of my job is that I get to talk with a lot of Product Managers. One common complaint is that their agile development team is cherry-picking items during the sprint. We turn over requirements, and development creates a sprint from the highest priority group. Our developers are often optimistic about schedules. During the sprint, some things don’t get done. I often hear a suspicion in these teams – suspicion that the development team works on the items that seem most fun, and don’t make it to the “other” items. That’s like if I cherry-pick from my to do list, and never quite make it to the higher-concentration items.

This behavior during an individual sprint does not bother me. In fact, I don’t really care how the development team’s work is organized – as long as they are addressing requirements in descending priority order. I understand that sometimes, we overestimate capacity and don’t complete everything that was planned for the sprint. All I ask is that the next sprint begins with the leftover tasks, so that they continue working in descending priority order.

Our teams should finish ALL the items planned for one sprint, before moving on to the next group of requirements. If we’ve done our jobs as product managers, the current iteration includes the highest priority requirements. If the team gets to the end of the sprint and they haven’t finished all the work, the next sprint should begin with the leftover items. Cherry picking is OK for a little while, but eventually we have to go back and finish the stuff we skipped. It’s a good rule for personal organization, and it’s crucial when developing commercial software in an agile world.