Agile Ottawa Meetup - User Stories

On Thursday night this week (November 24, 2011) I attended the Agile Ottawa Meetup Group http://www.meetup.com/Ottawa-Scrum-Users-Group/. I have attended in the past before, but did not have a very good experience unfortunately. No details will be shared, but I put that aside and thought I would go again. This session I am happy to report was well organized and I learned more about Agile.

Below are my thoughts of the evening.

The meeting was focused on writing User Stories. The presenters, who were the “Product Owners”, gave us a mockup application that they wanted us to “develop”. The group self organized into four teams, of approximately four people. We then went through and wrote User Stories for the application. I have been writing User Stories for a while now, but what I did learn was A) another template that can be used B) mind set of those involved in writing can be very different.

Templates

This one I have been using:

As a <user>

I want to <task>

In order to <goal>

The new template I learned was:

In order to <goal>

As a <user>

I want to <task>

(Side note both fit well with Given, When, Then as well :) )

The new template simply rephrases the order to help it flow better. Depending on the scenario and phrasing required, I noticed that we used the different templates. Basically, we used what sounded right.

Testing vs product owner vs developer mindset can be very different when writing a user story. The teams that were mostly developers the User Stories were very technical, while tester’s User Stories were more general in nature. This reaffirmed to me in the Power of Three was necessary for User Story writing. The team should do this. Not just the developers, not just the testers and not just the product owners. ALL should sit together to write the User Stories as this remove confusion and helps start the iteration in a good direction.

Some good points that I picked up:

•        Focus on what is necessary in a user story
•        Do not over think the user story. Some went wildly off track from what the Product Owner wanted in the product. There is nothing wrong with thinking about how the application will work in the future, but over thinking can “cloud” our tasks for our current Sprint/Iteration.
•        User story should be testable externally. With this we started to write three Acceptance Tests per User Story. This really helped us focus on writing clearer and shorter User Stories, and will help the team define Done as well.
•        The presenter suggested that each User Story should take up no more than half of your Sprint/Iteration.
•        If there is research involved in a User Story or task, make sure you time box it, or it can grow out of control.

I was happy to hear that some use diagrams to write their user stories. They didn’t really see or know that what they were doing was simply a mind map. Mind maps are just very useful and can be used for many applications. Using maps for User Stories will be something that I will like to introduce to my team going forward.

Some good (or bad) quotes from the night:

“Telling a developer how exactly it should look will take away the freedom for developers to add value.” (I am not in agreement with this. As a team, you should be working together to a common goal. Product Owners should know what is being developed, and testers should have a clear under standing before development starts (ATDD) in order to prevent confusion and test case rewrite at the end.)

“Keep User Stores big when out there, but when they come closer (in time) break them down, like the game of Asteroid.” (Again, I wonder about this. If something is not yet ready to be worked on for a Sprint, is that simply not on your backlog or as a requirement? Should you have large User Stories that cover future development, or simply statements for what they are?)

“The more self sufficient your team is, the more effective it is.” (I agree with this)

“Break down barriers between teams.” (Definitely. I was surprised how many at the meetup were working at companies were the developers, testers, UI developers and product owners worked on separate teams and even in separate locations! That does not sound Agile to me. I’m just very happy to not be in that situation currently.)

Overall I enjoyed the session and learned more. The most valuable item I got out of going though was how happy I am with my current job and the team I work with. Our team is quite mature when it comes to Agile and we are doing really well. Sometimes I think the grass is greener on the other side, so it was nice to see how other companies work (some are cutting edge, and some are still learning). I just know that I have a good balance where I currently am, and freedom to continue growing.