Themes in Agile Software Development
DZone's Guide to
Themes in Agile Software Development
Join the DZone community and get the full member experience.
Join For FreeDiscover how you can take agile development to the next level with low-code.
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.
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.
Download this eBook to learn how to prepare your business for agile adoption, how to ensure the proper business-IT collaboration that is critical for agile development, and how to choose the right stakeholders to increase productivity and enable accelerated time-to-value.
Like This Article? Read More From DZone
Topics:
Published at DZone with permission of Kelly Waters , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}