As per the suggestion of my manager to expand my horizons outside IBM for networking, I decided to drop by the Jan. 29th meeting of the Agile Montreal user group. It was my first visit with the group and I was pleasantly surprised to see 20-30 people there. The meeting presentation was about how to manage relationships with your customers and the presenter did a nice job of keeping us all both entertained and on our toes… 😉

During the presentation, a couple of questions came out from the crowd that stuck with me. So I decided to wait after the meeting to have a chat with those people and see if I could provide them some guidance. The first of these questions was:

How do I handle a customer that comes to me with all of his requirements up front even though I want to work iteratively with them. They don’t seem to get it.

For the sake of the discussion, let’s assume a two week sprint or iteration. The best answer that I can provide for this is to tell the customer the following: “Mr. Customer, it’s really great that you’ve invested all this effort in your requirements. If you look at your list of items, what is the most important thing I can work on for you in the next two weeks. We can talk about the other stuff as we move along in our project and you can refine your requirements as we go, but right now, what could I do for the next two weeks that would make you a happy customer.”

Once the customer starts giving you priorities, ensure you don’t accept more work than you can do in those two weeks, then go off and do it. In two weeks, show them what you’ve done and ask them what are the next most important things for them. You will start building trust with your customer. One of the reason that customers sometimes refuse to prioritize is that they feel they will not get whatever is at the bottom of the list. Yes, that can happen and it surely does. But if you are always working on the most important things to them, some of the things at the bottom of the list will eventually make it to the top or will simply drop off if there’s no need for it.

The important thing is really to build the trust between you and your customer. Show them you are willing to let them decide what is important, then execute the work. If you don’t execute in time, then you will not gain any traction with you iterative approach. So be sure you know what you are committing yourself to doing. The other important point to reinforce is that you are doing just-in-time development for them. The work you are committing to will meet their immediate requirements. Customers think they know what they want but if you spend six months in development before they see anything, you may end up with your customer telling you that you built something nice, but it does not meet their real requirements. So by having these two week checkpoints with reviews, they may find their design evolve in ways they did not originally expect.

The second question that came up was pertaining to user stories. Actually, after speaking with the person, I realized that she was confusing use cases with user stories. There not quite the same.

Should we identify all the user stories before we do the prioritization?

A few things here that I’d answer for this. If you are really talking about user stories, you may want to flush out all the top level user stories with your customer, then ask the development team to do a high level estimate using story points to get an idea of the relative complexity of the features one versus another. This should allow the customer to do some initial prioritization of the stories and this also give you a product backlog to start working with. Once the initial prioritization is done, you can work with your customer to break down the epics into smaller user stories representing units of work that can be contained in 2-3 days.

I gave the person some examples of how I use a combination of user stories and use cases in order to better explain designs to the development teams that I work with. I also gave her some references for Allistair Cockburn for use cases and use case templates and suggested she read Mike Cohn’s book “User Stories Applied for Agile Software Development”.

All in all, a good night. I’m probably going to skip the next meeting as it’s a bit too close to this one and the presentation is of less interest to me.