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.