SAFe = Scrum Squared?

In software development, first there was waterfall, then came Agile, and now we have SAFe but the deadlines have always been missed and will be. The only thing we can control is by how much. But even if it is a given that deadlines will be missed, we can find a solution in a saying by Confucius in the article header, which points us toward better task creation. 

I have been a scrummaster for several years and until recently worked under Agile/Scrum method. The basic premise of scrum was to break down big requirements into smaller “stories” that can be implemented in two-week or four-week “sprints.” A story was further broken down into “tasks.” While there were suggestions made toward breaking down the associated tasks, nothing was recommended in that regard.

At least the way I was taught SAFe, I gathered the suggestion on smaller task size became a strong recommendation* and my team decided to try it. This is the reason I dub SAFe as Scrum-Squared, that is we break down requirements into stories and then do the “breaking down” again and break stories with the same zeal into 6-hr tasks.

In SAFe, we recursively break down requirements into stories and then do the “breaking down” again and break stories with the same zeal into 6-hr tasks. This is the reason I dub SAFe as Scrum-Squared.

Be prepared for a lot of pushback during initial adoption but if you stand firm, one of the developers will break down their tasks in 6-hr increments. Foot in the door! A quick check of stories from the past sprints (ok ok iterations!) highlighted the under-pointing of effort. I could see that for an eight point story, that should ideally take 48 hours, the actual total of work to be done was 60 hours!

When any developer estimates a task to be 16 hours, it can be 12 to 20 (a variation of 8 hours). But when they are forced to think in terms of 6-hr or less, they are forced to reduce the variability. With three tasks of 6 hours, there will be less variability than with one 18 hour task.

Then as if planets were aligning, I came across a TEDx talk by Stephen Duneier (How to Achieve Your Most Ambitious Goals by Stephen Duneier), which confirmed my belief about the validity of smaller tasks. The first one minute and 15 seconds of this talk should give you the gist. Assuming one point to be six hours of work, a five-pointer should take a total of 30 hours of work, but upon analyzing past stories I found a total of 40 hours- meaning eight points. Lightbulb! The answer to “How could we have missed the mark on such a small story?” was staring me in the face.

I conducted a quick experiment with my team. We first pointed the stories at a high level and then went on to ask “what are the 6-hr increments that we can break this story into.” Almost always our initial estimates were on the lower side. For example, making a UI change was initially pointed as a two-pointer. Upon asking what 6-hr tasks this constituted, we unearthed a complexity in testing and need for documentation that increased the effort by 12 hours leading to the story really being a five-pointer: meaning our initial effort was under pointed by three points. Finally all the under-pointing accumulates and the result is a missed deadline.

As I said earlier, deadlines will still be missed but by breaking down tasks (Scrum-Squared!) we may be able to reduce the magnitude by which we miss deadlines. Astute observers might point out that the code review and unit testing might happen in parallel and I agree but in my view the basic premise- breaking down tasks into smaller chunks leads to better estimation, still holds true. In a recent talk about making DEI work, I heard a suggestion to not make DEI a moment rather make it a culture. I think the same applies to making SAFe work. Make SAFe a team culture, not a moment by repeatedly breaking down stories into 6-hr tasks until it becomes second nature.

Comments on improving the approach of breaking down tasks into 6-hr increments are welcome.

* While breaking stories into tasks is fairly common, it is optional and not mandated in SAFe. Iteration Planning - Scaled Agile Framework

I would like to thank Nisarg Shah for sharing with me a work breakdown sheet that helped cement my vague idea about smaller tasks. I would like to thank Mary Thorn for valuable discussions about Scrum and SAFe.

Disclaimer: I am using the terms SAFe and Agile/Scrum somewhat loosely. These are my own views.