In my current project we have a big offshore team from an external vendor doing most of the development. It was decided to run the project in an agile fashion using Scrum as methodology and user stories as the means for specifying requirements (in true agile spirit).
As you probably know, a user story is one or two sentences describing a high level requirement from the customer and is meant to be a reminder to the team to talk the customer. Then, when you start working with the story acceptance tests are added so that it is possible for the customer to test that the delivered peace of software works as expected/wanted.
I’ve used user stories before and my opinion is that this format is excellent when the entire team is on-site and sitting close to the customer. However, this does not necessarily mean that it is a good format for offshore scrum teams…..Some problems:
- Geographic distance makes communication hard
- Acceptance test criteria are interpreted incorrectly and then used in negotiations between customer and vendor in determining finish grade
The first point above is kind of obvious. Communication is difficult to begin with, have the team 300 miles away you realize that it is extremely difficult. You can improve the situation using tools as instant messaging, desktop sharing and so on but you can never replace the valuable face-to-face communication which on-site teams benefit from. Sure, you can buy some expensive video meeting equipment and come close to the real thing, but in my book it is definitely not the same. As a consequence you will have fewer discussions about the software to develop and you end up losing important input/changes that the customer may have to the story (and change will happen). Which leads directly to the second point:
Since there is less conversation, developers will trust that the acceptance criteria are correct and implement the system the way they interpret these criteria. Of course, we all know that the written language is full of potential misunderstandings so there is a good chance that the customer does not get what she wants. So the customer is unhappy and does not want to pay for the software which of course is a bad situation for the vendor-> the blaming game has started. Good thing with scrum are that the iterations are short so we at least discover these problems sooner rather than later.
So where do we end up:
The customer tries to specify all the functionality up-front through acceptance criteria and the vendor delivers software accordingly which is contradictory to the whole purpose of user stories. Question is then: Are we better off with use cases in offshore projects?