When I see internal IT teams adopting agile, I see them face the common challenge of how to properly structure the work they are doing on long-lived, legacy systems. The idea of small, quickly implemented features doesn't always translate to these situations because these systems have several dependencies and require a great deal of work to make even the tiniest change. As a result, teams often assume that they cannot split their changes into small stories because the resulting stories would not provide value.
What they fail to realize is that they can split these bigger changes into smaller changes, and gain value by showing their stakeholders, getting feedback, and incorporating that feedback in their continued development. It's not as critical that each individual story provides a complete solution because changes in this scenario are often delivered in a release that consists of several sprint's worth of functionality. These ideas can be somewhat esoteric, so it's probably best to provide an example.
Let's say you are working with a team at a cell-phone company that has been asked to create a new customer bill. Due to the nature of your systems, creating a new customer bill is not nearly as easy as it may seem. It requires pulling together information from multiple systems that have sprung up as the organization has grown and changed it service offerings. Customer account information is stored in a different system than call records, and information about data services are stored in yet another system.
For the sake of argument, we'll assume there is a compelling reason to do this (that's another article) and your team has created the following decision filter for the effort: "Will this improve the customer experience." Your team now has to figure out how to go about organizing the work. Undertaking this project in an agile manner, your first inclination may be to get the delivery team, the product owner, and some stakeholders together and brainstorm a bunch of stories. The danger with this approach is that you may end up with an incomplete solution where you are missing some critical changes that need to happen but that no one thought of at the time. You run an equally likely chance of generating a wish list of a bunch of changes that sound great, but in the grand scheme of things are not really needed. Either situation is not ideal.
Having a big picture view of the change can be very helpful, but choosing the right big picture is critical. In this case, a prototype of the bill is probably your best bet. For the purposes of this case in point, I'm going to use this example from my mobile phone carrier, US Cellular, as our prototype. Don't think by the use of this example that your prototype has to look this pretty. This particular example is obviously gussied up by the marketing department to be "easy to follow" for the cell phone company's customers.
In most situations a simple hand-drawn version will work great. The first thing to do is to create that prototype. Doing so really provides you with the big picture—in more ways than one. By working with the team to produce the prototype, you can help your stakeholders reach agreement on what the bill is supposed to look like, which inherently provides a lot of detail that the delivery team needs. Depending on how radical the change is, you may end up creating a prototype that only shows the things that are going to change from the existing bill or you may have to show a prototype that reflects a completely new bill.
Once you have a prototype that everyone can agree on, the next step is to identify the items for your backlog. This all comes down to splitting the work out into small enough chunks so that your team can finish something in a couple of weeks, show your stakeholders, and get some feedback to apply on the next stories you have to deliver. Your first story could be for the bill itself, but you would probably follow that up by creating a story for every section and then evaluate each section to see if it makes sense to split into smaller stories. In some cases that breakdown of stories is sufficient, but in many cases the work needed in generating the information can be much more involved because of the interaction of multiple systems.
Let's assume that is the case in this situation: The team decides they need to break the stories for each section up smaller. Here are some of the ways that the section can be broken up.
Account Summary This section could be split into smaller stories based on parts of this section. The first part is the page section (Page number, Account number, Bill Date, and Invoice Number). The second part is the series of summary information in the boxes and the list below it. If the team feels that it is still too large, the Account Summary section could be broken into smaller chunks, down to a separate story for every element if generating that information is complex.
Remittance Form
This section may warrant a single story, but could be divided into the static content (thank you text at the top, company logo, return mailing address) and the dynamic content (Total Amount Due, Account Number, Address).
Account Number Summary
This section may be small enough by itself to be a story. One thing the team may find as they discuss the acceptance criteria for this story is that there are several different examples that need to be checked to verify that the section is delivered correctly. The story may be broken down into an Account Number Summary for a single-line plan (effectively establishing things so that it doesn't appear) and multi-line plans to show the corresponding Account Number summary. Another story may cover Family Plans (because a note for the Cellular Telephone Number Summary of Totals indicates that the monthly service charge for Family Plans shows in the Account Number Summary section.
Cellular Telephone Number Summary of Totals
This section may be broken into multiple stories based on plans with different level of phones, and/or plan type. One story would cover single line plans, another for Multi-line Plans (perhaps different stories for plans with different number of lines), and another story for Family Plans.
Cellular Telephone Number Summary
This section introduces a couple of different options. You can create separate stories for the different sections shown on the example bill (Monthly Service Charges, Local and Extended Home Usage Charges, and Roaming Charges) or you can split the stories by cases where there is a single line or multiple lines. Or, you may find it is helpful to do both. It really depends on what it takes to deliver functionality in those different situations and what seems to make sense for getting something down small enough to deliver in a couple of weeks but significant enough to provide some value, even if it is providing a good enough understanding of what will end up on the bill to the stakeholders so that they can provide meaningful feedback.
Other Charges and Credits
In this section you may find it helpful to create stories that address the different parts of this section (General Fees and Credits, Additional Purchases/Credits, Games and Themes, Premium Messaging Content, Other Downloads, Taxes) or you may find that the source of that information is consistent enough that they can be delivered in one story.
Wireless Details of Usage
This section may have stories for when the customer has detailed billing and when they do not or different stories for a different number of lines. You may find that a single story is sufficient for delivering the information in this section, but you have an extensive set of examples that entail all the different possibilities that may exist in this section.
Phone Download Service and Picture Messaging
This may work as one story or it may make sense to have separate story for each part of this section. (Data Network Usage, Application Charges, Picture Messaging). You may also find that you have separate stories dealing with providing information for specific packages the customer may have; for example, one story for monthly subscription, a different story for unlimited purchase, and a different story for pay-as-you-go Picture Messaging.
There are of course several other ways to split these stories, and it's distinctly possible you can have fewer stories that would be sufficiently small to be done within an iteration. I chose to use the cell phone example as a general case for discussion purposes, but the overall approach is based on one I have helped teams use when they were trying to tackle similar efforts. The amount of splitting needed depends on the complexity of the systems—something the team should understand fairly well. One thing that is fairly consistent for teams working on legacy systems is the approach of starting with a prototype and using that to guide in the creation of the backlog.
