The Haphazard Blog

I’ve been working with Scrum since 2010. I work from home and my company has multiple offices so people on the same team are not in the same office often. As a result, we’ve almost always had to run our Scrum teams as distributed teams so we never had traditional Scrum boards/walls for tracking our backlog/sprints.

We started out using an Excel spreadsheet back in 2010. Since then, we’ve used other tools: VersionOne, TFS, TFS+Urban Turtle, Kunagi, and JIRA GreenHopper (now JIRA AGILE). More importantly, we’ve learned what works well and what doesn’t when being a distributed team. I’d like to share the things we like to do that work well for us. Some of it is useful for all Scrum teams, other stuff is more targeted toward distributed teams. I’ll try and hit the major areas of Scrum.

Team Communication

Text chat is very important for us. It allowed us to communicate in a non-interrupting manner with the team and also served as a virtual water cooler. (Although as binge watching and time shifting TV became more popular, that topic was limited for spoiler purposes.)

Screen sharing is another important tool and we used so many various products over the years. The best ones make it easy/quick to start a sharing session and easy to join. Sadly, this is a reason we have used so many as they usually start out that way and move away from there. This is important for solving problems as a team and used extensively for meetings.

Backlog Estimation

We moved away from marathon sessions. Meetings that are half a day long were simply too long. We made sure no meeting exceeded 2 hours, ideally 1.5 hours. We did not estimate the entire backlog, but generally enough to cover about 3 sprints were estimated to start. We then occasionally held estimating meetings which turned into fun meetings because everyone was actively participating.

We moved away from the traditional Fibonacci sequence of points (1, 2, 3, 5, 8, 13…) and moved to a 1 through 5 system. If it was larger than 5 it should be broken down into smaller stories. This let us stop making tasks for each story and leaving it up to the person who picked up the story to add tasks if they felt it was helpful.

Planning poker is an excellent way to involve and engage the entire team. It encourages a good discussion about the story and the work needed to complete it. It affords everyone an opportunity to weigh in with their estimates and the Scrum Master then has an opportunity to engage individuals when the scores differ. The team builds a consensus that everyone has now bought into, which means there are no surprises or disagreements later. New team members pretty quickly understood what the 1 through 5 scale meant during their first meeting.

Sprint Planning

With the estimation separated from planning, our planning sessions were generally quick. The Scrum Master will have already met with the Product Owner to prioritize the backlog so it’s a matter of seeing how much of the backlog can fit into the next sprint. Team buy-in is also quick since they had already agreed on the estimates. We would mark everything that is Done as Done and pull over anything that was not completed and fill up the rest. When you have a team that works well together, you can generally predict who will pick up which stories here as well and likely account for vacations with the stories you choose to include.

Daily Standups

We tried to go strict Scrum with this by having 15 minutes for he standup and 15 minutes after for items that were sent to the “parking lot” for further discussion. In practice, this didn’t really work because we were all mostly separated. The little additional discussions/questions beyond the typical three (what I did since the last standup, impediments, and what I plan to do before the next standup) were of interest to everyone. Being separated meant we were either communicating one-on-one, in text chat, or in a group meeting.  The standup is an opportunity when the whole team is together and one can ask opinions, questions, or share something interesting in their work. Our meetings were still around 15 minutes, but sticking to only status updates was not enforced.

One other discovery was that telling people we were starting on time didn’t help with punctuality, but having the person who arrives last start with their status first did. We never had to tell anyone again to be on time because they learned it and knew they were holding the team up with being late. They held themselves accountable.

Sprint Demo/Review

We usually allocated about 1.5 hours for demos and invited the group manager to all demos and senior management to demos for major releases to give visibility into the work the team has accomplished and the value for the customer. Following the demo we would perform the standard retrospective (what went well, what would we do differently, and what did not go well). First we’d review the last retrospective to make sure we didn’t repeat problems from the last sprint and improved in the areas we planned to do better. We then tried to go through each area and let anyone share items to add. Some sessions there wasn’t much and it was almost like pulling teeth to get much. You feel like there should be items, but sometimes things go well/as planned. But, that’s something that went well! We learned to accept that as long as we were honestly reviewing the Sprint, it was OK if the retrospective was sparsely populated with items.

One final note is that you may notice that in most areas, new team members don’t really require any training in Scrum because they quickly pick up on how things work with the current team/culture. When Scrum is being performed consistently, one of the benefits is new team members get up to speed quickly and moving between teams that operate the same way is more seamless.