joshua hoover

In my last post I wrote about user stories and how it’s easy to write a user story and forget to include the value statement.  Now that we’re all writing user stories with value statements, I thought it would be interesting to look at another phenomenon I’ve seen far too often when it comes to user stories – their death.  Yes, all good things must come to an end, but the way too many user stories die is not fitting.

Let’s take the example user story from the last post, which was from the Apple iPhone product owner (who am I kidding, Steve Jobs):

As an iPhone 3G user I want to be able to make VoIP calls over the 3G network in addition to wi-fi so that I can save money by not using my crazy expensive voice minutes.

The team working this user story thinks they’ve got it during their backlog selection. They’re excited to put the screws to the carriers as they prepare to expand beyond AT&T and turn the cell phone industry on its head.  The team does their task breakdown and they’re off and racing.  Daily scrums are happening, team members are communicating, impediments are being raised, tasks are getting done, and all is good in iPhone VoIP call land. The sprint review rolls around and the team is ready to show off their solution. They demonstrate making VoIP calls on a 3G network. Only one little problem.  The team mentions that in order to complete this story in time they decided it was best to use a VoIP service provider that would make the user experience far superior to any the team could develop in a reasonable amount of time.  The VoIP service provider charges a monthly fee. On top of the monthly fee there are hidden charges around certain types of calls. The product owner does his own demonstration following this. He demonstrates how the iPhone 3G can be used in combat by chucking the sleek devices directly at the team members’ heads.

So what happened? The user story was viewed during backlog selection, placed in a sprint management tool, and forgotten about until the sprint review. The team understood what they were doing, or so they thought. They were focused on completing the tasks to get the user story done. The team lost track of the actual user story – out of sight, out of mind.

The trick is to make sure the user story doesn’t get lost throughout the sprint and die a quick (yet too often) painful death. I haven’t figured out how to do this. Posting the user stories up on boards/walls is one idea. Temporary tattoos (that last the length of a sprint) of each user story on every team member’s forearms is another. Wait, that’s it. Sorry, I’ve got to make some calls now. My temporary tattoo parlor is calling.

One of the most overlooked parts of user stories is the content that follows those two little words, “so that.”  I’ve found that we (those of us working on agile projects) tend to do a good job of writing user stories until it gets to those two little words.  For example, let’s say the iPhone team has a backlog and one of the stories is:

As an iPhone 3G user I want to be able to make VoIP calls over the 3G network in addition to wi-fi.

Sounds pretty good in terms of a user story. It’s likely more an “epic”, but I won’t get into the size of user stories. Let’s start the conversation with the product owner and the team and estimate this story. Not so fast. Notice that we have no idea why the user would want to make voice over IP (VoIP) calls over the 3g network. I think the assumption is often made by whoever is writing the user stories that the team and others already understand the value of the story. That is not a safe assumption to make. Not only is it not a safe assumption to make but the focus of the team will turn to “how” to make the user story a reality. I think we’d all rather discuss the value of the user story before we start jumping into questions about how it might be implemented. But when the value isn’t present in the story it’s easy for everyone to overlook. Let’s see what that story might look like with the value statement added to it:

As an iPhone 3G user I want to be able to make VoIP calls over the 3G network in addition to wi-fi so that I can save money by not using my crazy expensive voice minutes.

Now we understand why the user wants this functionality. Before we could’ve assumed it was for any number of reasons. The cost savings is the driver for this story. The team and anyone else reading this user story can now better understand what the real drive for the desired functionality is.

I read a while back an InfoQ article about changing the format of user stories.  The traditional format is what we’ve already used in the example above:

As a <type of user> I want <some functionality> so that <some benefit>.

The new format suggested by the Elizabeth Keogh, the author the InfoQ article points to as the one suggesting the new format, looks like this:

In order to <achieve some value>, as a <type of user>, I want <some functionality>.

I think the new format is worth considering in light of how many user stories lack value statements. The only thing holding me back from this new format is that it reads too much like Yoda speak. Yoda was always known for putting those awesome sentences together, like: “Named must your fear be before banish it you can.”

I think whether we change the format of user stories or simply use the existing format, the important thing to remember is to communicate the value driving the user story. As Yoda might say: Focus we must on business value lest we lose reason why user story exists.

Has your team struggled to define “done” for user stories? You are alone. Everyone has this one figured out.  You must be new to this thing called agile software development. What’s that? You’ve been doing this agile thing for some time now?  Wow, that has got to be depressing. I’m sorry to hear that you’re struggling with such a simple concept.  Fortunately for you I’ve got the answer. Follow these three simple steps:

1. Listen to this podcast with Scott Hanselman interviewing one of the founding fathers of Scrum, Ken Schwaber
2. Sit down with the team, Product Owner, Scrum Master, and maybe even major stakeholders to define what success is for your project in a clear and simple manner
3. Make a list of all the activities required to achieve the level of quality required by step 2 for a typical user story in the backlog

Easy, right? That’s fine.  When you punch the picture of me on the screen I don’t feel a thing. I’m still smiling, see?

The title of this post is misleading. I think distributed agile teams do work, but only if everyone is remote. I’ve come to the conclusion that what doesn’t work are what I call “semi-distributed” teams. Semi-distributed teams are those where some people are co-located and others are not. I’ve seen all sorts of arrangements over the years. Everyone collocated but one person (experiencing that one currently – me being the odd man out), some collocated in one office and some in another, a few people distributed remotely and others collocated, on and on it goes.

The reason I argue that fully distributed agile teams work is because everyone is in the same boat. Everyone is disconnected and therefore looking for solutions to the problem of connecting with one another. With semi-distributed teams you have some people who are desperate to be a part of the conversation, while others are often quite content with their little collocated circle. I think this fact is often overlooked when people point to Open Source Software (OSS) development working in a distributed fashion and equate that to proof that semi-distributed projects can work just as well. One of the reasons OSS development works is because everyone is (typically) working remotely. The ease of looking across your desk and striking up a conversation with one of your team members is not an option with most OSS projects. Everyone on the OSS project needs to put forth an extra level of effort to strike up a conversation, even if it’s just chatting in IRC, sending an email, or doing a screen share session.

A majority of agile proponents will argue that collocation is a requirement for highly successful agile projects and I agree. The level of discipline required to make distributed agile projects work cannot be understated. But, you can be successful with distributed agile projects. What you cannot be overly successful with are semi-distributed agile projects. The level of effort to make semi-distributed agile projects work is too great for most of us mere mortals to overcome. I’m sure there are those that will point to their success stories of semi-distributed agile projects, but I will argue those are the rare exceptions rather than the general rule.

Some may read this post and have a moment of truth smack them right in the face, “Wait a second, I’m on a semi-distributed agile team!” What do you do in that case? My suggestion is that you figure out a way to make the team collocated. There are many creative ways to make this happen. For example, the team that I’m currently on and am the lone remote person on the team (Scrum Master, nonetheless!),is going to get a local replacement. If you can’t go collocated, then a radical idea might be to go completely distributed. Have everyone work from home and force themselves to deal with being remote. It’s amazing how well teams can stay connected these days when they’re all working from a different location. In other cases, it might be possible to create one team that is collocated and another that is truly distributed. Team to team communication is often tricky, collocated or not. At least with a collocated team and a distributed team you’ve eliminated the avoidable problems of a semi-distributed team. The problems you’ll deal with in this case are the same problems anyone scaling agile is faced with. It’s not an impossible mountain to climb.

If you’re still stuck on a semi-distributed team after trying some of the suggestions mentioned above then I wish you luck. The best advice I can give is to enforce use of constant connectivity through technology like video conferencing. People will likely object to this due to a sense of loss of privacy (understandably so), but it gives you a fighting chance of keeping everyone in the loop. Cool apps like MeBeam provide the ability to have more than two participants on a video conference. You’ll also want to investigate technologies that allow you to share whiteboards. I don’t have personal experience with these but I’ve seen them in a variety of places, especially schools. I can see electronic whiteboards helping where collocated members step up to a whiteboard on a whim and start jotting down some new design, architecture, notes, etc. These whiteboard sessions often turn into important moments of team collaboration. It’s moments like these that get lost by the part of the semi-distributed team that is not collocated. Use every communication and collaboration tool in the toolbox if you’re stuck on a semi-distributed team, you’re going to need them.