Themes are categories for user stories. You use them to aggregate user stories into cohesive buckets. The following stories, taken from my product backlog at Xclaim (my company), could be said to fall into a “security” theme:
As a user, I want to be able to change my password, so that I can keep my account secure.
As a user, I want to be able to reset my password, so that I can retrieve a forgotten password.
As an administrator, I want to be able to inactivate a user, so that I can deny an account access to the system.
Great. I have organization. If I have an electronic system, such as Excel, I can filter my backlog to look at items in a particular theme. This organization has a couple of very handy uses.
First, we can start to get our heads around a large backlog. We have a lot of stories. A lot. How can I focus on one particular area of the system? How can we get in a poker planning groove? Thinking about related stories has an effect of “sensitizing” developers and accelerating the estimation process. At least that’s my working theory.
Second, having a number of stories under a theme lets me track at the theme level. To do this we can develop an information radiator known as a parking lot chart. These look like so:
The boxes that look like parking spaces (hence the name) indicates the theme. There’s a label and a progress indicator. One calculates the progress by dividing the number of story points completed by the total number of points. A parking lot chart is an easy way to impart an overall sense of “progress” or “done-ness” at the product level. (Note: typically you’d also show the numeric percent done.)
Finally themes give you the ability to prioritize in the large. In the chart above, it’s easy to identify that we don’t have the same completeness in “invoices” as we do “reports.” Maybe it’s time to address that or maybe not. Either way the parking lot chart, enabled by themes, gives us a means of considering priorities in the large.
There are a couple main tips I’ve found useful when developing a backlog with themes.
Fewer themes are better.
When I started off I was using a tool (VersionOne) that permits very sophisticated theme management including hierarchies of themes, etc. You could have a “security” theme with a child theme of “personal account management,” for example. I’ll admit to not going the simple route (hey, it happens) and skewing toward many very granular themes with child themes. In the end I ended up pulling back to just a few in a flat namespace. It’s much easier to manage and much easier to understand at a glance.
Keep your themes business specific.
Another mistake I made was to use themes as a developer-centric means of mapping stories to technical components in our architecture. Developers are perfectly capable of making this mapping; they do it at estimation time and again inside of an iteration so it’s a bit redundant to misappropriate themes for this purpose. By keeping theme names business facing you get a nice product planning tool that makes managing a large product backlog easier.