Something Smells

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 f...

!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. A...

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 s...

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 blo...

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 wil...

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...