« A 15 minute primer on ASP.Net AJAX | Main

Role of the "Proxy Customer" (Agile for: Business Analyst)

We all know that ideally you want a customer present at all times and involved in the project. That this yields the best results in the shortest time on any given project. But that there are times when the customer is unwilling or unable to be available.

Reason for a Proxy Customer:

The Proxy Customer can help fill a gap in projects where the Customer is not always available when stories are being done in an iteration. Then the Customers are happy to meet weekly or bi-weekly, but aren't willing or able to be available through out the work day as new stories arise; Or when the customers wants to be able to just send in terse info and have it dealt with without learning any new tools are processes. In a way you can look at the Proxy Customer and being a way of scaling out the Product Owner role.

How the Proxy Customer works with the Team


Help in the creation of User Stories:

User stories serve the same purpose as use cases but are not the same. They are used to create time estimates for the release planning meeting. They are also used instead of a large requirements document. User Stories are written by the customers as things that the system needs to do for them. They are in the format of about three sentences of text written by the customer in the customers terminology. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement.



User Stories, and use scenarios can often easily be turned into meaningful documentaiton. The Proxy Customer can aid in the tasks of create this system documentition.



One thing the Proxy Customer does not get to do is prescribe the technology approach or weight in on, the order of magnitude of a story size or how long a tasks will take.



Help in the creation of Acceptance Tests:

User stories also drive the creation of the acceptance tests. One or more automated acceptance tests must be created to verify the user story has been correctly implemented. The Customer specifies scenarios to test when a user story has been correctly implemented. A story can have one or many acceptance tests, what ever it takes to ensure the functionality works.



Release Planning:

A release planning meeting is used to create a release plan, which lays out the overall project. The release plan is then used to create iteration plans for each individual iteration. Release planning should be made a visible of a processes as possible.

You may plan by time or by scope. The project velocity is used to determine either how many stories can be implemented before a given date (time) or how long a set of stories will take to finish (scope). When planning by time multiply the number of iterations by the project velocity to determine how many user stories can be completed.

The Proxy Customer can also aid the Customer understanding the set of features and bug fixes that make it into a given releases after they move from dev to test or to production.



One collaboration anti-pattern that will be very important to avoid is becoming a barrier between development and the Customer, so that the Customer doesn't directly drive the functionality developed.



Customer Meetings around User Stories:

As often as possible, when the Proxy Customer and the Customer meet. They should do it in the vacinity of the Developers. That way, the vicarious awareness of converations can take place and Developers can easily be directly involved in converstaion where their experience and clarity can help.



Triaging Bugs and the Bug Lifecycle:

One of the most common areas of value the Proxy Customer can play is in the area of traiging bugs on the way in (and completing incomplete work item documentaiton) and testing the resolution of the resolved work items.

Often the Customers feel they have done enough to make you aware of the defect and the adiquite testing of the resolution can go unchecked. The Proxy Customer can take the place of the Customer, by running through the scenarios that cause the bug and then review the results with the Customer for sign-off on completion



Warning Signs that a Proxy Customer role isn't working would be:

Rework of any Stories. We all learn and adjust to the learning as we go with projects, but an increase in work that is being re-done is a sure smell of the Proxy Customer role not working.

Developers rely on the Proxy Customer as their sole and single point of contact and stop communicating directly with the Customers.

Developers feel like they aren't hearing from the customer. Even if it feels more efficient to just leave the Developers out of meetings and such it is a point of communication breakdown and should be avoided.



After writing my take on this I found:  http://www.agilemodeling.com/essays/businessAnalysts.htm



Most of this looks like it jives with what I wrote.




Thank you,

Craig Gjerdingen
Applications Development Manager
Office of Information Technology
Carlson School of Management
c. 612-242-8384
o. 612-625-6657