Chapter 8: Mapplet Release 2

The mapplet example now begins development for its second release. We’ll write some new use cases to define the new functionality that the customer wants added to the mapplet for this release. We’ll also use an extension to ICONIX Process, persona analysis (described in detail in Chapter 10), to help drive the requirements. Then we’ll drive the use cases all the way to code. For brevity’s sake we’ll focus on just one of the use cases, “Filter Hotels.”

Customer Feedback on the First Release

With the first release of the mapplet in alpha (see the screenshot of the finished release in Figure 6-12), the customer (that would be our Doug) set up the new mapplet on a sectioned-off area of the VResorts website to test it out and generally play around with it. An interesting thing happened—something we’ve seen time and again after an initial release (or prototype) of a new system becomes available. The customer began to think of all sorts of new possibilities. His reaction went along the lines of “Hey, this is great! By adding the mapplet, I can now also do this, that, and the other with my website that I couldn’t do before. I could also do these other things if the mapplet could be extended to do this stuff too …”

This type of feedback seems especially common when a project is extending an existing system. The project opens up new possibilities, not just in itself, but also in what the existing system is suddenly capable of.

Here are a couple of examples of the feedback Doug (in his customer role) e-mailed to the development team upon seeing the first release version:

This will definitely allow me to put up “mapplet-based destination pages” by the hundreds very quickly. But it does need to allow me to drill down and look at the hotel brochures.

All these links use the ?HotelID=11111111 form of the URL. This allows me to preset the mapplet to the immediate neighborhood that I’m looking for centered on a specific hotel.

This feedback proves useful in a couple of ways. First, it provides confirmation that the release has met the specific goals that we set out to achieve. Second, it comes in handy when planning the next release of the project. Quite often, the customer reprioritizes features based on what he now realizes is possible. He might have previously assumed that certain features would be too difficult or expensive (even if the developers had assured him that certain features would be easier to implement than others).

There is often a disconnect between the customer’s preconception of whether something is technically difficult to achieve versus the programmers’ assurance that something is actually not that difficult to implement. The customer may not realize that the programmers already have a powerful set of APIs at their disposal, so they actually don’t need to do very much to implement an apparently difficult feature. Seeing something concrete produced in a relatively short amount of time in the first release should allow the customer to place some faith in the programmers’ estimates. This will almost certainly affect the way the customer prioritizes subsequent releases, which therefore should become increasingly grounded in reality.