Mike Cohn's Blog

Using a Task Board with One Remote Team Member

I want to address a question I was emailed yesterday but that I receive frequently. What should we do in the case when the team really likes having a physical task board, but when one team member is remote? My first answer is always: Try to get the one person to move to where the rest of the team is. I don’t expect to see any moving trucks roll out when I ask this, but I have to ask. I figured if I keep asking, some team somewhere will eventually have the person move. Having one remote is a cost that must be borne by the full team. For the right person, it’s easily worth it. But sometimes, the person who is remote has not special skills, knowledge or experience to justify the added hassle.

So, assuming that we’ve tried the “move here” solution and it didn’t work, what can a team do that likes the physical task board but that has one remote member?

My recommendation is to continue to use the physical task board–it is simply too beneficial to the collocated team members to give it up in favor of a product backlog tool, especially if team members are already used to it and like it. How the team conveys information on the task board to the remote team member depends on what that person does.

Sometimes the remote person works remotely because they have a very specialized skill that couldn’t be filled in the office where the rest of the team is. This would be the case, for example, if our remote person is an expert in Windows internals and is writing boot-time code in C++. It would also be the case if our remote person has twenty years of experience in the domain and with some of our really old code. In these cases, the remote person usually (not always) works for a day or two relatively alone. The remote person in this case could identify during the daily Scrum what he or she will work on and not need further interaction with the task board until selecting the next task. Here, the remote person doesn’t really interact with the task board at all and interacts only with the team. Not ideal as I’d like the person to see the tasks, but this can work in some situations.

What is more common is for the ScrumMaster to take on the responsibility of updating an electronic version that mirrors the physical task board. A shared spreadsheet is normally sufficient for this, but some teams opt for a more specialized tool, which is fine. Many tools offer 5-10 user free licenses and since the tool is only needed by the ScrumMaster and one remote employees, the free license is adequate.

Normally the ScrumMaster updates the electronic task board once a day, usually right after the daily scrum meeting. Of course, reading the physical task board and updating the electronic one can be quite time-consuming because the ScrumMaster has to look at each task in both places to see if that item needs to be updated.

One good way of minimizing the time the ScrumMaster spends doing this is to mark the cards on the physical task board. The mark indicates “I’ve updated this task. Please update it in the online task board.” I like to use Post-It flags for this. As team members do their daily scrum, they stick one of these flags (of any color) on the card. If the estimate changes, if the task is done, if a new task is added, those cards are tagged with a flag. When the meeting is over, the ScrumMaster can very easily see which items need to be updated. The ScrumMaster removes the flags once the online task board is updated. This approach also works in situations where the ScrumMaster updates the board more than once a day. Any time someone changes the board, flag the task.

Other teams do something similar using color-coded dots. Anything touched on Monday is blue, Tuesday is red, and so on. Two problems occur though: First, the dot packs usually come with four colors to a pack so you have to buy a fifth color. Second, it’s a hassle to make sure we have the right color on hand.

About the Author

Mike Cohn is the founder of Mountain Goat Software, a process and project management consultancy that specializes in helping companies adopt and improve their use of Agile processes and techniques. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile. Mike is a co-founder of the Agile Alliance. He is also a co-founder and current board member of the Scrum Alliance. He can be reached at mike@mountaingoatsoftware.com

30 Comments:

Todd Bradley said…

What’s wrong with just using a video feed of the task board, so the remote person can see it and tell folks what to change on the task cards?  It’s simple and effective and we do it every day with our team member who’s in Slovakia.

Mike Cohn said…

Hi Todd—
Nothing, of course. If you have video equipment that can read the task board, that’s great. I’m referring more to the situation where the remote person needs access to the information of the board beyond just the meeting. Usually the daily scrum is least concern since most issues are handled with discussion there. “What’s that card say?” works during a meeting; it doesn’t outside the meeting.

Gerry Kirk said…

Thanks for responding to my email via a blog post Mike! I’ll give some thought to the spreadsheet tool. This is a team new to Agile. They are interested in Mingle, which is free for them given their team size.

Another suggestion I received on this topic via Twitter from Andy Brandt:

Use an electronic tool and project the task board on a wall. This lets the remote person update information, and local team has benefit of high visibility.

Mike Cohn said…

Hi Gerry—
There’s a big difference though between a physical board I can interact act on cards and one that is projected. Yes, both are on the wall but one is tied to a keyboard, one isn’t. I think the difference between those is quite dramatic. I did see a demo of VersionOne using a touchscreen that was quite nice. So perhaps you can buy a touchscreen display for the team room, but that seems quite expensive to me.

Derek Mahlitz said…

We do this exact process for my team.  We have 7 members in 1 office in NY and 1 member at home in FL.  The collocated team updates our task board and I (SM) replicate in an Excel spreadsheet that is stored in our sharepoint solution.  That way he can keep up with the tasks.  We also do video for daily standup and all collocated team members have webcams for quick meetings throughout the day with FL home worker.  We are a year into scrum and this has worked great without issue.

Mike Cohn said…

Hi Derek—
That’s great to hear that this approach is working for you. Can you give us an estimate of how much time this takes you either per day or per sprint? Thanks.

Kevin E. Schlabach said…

I was thinking Todd’s idea… a decent webcam pointing at the board is cheaper than the hours of a scrum master duplicating it in excel.  (Also, what happens when the scrum master is out for a day?)

The webcam allows the physical/tactile interaction to continue while providing 24/7 view access to the board.  The remote person can always IM a local to move a card for them.

abby, the hacker chick blog said…

Wow, you know, when you spell it out like this it does seem really silly to go through all the effort to duplicate the task board in a tool just for one person.  And we all hate duplication because one is always out of synch and thus wrong.

If the webcam/streaming server is too much hassle, what about just having someone just snap a picture of the board once a day at the end of the daily scrum and upload that…?

Although, the missing point with the pictures is the details on the back of the cards (e.g., acceptance tests).  So… what about if, JUST for the tasks the remote person is working (let’s call him Joe), Joe duplicates the physical cards on his side.  And, Joe works with his team mates/product owner as always to determine the back of the card info for them.  I don’t see why Joe can’t just take responsibility himself for making sure his copy of his task cards is the same as the one at the central office (including asking a team mate at the office to update that card as needed), rather than making the SM do it?

Heck, why not have Joe keep his own mini task board that he uploads a picture of before each daily scrum so the team can also see a visual indication from him?  I dunno, maybe silly, but I wonder if that might help bridge the gap a little?

Mike Cohn said…

I want to be clear on something that apparently did not come across in my initial post: I was trying to address the question of “how do we handle conveying information from the task board during the day *other* than the 15 minutes of the daily scrum.”  Handling it with video is great during the daily scrum. But, most teams that I’ve talked to or worked with that used this approach during the meeting did *not* use it the rest of the day. The text on the cards couldn’t be read was the usual problem.

So, video: Great approach but only a partial solution, IMO.

Derek Mahlitz said…

We use the taskboard vertically so tasks move from top to bottom for each story through New, Checked out, Done. Inside each of the 3 squares we have an updated box in the corner, when a collocated team member makes a change to the remaining or checks out a task they place it in that area.  So I spend 15 minutes a day looking through only the post-its in the ‘updated’ areas on the board.  Our Fl home worker looks in the spreadsheet and sends me an IM on any changes.  All this is Done before our 9:45 am standup meeting so the burndown chart (on the wall and in SharePoint) is updated for the meeting.

Derek Mahlitz said…

It does take me about an hour after sprint planning to enter all the tasks into the spreadsheet.  All in all on a 20 business day sprint its about 6 hours of total work to keep the spreadsheet updated to match the board. 

Remember that the SM is the servant leader to the team and helps clear obstacles in the teams way.  If I can keep 1 team member cleared from hassles of tracking tasks then that is worth the 6 hours a month I spend..

Gerry Kirk said…

Mike, apparently the Wii has a wand you can use to interact with web pages. Projecting a Scrum whiteboard tool with drag/drop click capabilities might be fun. :) Can’t see that working for all input, will let you know if I get a chance to experiment.

Dave G said…

I’ve run into the challenge of maintaining a scrum board and keeping it in sync w/ a tool. I tried updating tasks in both places, and this was a pain. Here’s what I’ve been doing, and it works pretty well.

1. Use the scrum board for task tracking.
2. Have 1 Task per sprint in the tool with the Total Time Left for all tasks. Then daily, I add up all the hours left and update the one task. This provides the sprint burndown, yet detailed tasks remain on the board as desired by the team.

Thierry Thelliez said…

What about emailing a simple digital picture at the end of the meeting?

You could still have a 15 minute webcam to have ‘face time’.

Carlton Nettleton said…

@Derek - Absolutely.  The SM is there to serve the Team.  IMO, reporting progress on the Sprint Tasks to parties outside the Team is the responsibility of the SM.  It helps prevent those parties from distracting the Team. 

@Dave - My preferred method when you need to combine analogue and electronic tools.  The Team uses simple tools (whiteboards, index cards and post-it notes) to manage their work and the SM and PO use electronic tools to manage and report their work.  In most cases I have seen, once the Team begins using the electronic tools to update and track tasks, the electronic tool begins to drive the process instead of facilitating it. 

IMO, there is almost no value in the Team reporting out and storing tasks electronically.  There are so fluid, dynamic and owned by the Team alone, that why do we ask they be broadcast in electronic form?  Because we can in a tool?  Not a good enough reason for me.  If we are talking about user stories - that is completely different scenario and there are more than enough reasons to store, track and preserve them electronically, if it is called upon.  Stories are how the organization interacts with the Team and it is reasonable to persist these items electronically for visibility and to share.

Ron said…

I have used a spreadsheet to create a virtual task board for one remote user and it worked well.  It took about 10 minutes every day to update the spreadsheet and post it on our BaseCamp site.  It was also useful when someone needed to work from home.  The remote team member was on the same page as the rest of the team.

We considered moving to a complete electronic solution, but felt the advantages of having the physical board far outweighed the benefits for just one team member.

Mike Cohn said…

Thanks, Bignose, but I just looked it up the Oxford American Dictionary and it does mean what I think it means. In fact, the example they gave was exactly the same as how I use it. I double checked on “co-locate” and it has still not been given official status as a word per that dictionary. I know it’s very commonly used and will someday be in dictionaries such as OAD, but it’s not there yet. Thanks, though. Mike

Alex Kalinovsky said…

Mike, can you comment on the following problem that is taking what you described to an extreme?
Due to the nature of organization our whole team is split between three different locations, not just one person sitting in a home office.
It is mitigated somewhat by the fact that teams are working on different components of the system that are integrated together, but this is small comfort as we are not as efficient as we could be.
Have you come accross any succesful teams that were set up that way? Are there any tips for setting up a distributed team?

Mike Cohn said…

Hi Alex—
Yes, there are definitely successful teams that are set up this way. Being distributed just makes things harder, it doesn’t make them impossible. Unfortunately the list of things that a distributed team should do to help be successful is far longer than I can go into in a reply to a blog postings about task boards. I’ll try to blog about distributed teams in the near future.

I can say, however, that I have a detailed chapter on Distributed Teams coming in my new book. Earlier reviewers have told me that this chapter was very helpful. The publisher is going to put out a preview version of the book on PDF very soon so I’d suggest that as a source of helpful information on distributed teams.

Syed Rayhan said…

I would need to challenge the status quo here. Why do we fight the need for distributed teams? Even more interesting is that I see this tacit acceptance of using physical board when we have great tools that not only solve this problem but also provide so much more. I see more people here have some type of distributed teams, yet have this love affair for a physical board…:-)

Why do we not go completely electronic? Wouldn’t this issue be irrelevant then? I coach a team (collocated only) that started out with a physical board and cars and Excel spread sheet. A few months into the project, the team realizes that a Web-based project management tool would make their life a lot easier without reducing a bit of interaction quality. Since then, we have been all electronic ever since. Even for our daily Scrum, we use electronic task board through projector.

I don’t understand why some of the tools require developers to move the cards explicitly. Why not just provide time information, let the tool determine the status? Yes, there are a few cases where we would need to provide explicit state information. But, it is exception than norm. By the way, if you are not aware of such a tool, check out ScrumPad.

If any team still needs to see some sort of physical task board, they can always get a large flat TV and connect it with a computer and viola we have a physical task board…:-)

I know my view may not be popular here…:-)

Mike Cohn said…

Syed—
You should have mentioned of course that you work for or are ScrumPad.

Syed Rayhan said…

Mike,
Yes, sorry I should have. I thought readers will know by way of reading my blog, at least. However, my view is independent of my association with ScrumPad…:-) There are other great tools too. I would love to hear your thoughts though. I am curious why Agile teams have preference for using physical boards over going all digital. Any thoughts?

Michael J. Tardiff said…

Mike—

Thanks for this post; we had a similar situation, with one member in San Francisco and the rest in Seattle. We experimented with various schemes, but we found that the one that persisted was where we helped the remote member keep his own mini-taskboard and used video/IM/email/telephone heavily for daily interactions.

Reading the comments made me think about the tool-versus-manual/physical debate yet again (and it’s one of my favorites, so I think about it a lot). I wonder if the folks who advocate using electronic tools over a physical task board have costed out the expense and compared it against the benefit. Sure, some tools are free for small teams, but projectors or monitors and the like have costs that make the expense of cards and tape and markers look pretty impressive. Except in the hard-to-resolve distributed-team cases, I wonder if we’re drawn to using computers and software just because most of us make them?

Chuck van der Linden said…

For a mostly or fully distributed team a tool might make a lot of sense.  but otherwise I’d challenge the assertion that a tool offers ‘more’ than a physical taskboard.

I’ve yet to see a tool where it was as easy to sort, arrange, and otherwise manipulate the ‘cards’ (or the info represented on them) as a physical board, nor, unless we develop ‘minority report’ level tech, provide the same visibilty and ‘big picture’ view that a board does.

or even this simple scenario, I grab a card and collar the PO into a small meeting room to have a 5 min discussion regarding the task, the criteria, etc.  how do you do that with a tool unless you start putting pc’s and such into every small meeting room, and then we still have the time to login to the system, access the tool, find the card..

and how about any sort of making diagrams, or anything that’s not textual without a touchpad or tablet pc..

Mike Cohn said…

Hi Chuck—
No argument from me. Whenever possible, a team should use a physical task board to contain the sprint backlog. I’m such a big fan of index cards stuck to the walls that I actually buy clothes to help me use them; I buy rock-climbing trousers from Eastern Mountain Sports. They have pockets on the sides that perfectly hold 3” x 5” index cards. The pockets are really for carabiners used by climbers but they work great for me.

Alida Cheung said…

Hi Mike,

I have been doing this for over two years with various Scrum teams.  I updated the electronic version real time while the team members update their physical cards.  I’ve used a web cam.  The remote member said even though he couldn’t see the details on the cards, being able to see the task board was very helpful - gave him the big picture and provided a sense of belonging. (We made faces at him too, of course!)

I didn’t read thru’ all the responses and am not sure if the following has been mentioned.  I insist on this extra work for the ScrumMaster (me) than just using the electronic tool because at least for the tool we use, we won’t be able to see the whole ‘virtual board’ all at once, depriving the team the ability to see the whole picture, which I think is very important.

Mike Cohn said…

Hi Alida—
I think what you’re doing is great. Thanks for sharing it with us. Seeing the big picture is important. I have a slide I sometimes use in classes that is a photo of a task board. The photo is such that you can’t read anything on any of the cards. But, it does give a good view into how the sprint is going—e.g., someone can see that only one task is left on this story, someone can see that another story has a lot of tasks left, and so on. Even without knowing the tasks or number of hours involved in each, this high level view is valuable.

Zeppelin said…

Hey Mike,
I have an interesting scenario and it may not be directly related to your post. We’ve been using a physical task board for the last 5 sprints. During our planning sessions, we use TFS to capture the work breakdown for each backlog item included in the sprint. Updating the task board manually afterwards seems like a labored and redundant task. There are a few electronic task boards out there that I’ve looked at. Does it make sense to abolish using the physical task board and have everyone use the task board took instead? What are your thoughts?

Mike Cohn said…

If everyone is in the same office, I’d get rid of the software rather than the physical board. If you need to put tasks in software for some reason (distributed team or such) then get rid of the physical board if the team is OK with that. They may want it still and find it worth the extra effort. It shouldn’t be a lot of extra effort but it is a hassle.

Leave a Comment: