This is part 4 of a series of articles on Distributed Agile Development. In this article I will talk about the problems that are faced when writing user stories in a distributed development scenario, and how the INVEST approach can falter.

I published an article introducing the 3 C's and the INVEST approach when it comes to write user stories. One of the most important lessons of that article is that there is a need to negotiate/communicate with the end user while developing the user story.

However, how do you communicate in a distributed scenario?

In a regular, non-distributed, scenario, if you have a situation which the developer doesn't understand, he/she can (typically) just walk up to the Product Owner and hash it out. Oftentimes this is not an option while working in a distributed environment where the individuals who need to negotiate are in different location and often in different time zones.

In such a situation, if there are questions about a user story, the development team needs to email their questions and then come back the next day hoping that the answered have been returned overnight. This kind of approach is very anti-agile and a distributed team needs to take careful measures to avoid this.

So what can you do?

As we discussed above, the problem here is the 'N' (Negotiable) in INVEST. It may not be very practical to get a lot of negotiation done during the development of the user story. The way to combat that is to concentrate on the 'T' (Testable) in INVEST a little more while the user story is being defined. During iteration planning, as everyone works to define the iteration and its goals, it is important that more time is spent on defining acceptance test cases for each user story. Although, the user story can change a little during the development, but defining the testability of the user story up front, gives developers a better understanding of what is desired.

The reason it helps to write test cases up front is because as you write test cases, you already start asking questions about the behavior of the piece of software that the user story is describing; this allows you to bring some of the communication/negotiation part into picture before the story goes under development. Let's take a very small example of a user story:

User Story Description:

• The admin needs an Employee Management Module.
• This module should display a list of employees.
• There should be the ability to add/edit/delete/view an employee.
• There should be the ability to search for an employee.

Now this is a good enough user story description to kick off. You would usually work out the details during the communication phase. However, if you start writing test cases right away, you will ask certain questions which will automatically provide the details up front. A couple of examples of such questions are:

• What column should the default sorting be on the list page?
• What are the fields that mandatory and which are optional when entering employee details?

Each of these questions gives some more detail about the fine points of a user story, for instance, the answer to the second question will reveal details about which fields need to be actually present for an employee.

Summary

To deal with the problem that can arise in negotiation in a distributed development environment, we need to adapt by spending some extra time on the testability part of a user story.