29 August 2007

It's Story Time

by mo

Last night I finished reading…

User Stories Applied: For Agile Software Development (The Addison-Wesley Signature Series) by Mike Cohn Read more about this title…

It was a nice quick and dirty read, to get my feet wet in the world of applying user stories. I really prefer working with user stories as opposed to full blown system requirements specifications. Although, a typical SRS is much thicker then a set of user stories, I think more information is delivered through user stories because it done so piece by piece. As you require the information, it’s your responsibility to gather it.

I want to share some of my favorite quotes from the book.

“Pay attention to who is contributing during a story writing workshop. Occasionally a participant will remain silent through much or all of the meeting. If this is the case, talk to the participant during one of the breaks and make sure she’s comfortable with the process. Some participants are reluctant to speak up in front of their peers or supervisors, which is why it is important that story ideas not be judged during these sessions. Once participants become comfortable that their ideas will simply be noted, not debated, at this point they will contribute more readily.”

I have to admit that at my first story writing workshop I didn’t say much. It was kind of a foreign concept to me and I worried about getting shot down by the other developers if I mentioned a story idea. I felt like there was a good chance that would occur because the rest of the team felt they had a similar vision of how the product would look and feel before and discussion had even begun. I later realized that they did indeed want to hear my story ideas, but it just took some time getting used to the culture of the team.

“When you cannot find, or get access to, a real user, avoid falling into the trap of thinking you know your users’ minds and do not need or can ignore your user proxy. While each type of user proxy has some type of shortcoming that makes her less desirable than a real user, most developers come with even more shortcomings for pretending to be a real user. In general, developers do not have marketing backgrounds that allow them to understand the relative value of features, they do not have the same amount of customer contact as salespeople, they are not domain experts, and so on.”

I know as a developer that there are many times where I know how I would like a piece of software to work. Because it would work well for me, but ultimately that’s not always going to work best for the end user. It’s difficult to put yourselves in someone else’s shoe to try to think like they would. It’s much easier to just ask, instead of making a design decision, implementing it then later having them tell you that’s not what they wanted.

“Ideally the customer writes the stories. On many projects the developers help out, either by doing the actual writing during an initial story writing workshop or by suggesting new stories to the customer. But, responsibility for writing stories resides with the customer and cannot be passed to the developers.”

Wow… I had no idea. Right now we’re writing the user stories…

“In a blame-filled organization there are always some individuals who have learned that their best decision is to avoid all responsibility. If you’re not responsible for something you can’t be blamed for it when it fails, yet there’s usually a way to lay claim to at least some of the success. Individuals in this type of culture will want nothing to do with hard decisions like prioritizing features into and out of releases. They’ll fall back on statements such as “It’s not my problem that you can’t complete everything by the deadline, figure out a way to do it.”

This seems to happen more often then not. I think when someone because slightly hostile, it’s usually because of their own insecurities. But reading the above statement just helped me to realize to think about what they’re going through. Who’s grilling them, and how can I help so that they’re are happy with the software but it also makes them look good to their peers.

agile books