Note
The following was written using terminology based on the Scaled Agile Framework. Some agilists (particularly from competing scaled approaches) compare SAFe to the Borg; however you feel about it, SAFe is has become a framework to contend with. The job of those of use working in the trenches is to make such frameworks useful to organizations that have decided to use them. While no method or framework is a silver bullet, some are useful once you learn them.
Executive Summary
In software development, breaking requirements or User Stories down into their smallest practical size is beneficial for development work. Having small, “atomic” stories supports good system design, builds collaboration, encourages good systems development habits, and enhances the ability to measure progress. Bulky, compound User Stories foster miscommunication, retard development, cause rework and waste, encourage difficult-to-maintain architecture, and spawn poor development team behaviors.
When discussing splitting, a distracting topic is whether to take partial credit for work done in a sprint, even though the story wasn’t completed. Opinions of industry leaders range from barely tolerant to hostile of this approach. If this is done to evaluate velocity for successive sprints, then it creates a minor clerical headache. In contract work situations, however, it encourages poor vendor behavior that becomes a major client headache. Our recommendation is to disallow in-sprint story splitting, and simply move unfinished work to the next sprint.
Developing the skills to decompose stories rapidly can be developed by training, but only can be mastered as Product Owners work with development teams. With practice, they will see how this process improves their communications with the developers and makes story acceptance easier.
Steps to break stories down to the atomic level may include the following (borrowed from the Scaled Agile Framework[1]):
1. Workflow steps – ensure each story represents a small, finite number of workflow steps
2. Business rule variations – each variant on a business rule may call for a separate story
3. Major effort – apply obvious splits, defer large difficult stories for possible splitting later
4. Simple/complex – look for the simple core of a story, add complexities in new, related stories
5. Variations in data – each variation may call for an additional, small slice of functionality
6. Data entry methods – seek the basic, valuable data entry method, split the rest into follow-on stories
7. Deferred system qualities – defer or split out non-functional system abilities into separate stories, if reasonable to do so
8. Operations (example: Create Read Update Delete, or CRUD) – consider each subset of functionality as a potential story
9. Use-case scenarios – does viewpoint analysis reveal additional functionality based on who or what interacts with the story’s core intended functionality?
10. Break-out spike - if still unsure, run a research spike
As product owners and developers become proficient creating lean and thorough Acceptance Criteria, their ability to break stories down to the atomic level will improve. Product owners tend to provide more impetus for breaking work into Features and stories; Developers naturally tend to understand and need atomic-level stories, and will provide more drive for decomposition efforts at that level.
The following pages provide additional details on this practice, as well as real-life examples of teams working towards atomic story definition.
[1] http://www.scaledagileframework.com/features-and-capabilities/
Introductory Concepts
User Stories and Requirements deal with two layers of attributes, sometimes called “the ilities” because most of them share that ending – as in “functionality,” “security,” “usability,” or “maintainability.” One layer deals with the system’s abilities other than functionality, which is where we use terms such as “recoverability” and “maintainability.” The other layer deals with the elaborated User Story itself, and includes such terms as “testability,” “clarity,” “stability,” “stable,” “design-free,” and “complete/ready.” A key attribute of a Story is whether it has been broken down to the smallest chunk of valuable functionality, which we here refer to as “atomic.”
“Atomic” User Stories
In about 400 B.C., the Greek philosopher Democritus formulated an idea that, if you had an infinitely thin knife, one could slice matter into smaller and smaller bits until a limit was reached. That limit, the smallest particle that can’t be physically separated, would be the atom (from the Greek “atomos” meaning “indivisible” or “uncuttable.”) Although today we know that an atom can be further divided into components (electronics, neutrons, protons), they are not stable, independent units of matter.
We use the atom as a simile for breaking work down into small, meaningful chunks. In Agile development work, we consider User Stories[1] to ideally lie at that ‘atomic’ level of detail -- the smallest demonstrable, working piece of useful functionality. The art of breaking down User Stories to the level where they can’t reasonably be broken down further can be referred to as “splitting,” “slicing,” “decomposition,” and other such terms.
The User Story statement and Description are the primary overarching definition of the story – the ‘atom’ overall. Like sub-atomic particles, there are sub-components within that User Story (normally called “tasks”), but they only have relevance as part of the User Story. Test cases, notes, interface identification, and other pieces are sub-components, much as neutrons, electrons, and protons are part of every atom.
The idea of Atomic stories matters [2] because many issues with application software development stem from taking on too much functionality at one time – complex molecules of work, if you will. Taking on too much at one time can result in large, convoluted code blocks that are difficult to maintain and navigate. It encourages poor coding practices such as excessive nested “ifs” and direct calls through successive blocks of code without using object oriented discipline [3].
Developing against compound stories complicates testing and debugging, making it difficult to determine which variable in the code, data store, or environment is responsible for how the software is behaving. Less obvious, but still critical, is the tendency for a single individual to become the sole keeper of a compound, complex requirement. This makes the code opaque to other developers, creating a development bottleneck and single point of failure. User Story decomposition to the atomic level helps manage these basic development risks.
[1] We concede that Technical Stories are necessary, but find that they often wind up being tasks under a User Story. In this paper, consider the term ‘User Story’ to also encompass Technical Stories.
[2] pun intended
[3] Sixty years after Edsger Dijkstra published his letter on the dangers of unstructured GoTo calls, spaghetti code continues to be slung -- partly due to poor User Story decomposition and poor coding standards.
The key Story splitting skill is determining when a User Story is at the smallest practical level of decomposition. One hint for this evaluation is to think like a developer who has to test her own code: if she is writing tests and test data that are normalized to make sure a single piece of functionality works, then the story may be at the atomic level. If those tests are evaluating many interconnecting dependencies within the story, then the story may be a candidate to break out into smaller stories.
As mentioned earlier, breaking down stories can encourage good developer behavior. Take, for example, a classic data entry screen with Create, Read, Update, and Delete (CRUD) functionalities. Many developers consider such a screen to be a single component, and approach it as if they are developing it as a unit. However, this example represents separate functionalities. The functionality to add data is slightly different from the functionality to edit, which is different from the functionality to delete. Competent developers will develop and unit test these elements separately; it’s just good practice. Developing and testing these entities separately reduces debugging time and promotes efficiency through compartmentalized and reusable code.
Atoms, as you know, are not all alike. For example, while a hydrogen atom contains only one proton, uranium has 92. During backlog grooming, we absolutely do not want stories with 92 pieces of sub-functionality; such stories should be considered dangerous -- radioactive -- and not allowed into the iteration[1]. Our ideal model resembles Hydrogen, the simplest atom with only one proton – our goal is to have only one piece of functionality in each User Story.
[1] Throughout this paper I use the term “iteration” and “sprint” interchangeably.
Vertical Slicing
If we took each component of a story (each particle of the atom) and stacked them vertically, they would represent combination of the technical and development components and activities necessary to have a piece of product completed, tested, accepted, packaged, and ready to place into production. There are many versions of what that stack would look contain; here is one:
Using the thin vertical slices[1] discipline, each unit of shippable product should contain most or all of these layers. Some items (such as data design and user experience design) may be implemented early, in a technical spike, but their outputs would be integrated into all relevant subsequent User and Technical Stories.
[1] The Atom visualization doesn’t work as well when we discuss “vertical slicing.” Our illustration looks like lasagna; Alistair Cockburn uses a carpaccio analogy, Gojko Adzic uses the “hamburger method.” Years of subsisting on high-carb food as software developers may explain why we gravitate to such similes.
Thin vertical slices is a difficult concept for some; we tend to think in broad, horizontal batches and specialties. Those big batches feel more efficient to us, despite over a century of assembly lines, concurrent engineering, and small team work demonstrating otherwise. Horizontal slices (batches) may be more efficient for creating niche components, but they hold up delivering the vertical slice of functionality (which is where the real value lies.)
For example, breaking out a broad “horizontal” slice such as User Experience into a separate Feature for the duration of the work has been proven to create bottlenecks. Some organizations amplify this error by creating segregated specialty teams, which increases over-specialization and bottlenecks.
Using the thin slicing concept addresses the common error of splitting along technical boundaries, which can result in “backend” versus “frontend” stories. Such stories may not be atomic, they could be too small, sub-atomic; often they are tasks, not stories. Sometimes a tech story will come into being because it isn’t clear how it works into a vertical slice of functionality. Don’t worry too much about this happening, just be sure to keep an eye on tech stories to make sure most of them eventually roll up into User Stories.
A common challenge in the “vertical slice” approach is how to manage testing. We tend to develop and manage tests as large batch activities late in the life cycle. This stems from several sources:
· Believing functional tests at the end of development can find all defects;
· Over-specialization of testing as a separate discipline from the Development team skills; and
· Using points and velocity quotas as a measure of success, which can pressure teams to downsize and delay testing.
But testing, like everything else, needs to be done in-sprint so that the Sprint Demo contains fully done product (‘Done-Done’ in eXtreme Programming lingo) that could be placed into production the moment the demo is over – or even before then. If testing has to happen after the story has been demonstrated, it indicates a dysfunction.
Thin vertical slicing aligns to DevOps, which grew from efforts make possible the “continuous deployment” model of eXtreme Programming. It involves a technical aspect of ensuring the development and test environments mirror Production, then promoting product into use “untouched by human hand” actions.
Just as important as this tool-focused side of DevOps, the human aspect involves a tight collaboration between key players from inception through successful operation of a piece of functionality. That tight collaboration applies to creating complete, thin vertical slices. Each small slice of valuable functionality has been created with the input of those who will support in Production, those who will use it in the Customer community, and all those involved in moving it through the deployment pipeline. This collaboration avoids having product considered complete, only to have a relevant stakeholder pop up at the last minute and say, “Wait, that can’t go into production! Why wasn’t I consulted about this part?”
Who Splits Stories?
The Product Owner (PO) and the Developers are primarily, jointly responsible for decomposing business needs progressively into stories. Leadership of story decomposition may shift as stories get more atomic, however; this dynamic is natural, almost subconscious, on self-organizing teams. The Product Owner is ultimately responsible for accepting the completed work, however, and so should always be sure that someone is taking the lead, and that Story splitting is getting done.
Product Owners will participate at all levels of splitting, but they typically have a less granular view of systems. Once Features have been defined, they may need prompting and questions from the Developers to help them understand why and how stories need additional breakout. The Product Owners’ strategic focus, balanced by the Developer’s deep technical focus, supports the progression from high level needs down to detailed technical slices, and subsequently aggregating back up during development to a working system that satisfies customer needs.
(Hopefully, this early work will involve challenging existing assumptions, since automating a bad system can just help counterproductive things happen more often and more expensively.)
During early decisions to automate a manual or mechanical process, the system sponsors and subject matter experts may already have a “tree structure” view of what the system should contain. This tree structure may be referred to as a Work Breakdown Structure[1], and is the foundation for progressive breakouts into Features and Stories. This decomposition continues all the way down to the task level. Other roles such as business analysts may provide support, but the POs are responsible for participating in this early breakout and for considering how to convey the system needs to the Development team once it is engaged. Most importantly, the POs are responsible for ensuring the Babacklog grooming takes place effectively for the duration of the system development effort.
When the developers are brought onto the program team available, their first task should be to engage quickly and closely with the system sponsors. They should evaluate whether initial functional decomposition or design ideas have created potential problems. Rarely, they will find that the sponsorship team has deep knowledge of existing systems, and will have already broken some needs out into atomic-sized stories. This can give teams a head start, but requires sifting through design assumptions being pushed to the development team.
Early engagement with the POs and other stakeholders give the developers understanding of what really is needed; they will continue to refine that understanding until the final build is shipped and development is considered complete. Ever-evolving understanding will enable the development team to proactively, energetically help refine the backlog.
[1] Microsoft Project has in the past has had the label “WBS” in the upper left corner of its Schedule view. MS-Project’s schedule is not a good example of a WBS, it is a better example of a Gantt chart.
Three Amigos
Agile blogger and coach George Dinwiddie first published a description of the “Three Amigos” approach to backlog grooming. His backlog grooming sessions as Nationwide Insurance involved, at a minimum, three roles: the product owner, the development lead, and the principal test designer. Mr. Dinwiddie later stated that those three roles are considered a minimum; others may be invited to any given grooming session to provide input.
http://blog.gdinwiddie.com/2009/06/17/if-you-dont-automate-acceptance-tests/
Energetic engagement is vital. Developers must not act passively, like bored fast food workers taking orders. They must elicit system needs from the product owners and subject matter experts, using various techniques to understand how a set of problems can be converted to testable, maintainable, reliable components. Some development teams employ business analysts to support elicitation and documentation of stories. This can be useful, but must not interfere with the evolution of the developers’ ability to perform elicitation.
The developers usually drive story decomposition down from the “pretty small” level to the “atomic” level. This is normal, since often the rationale for splitting at this level are technical. the ability to code discrete, useful units of product that meet the definition of “done.” The PO team validates these atomic stories as being useful pieces of the larger product, and validates the defined stories as being sufficiently defined to allow their review and acceptance.
In summary,
· The Product Owners and Subject Matter Experts are ultimately responsible for the stories, but need help as stories get more technically detailed.
· The developers provide technical skills to make breakdowns support coding, data design, environment setup, interface management, and other tasks. These skills support their ability to elicit and provide guidance.
· Business analysts (if they are present) help with elicitation and elaboration, but do not own responsibility for these activities.
Despite shifts in involvement throughout the life of a Story, no one may foist Story decomposition completely onto another role. It remains a collaborative effort.
