This is the fifth in a series of posts that began with “How to Capture Software Requirements Using Story Roadmaps”. The focus of this post is themes.
Agile software development projects usually rely on user stories as the primary vehicle for capturing software requirements. Yet, user stories are often criticized for being disjointed and confusing. Here’s why that happens.
There is a strong tendency among agile software development teams to define a software vision and immediately dive into user stories. That approach can work for small projects because it’s fairly easy to envision and comprehend the finished product.
But for enterprise-scale projects, jumping into user stories is a flawed approach. There are too many features and functions in a large-scale software application — too many stories. Every time a new story is written, two more emerge. Getting all the stories to fit together cohesively can be a monumental task.
Let’s step back and take a top-down approach to evolving the user stories via themes and epics. First, a few definitions will help clarify the discussion:
A user story is a specific action taken by a user to achieve a desired result. You’ve likely read that user stories need to be independent, negotiable, valuable, estimable, small, and testable (the “INVEST” model). It’s good advice.
An epic is a group of related stories. Like stories, epics capture user actions and results but they do so at a higher level. Epics are too big to be written and tested by a single developer within a few days. They don’t meet conditions of the INVEST model.
A theme is a high-level software objective encompassing multiple epics. Themes may span more than one project or product. Themes help to drive software strategy and communicate a clear direction. They can be viewed as implementation goals.
I’ll return to the example I’ve used throughout this series of posts. We have a local retail chain that wants to allow customers to order products online. The retailer already has a web presence but it’s for marketing and advertising only. Online ordering is a new capability.
What would some possible themes be for this project?
Theme 1: Customers want the ability to view products available for purchase.
There are many possible software implementations for browsing, searching, sorting and selecting products. Those implementation options will be covered in epics and stories.
Theme 2: Shoppers want to have a shopping cart as they navigate the site.
Shopping carts are a standard feature of virtual retail websites. Implementing them involves a lot of user activities including adding items, removing them, changing quantities, emptying the cart, saving the cart for a return visit, etc.
Theme 3: Customers want the option of registering with the site or simply making a one-time purchase without registration.
User registration, payment options, order tracking, etc. are complex topics — too complex to be covered by a single story or epic.
As you can see, themes help to group software functionality into manageable chunks. Think of a theme as a goal for one aspect of the software implementation. Themes will drive the minimum marketable feature set and help the team to focus and deliver what really matters.
Themes can also be used to focus the team’s activities during sprints. Having each sprint operate around a theme will help the team operate cohesively.
The user story roadmap has come a long way. We have Goals, Stakeholders, Needs and Themes. In the next post, I’ll discuss Epics in more detail.
photo credit: Nina Matthews Photography via photo pin cc
[The next post in this series is available here.]