Distributed Development: Delivery (Part 2)

7 April 2015
| |
Reading time: 6 minutes

The previous part covered aspects of regular sprint meetings. In this section, we will share our experience related to distributed estimation, sprint review and retrospective sessions from various projects. The focus is on the format of a meeting, with some variances we gathered so far.


Our typical setup for estimations is that one moderator prepares the items for estimation in advance by gathering domain/business knowledge on grooming sessions and guides the rest of the team through the items. Each item is explained and analyzed by the whole team. Estimation is then performed using an online tool. Each team member is sitting on his place, joins the group call and online estimation session. After the voting round is complete, votes are discussed and item is re-estimated after discussion, if needed.

In one of our projects we tried to moderate these sessions from the off-site part of the Team. Unfortunately, this didn’t work out well since the moderator from off-site part of the team didn’t have enough business and domain knowledge and was not in constant relation with the business. In the end, the only role of moderator on the off-site part of the team was to schedule a meeting and keep the meeting within the timeframe and on track, leaving the explanation of the item and its priority for estimation to an on-site team member who had greater knowledge in the area. 

Distributed setups can also help in estimations during the bidding phase and not just when the project is already running. Sometimes, a request for proposal is required on a short notice and it could happen that there are just not enough People available in one location to do the estimation together. Having a pool of professionals distributed across various locations can really give you an advantage in such cases.

For one of our request for offer, we had a couple of distributed estimation sessions. We estimated one user story by using WBS (work break-down structure). One user story was split into tasks and each task was estimated in hours of work. Then we assigned the value in story points to that user story and used it for relative estimation of other user stories. Since we had the estimation in story points and hours for one user story, we could roughly estimate the required effort in hours for other user stories and complete our request for offer. 


Sprint review

The Sprint review is the meeting where the team can proudly present what they have achieved in the last few weeks. Customers gather to see where the product stands and ask questions to the team. Sadly – since the technical setup usually has some restrictions – the off-site part of the team usually doesn’t have the opportunity to fully participate in these meetings. What is possible is to take care that they can see and hear what is happening, thus gather the same knowledge as the on-site part of the team.

In one of our projects the on-site team shares the screen that is used for the presentation and sets up a good conference microphone. That way the off-site team can see what their colleagues are showing and most importantly they can hear the questions asked by the business. 

Active participation in the review is still very important for multiple aspects. It is a chance for team members and customers to meet in person and exchange questions, dilemmas and ideas. Splitting the presentation amongst the developers makes the review more efficient as well, because nobody knows the feature better than the person who has done it.

These aspects make the sprint review a great timing in the sprint for the off-site team to spend a few days at the customer’s location, especially since other important meetings like planning, estimation, retrospective and grooming are usually held at the same time. This gives the team members the opportunity to hold these meetings in the same room, which makes discussions easier. Another very nice side effect of these travels is that there is no better moment for the team to celebrate its success and strengthen the team spirit!

Sprint retrospective

Sprint retrospectives are an essential part of the sprint. It’s the perfect time and place to reflect on everything that happened during the sprint and come up with ideas to improve. Even the best Teams will find space for improvement.

The format of the meeting itself does not differ from the collocated retrospective. It can be start-stop-continue meeting, top 5, four L’s (liked, learned, lacked, longed for), or any other possible format. The general idea is the same: do the brainstorming and try to come up with action items which will help the team to improve in every aspect: efficiency, effectiveness, interpersonal relations and overall teamwork.

The setup of the meeting is similar as for all the other distributed group meetings: both parts of the team are sitting in their meeting rooms and discuss the cards on the online shared board. List of action items are gathered and corresponding to this, a responsible person is chosen for action.

Still, everybody does it a bit differently and after a while each team comes to a different conclusion on what is important for them.

One of the teams came to the conclusion that for distributed sprint retrospectives a video conference is a must because, when team members see each other, the communication is much more effective.

In another project, team members randomly decided who is going to moderate the next retro, which actually led to more transparency in the team, and hot-spots were discovered earlier.

In some other Projects, when we started distributed development, only one developer worked off-site and was not participating in the team retro sessions. After a while the off-site part of the team grew and we saw the need to have distributed session. The moderation of the meeting is now delegated completely to the off-site part of the team while team members are rotating in this role.

The nice conclusion we all have from different projects is that being distributed during any scrum meetings doesn’t make a big difference. You need some online tools, a quality microphone and a bit of will to make it work. If you have that, the only problem you will face is the constantly ruined hairstyle from the headset.

The last part of this blog entry will cover the remaining meetings and a view of the setup from QA perspective.

Comments (0)


Sign up for our Updates

Sign up now for our updates.

This field is required
This field is required
This field is required

I'm interested in:

Select at least one category
You were signed up successfully.

Receive regular updates from our blog


Or would you like to discuss a potential project with us? Contact us »