Recently, I’ve debated with some colleagues about the order in which a software team should attack a lengthy set of must-have issues. Their take was that the team should attack the list in an order that most quickly reduces the total number of open issues. Mine is that you should do the hardest thing first.
Substitute “riskiest,” “scariest,” “most unknown,” “most important,” “most complex” for “hardest” and the discussion will be roughly the same.
In this post, I use two ubiquitous charts as illustrations: a burndown chart and a remaining issues chart.
Let’s suppose we have 26 issues, A through Z. Let’s assume all of these issues are above the “must have” line, so the normal first step of prioritizing the issues has been done for us, and is not up for debate. Let’s also assume that based on what the team knows before starting work, that each issue is the same number of story points – let’s say “2.” Without further analysis, the team could reasonably consume the issues in alphabetical order: ABCDEFGHIJKLMNOPQRSTUVWXYZ, with total effort remaining of 52. (2 points x 26 issues)
So, the team is sprinting along, and three of the four team members hit tasks F, H and K each of which turns out to be 5x “harder” than previously believed. Being a good team, they promptly update their burndown chart to reflect this new knowledge.Now, if the team took the opportunity to size up all 26 issues in the list at the start of the release, they would have had a better shot at sizing the work at 76 points instead of 52.Rewind time back to the beginning of the effort. Now that we know that there are 3 high effort issues, here’s the big debate: should we front-load the release with them, or save them until later? If we save the big issues for later, then from a “remaining issues” perspective, we’re making great progress at the beginning. However, from an effort and risk perspective, we’re procrastinating. Procrastination breeds stress.Contrast this with front-loading the release with the most difficult issues. In my experience, when a team says something is “big,” they tend to underestimate just how big it really is. However, by front-loading the big, difficult issues, that uncertainty is diffused most quickly, and at the point in the project when you have the most amount of time to deal with it.John Sonmez makes several points about the virtues of tackling hard problems last. I particularly disagree with his assertion that doing the hard things first is “fear driven development.” I prefer to think of it as “risk mitigating development.” Having said this, reality is somewhere between extremes. I can see deferring hard problems if there is some chance that the product owner will have a change of heart late in the project and de-prioritize them.
The takeaways are these:
- Your team should look for opportunities to size up issues as early as possible.
- Leverage the metrics and charts that accurately convey the team’s true velocity and remaining work.
- Saving hard work for later plays into the “last responsible moment” tenant of many agile teams, but can breed stress and wreak havoc on risk mitigation.