Slicing and Dicing

If you have sliced stories for your Backlogs you may have had some questions arise. I am going to discuss two of the questions that I wrestled with when I began my Scrum Master career. To motivate this discussion, consider that we are given a story, P, that the team sizes and then determines that this story cannot be completed in a single sprint. Let’s say the story is estimated at 13 story points (SPs) and 8 SPs is the largest that fits into a single sprint for them. So, the team meets and deconstructs story P into four substories: S1, S2, S3, and S4.

Sizing and Adding

The first stumble this team experiences occurs when they size the four substories. The sizes they determine are S1 (3SPs), S2 (5SPs), and S3 (5SPs).  At this point the team pauses. They have sized three of the four substories and the aggregate size is already at 13. How can this be correct? All four substories should add up to the size of 13 SPs for the parent story, correct?

No, not correct.

The sum of the substory SPs does not, and usually will not, match the size of the parent story. One reason is: fixed effort versus variable effort. It is obvious that each substory describes only its own functionality. This is the variable effort, and we may have to use stubs or mock interfaces when we implement each substory, while the parent story should implement actual endpoints. These mocks add to the effort to complete the substories. The fixed effort might involve duplication across the substories of some code or test cases that would not be duplicated if we just implemented the parent story without slicing.

A second reason is: the parent sizing was probably incorrect. Perhaps the team did not analyze the parent story adequately, and they did not identify part of the work effort. Perhaps the story was not a 13, it was a 21 or higher.

The clarification of this “addition” puzzle is simple: size each substory without reference to the unsliced parent story, and do not try to make things “add up” to your original, parent sizing. After all, sizes are subjective and all are probably incorrect a bit, or a lot.

Abandoning the Parent

The second stumble is more subtle. In this scenario, after the substories are identified, created, defined with Acceptance Criteria, and sized—the parent story is set aside. This neglect is motivated by an assumption that the effort and functional coverage of all the substories completely maps onto the intended functional coverage of the parent. Therefore, if we successfully implement each substory, then we have automatically implemented the parent story.

Again, not correct.

Consider you are building an automobile. You divide the work into discrete areas to match what a substory would identify. You implement the brake system, the electrical system, the ignition system, the starting system, and so forth. You test each system thoroughly and demonstrate that every system works in isolation as specified.

But then you start to add the systems together. You test both the brake and electrical system and discover the Brake lamp on the dashboard is not illuminated when there is no brake fluid in the master cylinder reservoir. You test the ignition, starting, and electrical systems together, and to your dismay you kill your alternator because the attachment to the car battery was reversed.

The point is rather obvious: successfully deconstructing a story into substories does not guarantee successful reconstruction to the parent story until you actually prove the “whole” works as specified.

When we slice a parent story into substories, that parent is the “whole”, and we must treat that parent as the last story in our aggregate to be proven. In the automobile example, the parent story would include a “universal” function of a diagnostic check of each automobile subsystem when the ignition is turned to “On”. This multi-system power-on check cannot be part of any of the substories.

This proof of the parent may entail some additional functional development in the parent beyond what we develop in each substory, but it always mandates verification and validation (that is, testing) of that parent story’s total defined functionality – which will be beyond what we can prove from just the substories.

I love working with teams and executives to find effective solutions. Email me at gary@effectivescrummaster.com and let's explore how we might partner on your challenges.