Here at TeraThink, we are currently building an internal application that will allow us to better track new business opportunities. Simultaneously, we are exposing more of our staff to agile and continuous integration/continuous deployment (CI/CD) principles. Among the many concepts we are trying to inculcate in our team is the “layer cake” user story.
The layer cake idea has been around for over a decade. However, I’ve found on nearly all agile engagements that I’ve been on, teams either discard this idea early in the project or completely ignore it from the outset. It is up to the triumvirate of the Product Owner, Scrum Master, and Business Analyst to ensure that the scrum team writes user stories in such a manner that the outcome of each story is working software that delivers tangible value to the end user.
What is a Layer Cake User Story?
To illustrate the idea of the layer cake user story, let’s return to the new business opportunity application mentioned above. One basic piece of functionality that end users need from the application is the ability to create a new opportunity. Opportunities determine for whom the work is for, for how much money, the nature of the work performed, the period of performance, etc.
There are multiple “layers” of work implied within this piece of functionality:
- User interface (UI) developers need to build out the UI. This will allow the user to fill out an online form with the above information and submit it
- Database experts need to either create a new data entity or modify an existing entity to persist the information provided
- Backend developers need to write code to knit the UI and database together, implementing any associated business rules
- Testers need to write and execute scenarios to ensure the software is working as expected
The concept of the layer cake stipulates that the “Create New Opportunity” user story should encompass each of these layers. The UI, database, backend, testing, etc.—into one distinct story. Each component layer represents a subtask within the story.
When the story is complete, the user has working software in front of them. Now, they can provide fast feedback. This feedback then guides the creation of the next batch of user stories. The user takes a bite of the layer cake and says, “mmm, delicious” or “this is good, but it could use a little more…” or “this is horrible, never feed this to me again.”
Regardless of the outcome, the user has now given your team direction to inform their next steps.
Breaking Down the Layers
To further illustrate the concept, imagine that each of the layers I mentioned above is represented as its own user story. Code UI, Update Database, Code Backend, and Test New Opportunity as independent stories. In order to deliver value, the team MUST complete each one of these stories by the end of the sprint.
In isolation, an “updated database” is of no value to the user. I assure you that most if not all users will not care that you built an Opportunity API using X/Y/Z tools. Only when the team combines all the layers into working software the user can see and use has the team delivered value.
Separating what should be subtasks into distinct user stories also has the deleterious impact of decreasing team integration as each functional area works on “their” stories during the sprint and needed collaboration typically occurs near the end of the sprint—often too late to complete all the stories in time for the demo.
The layer cake user story method forces teams to consider how much functionality can realistically be delivered in a sprint and allows for more precise estimation. Using my Create New Opportunity example, sprint planning may reveal that that story, as constructed, is too big to deliver. The database changes may be too extensive to be completed in one sprint. In this scenario, the team could “skinny down” the story.
Instead of providing the user the functionality to enter all the original data elements for a new opportunity, modify the story to allow the user to enter just the name of the organization requesting the work and the contract value. You can split the remaining data elements into a new story or stories to complete in a later sprint.
Bringing It All Together
Creating layer cake stories often requires a cultural adjustment in the scrum team. Writing stories in this manner ensures that every team member is aware that their work is part of a larger goal of delivering value to the end user. Each team member must be aware of how their efforts will achieve that goal.
As with most things, practice makes perfect. As your stories improve, so too will your estimation, workflow, and ultimately, the software you produce. If you would like to talk to TeraThink on how you can better use vertical layer cake stories, let us know.
[Editor’s Note: This post was originally published on the blog of Dominion Consulting. On November 1, 2017, Dominion Consulting merged with TeraThink and are now operating jointly as TeraThink. All blog posts migrated from the Dominion Consulting website have been updated to refer to ourselves as TeraThink.]