Communicate Through Stories Rather Than Tasks
Last time I talked about interfaces between pieces of code. Today I want to discuss the interface between groups of people involved in developing software. 
There are two basic groups: those who develop the software, and those who coordinate that development. In Agile terms, those groups are the Development Team on the one hand, and the Product Owner and other Stakeholders on the other.
Speaking the Same Language
The two groups need to communicate, so they do best when everybody speaks the same language.
This begins with speaking the same “natural” language, e.g. English. For most teams that will be a given, but teams that are distributed over multiple locations in different countries need to be a bit careful.
Once the language is determined, the team should look at the jargon they will be using.
Since the Development Team needs to understand what they must build, they need to know the business terms.
The Product Owner and Stakeholders don’t necessarily need to understand the technical terms, however.
Therefore, it makes sense that the Ubiquitous Language is the language of the business.
Speaking About Work: Stories and Tasks
But the two groups need to talk about more than the business problem to be solved. For any non-trivial amount of work, they also need to talk about how to organize that work.
In most Agile methods, work is organized into Sprints or Iterations. These time-boxed periods of development are an explicit interface between Product Owner and Development Team.
The Product Owner is the one steering the Development Team: she decides which User Stories will be built in a given Iteration.
The Development Team implements the requested Stories during the Iteration. They do this by breaking the Stories down into Tasks, having people sign up for the Tasks, and implementing them.
Tasks describe how development time is organized, whereas Stories describe functionality. So Tasks may refer to technical terms like relational databases, while Stories should only talk about functionality, like data persistence.
Stories Are the Interface
Since we value working software, we talk about Stories most of the time. Tasks only exist to make implementing Stories easier. They are internal to the Development Team, not part of the interface the Development Team shares with the Product Owner.
Many Development Teams do, in fact, expose Tasks to their Product Owners and other Stakeholders.
Sometimes they do this to explain why an Estimate for a Story is higher than the Product Owner expected.
Or they let the Product Owner attend Standup Meetings where Tasks are discussed.
This is fine, as long as both sides understand that Tasks are owned by the Development Team, just as Stories are owned by the Product Owner.
The Development Team may propose Stories, but the Product Owner decides what gets added to the Backlog and what gets scheduled in the Iteration.
Similarly, the Product Owner may propose, question, or inquire about Tasks, but the Development Team decides which Tasks make up a Story and in which order and by who they are implemented.
Always Honor the Interface
This well-defined interface between Product Owner and Development Team allows both sides to do their job well.
It’s important to understand that this has implications for how the software development process is organized.
For instance, the metrics we report up should be defined in terms of Stories, not Tasks.
Outside the Development Team, people shouldn’t care about how development time was divided, only about what the result was.
If we stick to the interface, both sides become decoupled and therefore free to innovate and optimize their own processes without jeopardizing the whole.
This is the primary benefit of any well-defined interface and the basis for a successful divide-and-conquer strategy.
What Do You Think?
What problems have you seen in the communication between the two groups?
Are you consciously restricting the communication to stories, or are you letting tasks slip in?
