Hi! My name is Sunil Kumar, I am a Software Developer and Designer from London, United Kingdom. I work with Java and XML Enterprise Ecosystem Technologies and Mark Logic.

•                       Follow @esunil                                               

Specification Workshop: A panacea for distributed agile team

In my previous job, we introduced a process called Specification workshop. This was done to improve the quality of user stories and team’s understanding about it. Specification Workshop is not yet so popular with agile teams. Our team’s experience is very good and everybody found it useful.

Next I am going to describe about - how distributed agile teams are structured, how stories are planned, what Specification workshop is and how this helps to bridge the gaps between technical team, tester and business.

Team Structure:

It is very common nowadays in globalised world that an agile team is distributed across many geographic locations across many continents. Let us imagine a case where development team is based in London (UK) and Business Analyst is located in New York (USA) and some members of Quality Assurance Team are in India and other members of Quality Assurance are in Moscow (Russia) and Project Manager being located in Oxford (UK). This is not an imaginary team but many of us have been part of such team.

It is no surprise that such teams will have challenging time ahead in the project. Team members have a common goal – development and deployment of features/project in the production. But not every team has same level of understanding of the requirement. The main challenge for distributed agile team is to have same level of understanding of requirement among technical team, testers and business.

Story Planning:

Let us have a look at how story is planned in agile team. At high level, BA will get the requirement from Business/Client and will do analysis and then create a user story from it. The user story is written on piece of card or logged on to some digital system e.g. JIRA. Next, story is either discussed in pre-planning meeting with Tech-Lead or/and discussed with the whole team in the planning meeting. There may be few questions asked by Dev team or QA Team in these meeting. The real problem with these meeting are –

1) Many stories are discussed with whole of team and meeting can drag very long,

2) Individuals may refrain from asking questions for some reason e.g. meeting is dragging or people are rushing to finish the meeting, etc.

3) Testers, in some cases, are just passive listener and does not really participate during this period.

So, some stories are not clear and not ready for Dev team but gets planned and picked by Dev team. These stories most of time initiates discussion, during the play, among Dev, BA and other stakeholders. These communications are very late in the process and delays delivery which results in extra cost to develop the software.

Specification Workshop:

Specification workshop is a same-time collaboration of technical team, testers and business to develop a requirement specification using any BDD tools e.g. Cucumber. Team members may be located at different geographical places. This process requires screen sharing facility and every participant on the conference call. There are few preparatory steps e.g. technical team will create a feature file which will contain details of technical analysis, if any technical analysis done. During the workshop BA gives a business overview of requirement whereas technical details is either provided by Tech lead or by a Dev. Then a developer or a tester starts adding scenarios to the existing feature file. Note, the term Scenario comes from BDD world. In fact, Scenario is like acceptance criteria in plain English. If any tester thinks that some scenarios are missing then he can ask to add those scenarios or can add himself once the feature file has been checked in to version control. BA can also ask to add any scenario which he thinks is missing from the list. Actually any one part of the workshop can ask any question which should be clarified then and there if possible. If there are doubts about any question then a note should be added to feature file for later clarification.

You can imagine that how technical team, testers and BA are discussing and agreeing on what need to be done to deliver the feature. In the workshop, everyone gets opportunity to clarify any query or concern about the requirement. There are no time limit on duration of discussion of a story. But it is good idea to time limit the workshop duration to one hour. And you can have as many workshop as required before the planning meeting. Once specification workshop is done for a story, story can be handed to testers so that they can to add extra scenario or review the existing scenario. At end of this process, story is quite complete and requirement is clear to everyone in the team. Devs and testers who have not participated in workshop for the story can still raise query in planning meeting. This process grows the requirement and make it more mature.

Typical flow of a user story is something like:

Benefits of specification workshop:

• Well defined requirements
• Upfront discussions among Developers, testers and BA
• early involvement of the testing team
• No or very little communication required while developing or testing the story
• Less time required by tester if all scenarios are working fine in continuous integration environment
• Good documentation of requirement in the form of feature file
• Documentation will updated if requirement changes
• Same-time query clarification, no delay due to no use of email or any other digital tool

Conclusion:

We saw that how a distributed agile team faces changes due to distance and various layer of communication. This leads to confusion about requirement among the team members. Which ends up pushing the development cost to higher side. But if we introduce the missing link, specification workshop, to the process. We find that quality of user story is very high. Understanding of user story requirement is increased many folds for technical team and testers. This helps in reducing the very late communication among BA, testers and developers. Stories which is part of the planning backlog are quite mature and of high quality.

I’ll recommend using specification workshop to not only distributed team but also to co-located teams. I have tried to give overview of specification workshop which is not very detailed but gives a fair idea about it.