Kelly Waters is Web Technology Director for IPC Media, one of the UK's largest publishers of consumer magazines and web sites. Kelly has been in software development for about 25 years and is a well-known narrator of agile development principles and practices, as a result of his popular blog 'Agile Software Development Made Easy!' (www.agile-software-development.com). Kelly is a DZone MVB and is not an employee of DZone and has posted 40 posts at DZone. You can read more from them at their website. View Full User Profile
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.
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.
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.