Martin Fowler states that the first law of distributed objects is: don’t distribute your object. I think that the same applies to distributed teams. Co-location just makes things easier and distributing people makes it all much, much harder. However, sometimes, for reasons outwith our control, you end up with a distributed team.

I’m hoping to catalog some techniques I’ve used to run distributed retrospectives (and possibly other activities like stand-ups, planning, pair programming, etc) in a series of posts under “Distributed Team”. It’s not an in-depth study of the retro techniques, rather notes and observations on how well they worked with a distributed team (and what changes can be made to help).

Why? Well I’ve been working on distributed Agile teams almost exclusively for the last 5 years and have tried many things to make the team feel more inclusive, work better together, and ultimately be more effective at delivering software. Some of these things worked well and I’d like to share them.


I like the Sailboat retro technique as it’s very good at gathering data and quickly grouping it. It is also fairly simple to understand, requires minimal preparation, and overall is a great introductory technique for teams unfamiliar with regular retrospectives.

For those of you unfamiliar with this retro technique, there is a picture of a Sailboat. It’s essentially a visual collaboration game where you place issues around it to signify:

  • Sails – what is making the project faster/better ?
  • Anchors – what is slowing down/dragging on the project ?
  • Rocks ahead – what risks/dangers are coming up?

Distributed Sailboat

I flexed my Paint skills to the max and sketched out the boat below, feel free to use it yourselves.sailboat

First off, we all dial into a conference line. We’re in a Windows 7 environment, so I ran a screen-sharing session with the Sailboat as my background (and a nice clean desktop). Using the Sticky Notes application, I would capture each idea as it was raised on a new note, then locate it appropriately over the image on my desktop.

It sounds simple, and for this technique, it worked really well. Once you’ve aligned the Sticky Notes around the boat, colouring them also helps. This is how ours ended up:


Summary of tools

  • Conference line
  • Screenshare
  • Paint (or use my image above)
  • Sticky Notes

Like many distributed retro techniques, this relies on one person driving the shared screen. With a lightweight activity like this, where the other participants are providing most of the data and discussing the groupings, it’s not too much of a burden.

Product Owner required

November 16, 2011

Recently we had to find someone to act as Product Owner for our project. He had little experience of Scrum or of agile software development so I wrote him a primer on what role we needed a Product Owner to fulfill. This post is more or less what I sent him to see if he had the time and appetite for the role (with company and project details removed/altered to make it more generally applicable).

There are some things that people assume about the role of Product Owner, so let’s dispel some of those upfront.

What the Product Owner is not

  • It’s not a “prestige” or “honorary” role, you will have work to do and decisions to make
  • It’s not a project manager role, it has specific responsibilities but they are not related with the running of the project
  • It’s not shuffling work around on a spreadsheet and then handing it over to be done
  • It’s definitely not running the build team 😉

What does the Product Owner need

  • A clear and detailed product vision – the build team will look to the Product Owner for guidance on features and how they should work and fit in with “the vision”
  • A solid understanding of Business Value – I’ll come back to what I mean by Business Value
  • Communications with the key stakeholders and project sponsors
  • Understanding of the User Stories in the backlog – we’ll work out what level of detail and language they need to be valuable to both you and the build team
  • Some understanding of how software is developed, but not low level details. It will be helpful for us to occasionally explain technical concepts, but we won’t be asking you to cut any code.
  • Skin in the game. You’ll be responsible for maximizing the value realized from the effort spent.
What is Business Value (in this context)?

Ultimately, Business Value is whatever the Return On Investment (ROI) of this project is going to be judged on. That could be the number of users, the happiness of our users, the diversity of our users, the number of installations of the application, the collective dollar savings our customer make by using the product, or any combination of those (or more) options. This is not always going to be the same for all time either.

For example, right now we are trying to make a handful of customers happy, but next year we’ll probably be more interested in increasing the number, and diversity, of projects using our application, and how much money they are saving the firm by doing so (it’s an internal project in our firm, but the teams in the firm will only use it if they perceive it to be giving them additional value).

It’s going to be up to you to identify the current Business Value and prioritize work accordingly to get as much Business Value as possible…and be aware of when Business Value changes.


So I’ve talked about what a product owner is not, the things they need, defined business value. It’s probably a good time to talk about what you’d need to actually do.

Product Backlog

This is where every feature, bug, task, activity, etc related to the product lives. You would be responsible for keeping that list up-to-date and prioritized. This is the element of the role that was referred to as being a full time role. We will end up with some shared responsibility of its maintenance, but you would have the final say on priority of work. With that control, you’d be expected to keep on top of what’s in the backlog, see dependencies (with our assistance where it’s a technical dependency), and determine urgency of items. In an ideal world, you might be able to assign a numerical Business Value to each story to assist you…but we’ve attempted that on other projects and it’s not a trivial thing to do, so let’s walk before we run. There is also the breaking up of stories into smaller units and the creation of “epics” which span many stories to deliver a higher level feature.


You get to accept or reject any work done. Traditionally this is done via a demo at the end of an iteration where you would come along and we’d demonstrate all the features built in that iteration. Being intimately familiar with the stories, you would be in a position to say whether or not it’s acceptable, or perhaps needs some additional work. The feedback from this is also a driver for fine tuning the user stories so that your expectations line up with what we’re delivering (and vice-versa).


In iteration planning we essentially take the prioritized backlog and see what can be delivered, in a fixed period, starting with the highest priority item and working our way down the list. Of course this is an oversimplified view and it’s not always the most effective way to work, so your input would be required to provide themes and higher level goals for each release/iteration. For example, in one release we might focus on integration with other systems, in another we might focus on improving user experience.

So, given all of the above, are you still interested in the role job?

Writing better user stories

November 11, 2011

Recently we had a planning session where I was asked to explain what made a good User Story, so I thought I’d capture that in a blog.

We are all familiar with the standard layout of a User Story:
* As a …
* I want to …
* So that …

However, I’ve observed a temptation to just blindly follow that formula and then claim that you are “doing Agile”. For me, the real essence of Agile is looking at what you are doing, identifying if it’s giving you good value, and if not, changing it so that it does (or dropping the practice all together). So, how to we write better user stories ?

I’d like to start by breaking down what we capture with the above formula, what qualities we want from a user story, and then what we can do to improve our stories.


Role, Task, and Motivation

As a … : this defines the role of the person stating the User Story and gives it a context. If you have the same value here for every story, “User” for example, then the field is not providing any value to you. You should take the one role you have and try to break it into finer grained roles, even if they are not actually represented that way in your system.

I want to … : this is the task you are trying to achieve in the context you have just set up. Generally, people are quite comfortable describing this part. Concerns here are striking a balance between readability and capturing the necessary details. I’d err on the side of readability and make sure that the task part of the description is memorable and differentiates the story from others. You don’t have to capture all detail in this one line, you can add additional detail to a story outside of the “As a, I want to, Such that” structure.

So that … : this is the motivation behind the story and, I find, often over looked when writing User Stories. I’m not suggestion you write a lengthy thesis on the motivations of the user, but at least explore it and see if there are some useful pieces of information to take from it.



A good user story should also capture some information about how you might go about testing the story. This can be in the form of a simple “Done” list, or perhaps as  description of an integration level test/scenario(s) that would exercise it. I’ll assume that you would be writing unit tests (and writing them first) as part of the implementation.


Large Stories

A cardinal sin in my book is having huge stories that have such a complex completion criteria and cover such a wide range of functionality, that they take many iterations to be completed. These interrupt the rhythm of an agile project because it’s very hard to track progress against them. I’ve found that this can have a negative effect on the team morale as the story rolls on from one iteration to the next. We currently have a rule of thumb for our 1 week iterations, which is to limit estimates on stories to 3 days. If it looks bigger than that, I encourage the creation of sub-stories within it. So far, that’s working well for us.

Sure, you might find it useful to capture epic stories as a set of related functionality, but break it into bite sized chunks. Not only does this give you a warm feeling to the team as you close out all the sub-tasks, but the act if breaking an epic into smaller stories helps focus in on what exactly you are trying to achieve…which is what a good user story should do.



So do we write perfect user stories every time? No, of course not, but we often review stories in our retrospectives and identify which features of them made them easy to work with and which stories we had trouble with. I never expect a story to capture every detail, but I like to aspire for stories that anyone on the team could pick up and understand what needs to be implemented, why it’s being added to the product, and how they can go about verifying that they have finished the work.