This is the sixth in a series of posts that began with “How to Capture Software Requirements Using Story Roadmaps”. It started with goals and will end with stories. The focus of this post is epics.
If your software development team has gotten this far along on the User Story Roadmap, the epics should be readily apparent. The team has developed a good understanding of what the project must achieve and who it must satisfy. Those are giant strides!
Now it’s time to articulate what the software will do when driven by user actions.
Epics follow the standard agile format for writing user stories:
“As a <role or persona>, I want to <accomplish something>, so that <benefit or reason>”
So, if epics follow the same pattern and format as user stories, what’s the difference?
The difference lies in the size and complexity. Let’s go back to the INVEST model for writing user stories. INVEST is an acronym for Independent, Negotiable, Valuable, Estimable, Small, and Testable. It’s good advice when applied to stories.
As for epics, they too should be Independent and Negotiable. However, they are not necessarily Estimable or Small. They have to be Testable, of course, but the testing will likely need to be broken down into smaller chunks (and aligned with stories).
So epics fail the INVEST test but that’s good. You’re still in the process of drilling down into the software details. You’re not at the user story level yet.
Let’s go back to our example retailer and its project to build an online ordering website. One epic might read like this:
“As a new customer, I want to create an account, so that I can save time when placing orders.”
Why isn’t this a user story? It’s too big. Creating an account means entering name, billing address, shipping address, phone, email, credit card information, password, and possibly other details. Credit cards need to be validated and verified. Email addresses need to be confirmed. Invalid or duplicate data entries need to be marked, then corrected. There’s a lot to do!
This is far too big to pass the INVEST test. In fact, depending upon the complexity of the final system, the team may opt to split this epic into two or more epics. For example, there could be more than one type of customer or account.
Don’t seek perfection!
The epics won’t be perfect on the first pass. That’s okay. As the software system takes shape and additional clarity is gained, some epics will be split into two or more epics. Some may be discarded and redefined. Eventually, they’ll evolve into user stories that the team can implement within sprints.
As long as the epics remain in the product backlog, the team can create, update and delete them as needed. Once they are broken down into stories AND allocated to a sprint, it’s showtime!
The user story roadmap is nearing completion. We have Goals, Stakeholders, Needs, Themes and Epics. In the next post, I’ll conclude this series with User Stories.
[The next post in this series is available here.]