Writing User Stories and Pragmatic XP

Writing User Stories

Part 1 Part 2 Part 3

My previous post in this series generated a lot of commentary on the XP list. I honestly appreciate everyone's insight....it can only make me better.

My intent (with respect to this series) was to suggest other approaches to writing stories. The series is aimed mostly at helping users. I try to make these approaches simple. Some users will find a "by the numbers" approach easier to wrap their mind around. The 5Ws method may also provoke a deeper analysis of the story as users try to describe each W. I also believe that some developers and testers might appreciate a more predictable user story. In the end though, users can bring us any scribble. Be it on a card, a sticky note or a napkin and we will do our best to make it a reality.

The series was never meant to be a holistic commentary on writing stories. As a rule I try to avoid anything holistic. I do, these days, try to be pragmatic and a bit understated.

When I first started down the path of XP (uhg, sounds way too cult-like) I worked in a shop with no formal method for developing software. When I discovered XP, I wasn't looking to be agile....I was looking to be methodical. My first instinct was to codify as best I could a fully functional set of XP policies and procedures. What mostly drove my efforts was a need to justify our wacky ideas (ie pair programming) to what was and primarily still is a government contracting company.

It took me several years of struggling to realize that I missed the whole point of XP. Yes, XP does help you to be more methodical, but without the formalized process. XP's informal nature is what makes it "Agile". The practices are not rules but guidelines. The coach doesn't drive the bus (the team does) she simply points out the pot holes. Finally, this all works because each person values good software over the process. The point? We write and discriminate our user stories the same way.....with a lot of guidelines and very few rules.

I wish I could say that I gained all of this insight many years ago...but I didn't. I really only got it in the last two or three years. One day I had to stop talking and start listening. To that end, I can mostly thank the insights of two of the smartest people I know (Gareth and Jason) and the never-ending patience of my boss Rob.

In the words of the "Wyld Stallyns"...."Be excellent to each other!"

Shoot Yourself in the Foot!

!WARNING! If you're not a major nerd or geek you won't get these jokes!
Recently a friend of mine sent me some funny additions to the Shoot Yourself in the Foot! list. The list is a humours look a the logic you might need to "shoot yourself in the foot" in different programming languages. Here are his suggestions:

Python
You try to shoot yourself in the foot, but the gun refuses
to go off because it doesn't have appropriate space around it.

Perl
You quickly create your own gun and shoot yourself in the
foot. Witnesses are unable to explain what happened. No one else can
figure out how to use the gun.

JavaScript

Your prototype gun admirably shoots feet during testing,
but in production many users' hands are incompatible

Flash
As you pull the trigger, the gun's barrels surge
impressively to life. The muzzles flash, smoke billows, and the ring
of pounds of expelled brass is barely audible over the deafening
gunfire. After the smoke clears, your foot is unaffected and you
realize nothing seems to have happened.

Here are a few of my own additions/revisions:

Visual Basic 6
You take advantage of the very handy ShootMyselfInTheLeftFootOnce() method and wait three years for M$ to release a ShootMyselfInTheRightFootOnce() method.

C#
You spend several hours browsing through Intellisense drop downs and the object browser looking for the right combination of .Net classes and methods to shoot your foot and eventually decide to port the Java libShootMyFoot library.

Java
You decide to take advantage of the libShootMyFoot library. After days of scanning painfully abstract API documentation you realize that, through some complex twist of logic that still can only be understood by developers working for Sun, the libShootMyFoot library was never intended to be used for shooting feet.

Please post any additons you would like to see!

Monorail Custom Session Factory for Memcached

Introduction

I have written a simple but effective ICustomSessionFactory implementation that uses memcached storage on the back-end. If you don't know why you should be using memcached then you should check it out first. If you want to check out the code now, then go here. So far I think I have a passable Session Factory implementation that uses memcached on the back end. In later posts I will give some code examples and more details about deploying the Factory code.

Details

Here are a few dependencies you will need to get going:

• Castle::Monorail
• A memcached server or servers running on your network. Memcached is a simple and fast distributed object server for balancing object caches across many servers!
• The latest release of Enyim. These are the guys that did all the real client work! Thanks to them for a great memcached client!
• If you want to run the tests or plan on making modifications then you will need the Nunit/RhinoMocks stack.

Current Features

• A session dictionary that uses memcachedon the backend. This is the real meat and potatoes.
• Almost complete IDictionary implementation (The Values property and enumeration are not implemented). The default session in monorail doesn't seem to support the values property either. For that reason and for performance reasons I have no plans to implement the values property.
• ICustomSessionFactory for CASTLE::MONORAIL

Planned/Missing Features

• Optional DB persistence of sessions using activerecord/memcached fusion. Memcached storage isn't redundant and as a rule caches should be considered unreliable. I would like to give developers the option of turning on a DB persistence layer to ensure the reliability of the session state.
• Cache provider for monorail. Abiity to easily add memcached caching into all of your service components.
• Cache provider integration with ActiveRecord.
  

DOWNLOAD MEMCACHEDFORMONORAIL!

Other Memcached Goodies

I also intend to write a custom cache provider for ActiveRecord / Monorail. So stay tuned!

Writing User Stories the 5 Ws Way

Writing User Stories

Part 1 Part 2 Part 3

This is Part 2 of my "Writing User Stories series". Part 1 focused on some common pitfalls while writing a user story. In this article I intend to outline a simple but effective method of writing a user story using the 5 Ws.

A User Story is written by any User. The User Story should have a short but descriptive title and a longer narrative. The narrative should include the 5 Ws: Who, What, When, Where and Why.

• WHO: Usually, the type of user (ie Admin, Student, Teacher)
• WHAT: What the user in the WHO is going to do (clicks on the "new blog comment" button)
• WHEN: "When" may describe a time or date or relative time (ie After logging in or after reading a blog)
• WHERE: Where on the page or in the application.
• WHY: What was the trigger for the user (user wants to suggest a change to the blog post)

Example 1: A student (who) clicks the new blog comment button (what) after reading a blog post (when) located at the bottom of the blog post (where) in order to make a comment about the blog post (why).

Discussion 1: Example 1 is pretty straight forward the who, what, when, where and why are well defined. Let's look a more complex example.

Example 2: An instructor (who) has determined which students to put into which discussion groups(why,when). Viewing the student listing for a class (where) clicks the checkboxs next to several student names, selects a discussion group from the drop down and clicks the add to discussion group (what).

Discussion 2: Example 2 is a bit more complicated. The "what" is a bit more protracted and the "why" and "when" are combined. For more complex stories it may be easier to list the 5 Ws first:

Who: An Instructor

What: Selects multiple students (at once) and adds them to a discussion group

When: After determining what students go in which groups.

Where: From the student listing screen.

Why: To get students into discussion groups.

In this format the when and the why come out a bit differently. Using the 5Ws method can greatly reduce the amount of time it takes for users to produce good stories. When all stories are written this way they become easier to estimate and the why element give valuable insight into what a user expects from the software.

Note: (Added 2 Sep 2009) In fairness to the SCRUM world this could also be expressed in SCRUM Style: As an instructor I want to add multiple students to the discussion groups from the student listing.

Feel free to suggest additional examples or make comments!

8 Things You can do Now to Improve Your Software

These aren't new ideas but they are true. The list below focus' on the things that organizations should be doing to help make their agile teams more productive.

• LET USERS SUBMIT ISSUES! Let users submit issue tickets. They may be bugs, feature requests...whatever. You need to start tracking it. Your users will sense that you place value on their needs and you will have invaluable data for prioritizing new user stories.
• GET USERS TALKING ABOUT YOUR SOFTWARE! Create a discussion forum or bullitin board for users to discuss the software they use. Creating a community around your software will help endear your users to it. Your engineers, product managers and other stakeholders should be encouraged to actively participate. Your team will gain great insight into how users are using the software.
• MAKE A USER AVAILABLE! Developers should have real-live users to contact and ask questions. Most of what slows delivery of new features is a clear understanding of how a user will use them. Many new features end up looking nothing like what a user was asking for. These features sit around and remain unused.
• TESTERS SHOULD BE USER EXPERIENCE EXPERTS! Put user experience experts on your testing team. If you don't have a testing team then become a user experience expert.
• CO-LOCATE THE "WHOLE TEAM"! XP defines the Whole Team as the developers, testers and users. Studies show that communication is a major linch-pin in the success of software development. Anything you can do to improve communication will pay off.
• EAT YOUR DOG-FOOD! Dog-fooding is the process of using your own software internally (eating your own dog food). If you use it then you will fix it!
• RELEASE OFTEN AND EARLY! Your users like to see new features! These days you absolutely MUST give users a sense that your software has a future. Your organization should never consider a project "complete". You must work iteratively and release smaller chuncks of functionality.
• ALLOW DEVELOPERS TO CHOOSE! The big boys know this one! Google does this and so does M$. Take advantage of your engineers' Creative Momentum and let them decide which project to work on. I would suggest that this can be done from iteration to iteration or release to release.

Programmer at War (in Iraq)

Most of those who read my blog are probably unaware that I am in Iraq. Normally, I am a Software Engineer/Chief Systems Architect for an Oklahoma based company. One weekend a month I am an Officer in the U.S. Army Reserves. Last summer I was deployed to Iraq.

I am a Platoon Leader in a Medium Truck Company. It's quite interesting how different my civilian and Army jobs are. In my civilian job we are always going forward with new developments. In my Army job, each mission tends to be organized similarly and entail doing the same task over and over again. Although, sometimes, the enemy has a say in that.

In some ways though, my jobs are very similar. There is a great deal to be learned from my experience in the Army. Being an "agilisto", I really value communication and people. In the Army, the most successful leaders learn to communicate very well and place the needs of their soldiers before all else.

On an agile project we plan and deliver value incrementally. This allows teams to embrace change. In the Army, it is understood that your enemy, the weather and the terain have the final say-so in all plans. Unfortunately, just as in the software engineering world, not everyone understands this concept and are unable to embrace change.

I dealt with this recently. We were planning for a mission. Our higher echelon wanted us to push out on a certain day. I felt we could do it. The Platoon Sergeants had a "feeling" that we could not push out until 2 days later. Usually , in the agile world, the nod would go to the Platoon Sergeants (the team).

99% of the time I would agree. Although, sometimes, we are presented with time sensitive requirements. I attended a workshop several years ago at AgileXP, that talked about Advanced Estimation. They suggested that, in some cases, you have to push the envelope to get requirements met on time. I felt this was a time to push the envelope.

Well, since I am the acting XO, I argued my point. Eventually, I was able to convince the Platoon Sergeants that we could "try" to meet the requested date. I suggested, we would keep our higher echelon (the customer) informed by passing up incremental updates and letting them know the risks upfront. As the date approaches, and things aren't looking good, we give them the option of changing the operational scope. If the scope is what they value most then we suggest they push the date to the right.

Ideally, we want to stay pragmatic and plan our time accordingly, but in a few cases we have no choice but to work out some solution. A common argument from the Platoon Sergeants was that our higher echelon would consider this a solid commitment and our hands would be tied if something went wrong. Surprisingly (not really) our higher echelon was very understanding and, like everyone in Army, was prepared for a contingency in which we were unable to meet the mission.