Themes in Agile Software Development
by Kelly Waters
Agile software development teams often use User Stories as a simple and concise way to express user requirements.Ideally these User Stories are broken down as small as possible, whilst also trying to minimise dependencies.
Naturally, though, as you break User Stories down smaller, they become increasingly inter-dependent. Like most things in software development, it's a balancing act.
Break the User Stories down as small as possible. But stop breaking them down when it becomes onerous or pointless to do so. When a User Story can be delivered (done) in less than 1 day, I think there is little point breaking it down any further.
Use the concept of Themes to categorise these related User Stories under one label and keep them together.
You could physically keep the cards together by paper-clipping the cards together. Or you could put a card representing the Theme on the left side of your whiteboard, and keep all related User Stories on the same row as the Theme as they move across the board.
Equally important, try to make sure that any inter-dependency between User Stories is a soft dependency, rather than hard. By this, I mean that you might not want to ship any of the User Stories until the whole Theme is done. But try not to break them up in such a way that one User Story simply doesn't work without another.
For instance, a 'Login' Theme might include User Stories for Register, Log in, and Forgotten password. Although the stories are related, and somewhat dependent on each other, they can still be delivered in isolation, and can still work from a user perspective if you do them in the right order.
You can also use Themes to categorise loosely-related items on your Product Backlog. For example, on a web site, you might have a whole host of User Stories relating to SEO, performance, usability, a re-style, or sections that are made up of multiple User Stories.
Assigning Themes to the User Stories in your Product Backlog can help you to see emerging themes, which with a loose set of User Stories you may not have noticed. When you see emerging themes for your next Sprint or two, this can help to give extra clarity to the team and business about the Sprint Goals.
This is a useful thing to do. It gives you more of a message for the Sprint. It's actually *about* something, rather than a random collection of high value but unrelated stories. It could tell you that you're focusing a high percentage of your Sprint on features x and y, when at a macro level your priorities are really elsewhere, for example.
It also helps when priorities are set top-down. For example, let's say we make the commercial decision that for the next few sprints SEO will be a top priority. You can quickly grab all the User Stories with the SEO Theme and give them priority.
Of course it's fine for a sprint to include items that are not part of the overall Theme. The theme is simply the main area of focus, not necessarily the sole area of focus.
There is sometimes a danger with agile software development that everything is broken down so small and incremental that everything becomes a bit too tactical, and there is either no direction or at least the direction is not apparent.
It's important to keep a higher level Release Plan, or a Product Roadmap, so the Sprints do take the product in a certain direction, and so the team can see what that direction is. Because no Sprint is an island!
You can also use Themes as a simple way to sketch out broad priorities on the Product Roadmap, showing the key areas of focus over time.
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Photo by *phototristan
2 August 2010 01:51
A clear statement on what the relationship, hierarchy (if any) and differences are between themes, epics, user stories, featuires and tasks would be immensely useful.
2 August 2010 08:20
Hi Anonymous - fair point, it is a bit confusing.
It's not necessary to always use these levels if they're not appropriate, but here's my take on what the difference is...
A user story may include several features. For instance, 'As a user, I want to search for a job, so I can find my next career move' might include various features, such as simple search, advanced search, faceted navigation, sort, filter, sign up for email alerts, etc.
A user story this big would be considered an epic, since it's a very big user story. Epics can (and ideally should) be broken down into further user stories.
Each feature can be broken down into tasks. For instance, the advanced search feature (which could also be expressed as a user story of course) might include back-end development of the search index, front-end development of the search box, an API to find the most relevant search results, front-end development of the results page, writing test cases, executing the tests, configuring the search servers, etc.
Themes, on the other hand are just a broad way of describing an area of focus. For example, the theme of the next 2 sprints might be 'job search', after which it might be something else, say 'apply for a job', followed by 'CV database'. Each theme would probably contain several epics or many user stories.
In terms of hierarchy, I think these aspects of the backlog can be defined in as structured or as loose a way as you think is right for your project. I don't think there need to be any hard and fast rules on this.
I hope that helps!
Kelly.